Re: antiphishing idea

Christian Grunfeld <[email protected]>
Newsgroups gmane.ietf.asrg
Message-ID <CAFdugan4Hg-5GYqCVp9U7+H0qRE6c_gHH+fE+b=JX+87JsmU1Q@mail.gmail.com>
2011/11/19 Bill Cole <[email protected]>:

> I understand both fairly well, but I appreciate your concern for my
> understanding. It is unfortunate that there seems to be a language barrier
> preventing you from coherently explaining my ignorance to me.

I do not need to explain coherently your ignorance to you since you're
doing pretty well job yourself.


> It would be useful for you to think about how you are using the words
> "should" and "could."

In my "bubble world" MUAs MUST submit emails to an MTA. Maybe not in
yours...that was why I´ve used "should".
SPF records tell the world which systems can send email for a
domain...so (as I said) MTAs are closely related to DNS servers for
that domain. With "closely related" I mean they must know each
other..then dynamic updates "could" be easily implemented !


> In a previous job I managed mail servers for the US subsidiary of a major
> global conglomerate headquartered in Germany. Due to control fetishists in
> Berlin and Frankfurt and some corporate asset shuffling between parent
> companies, some of the domains used by US employees had their authoritative
> DNS in very stable zones on machines in Germany. At one point a US IT
> manager insisted that we put SPF records in for one of those domains. That
> took 6 weeks, because no one in the US had been informed when
> responsibilities were shuffled in DE. Less than a year later when we were
> migrating our mail servers to a new set of machines with new IP's, it took 3
> weeks to get the SPF records changed because it was August (when apparently
> virtually everyone in Germany is on vacation.) In getting that change done,
> I learned that the authoritative DNS was running on hardware and software
> that had not been updated since 1997, almost a decade of stability. The
> person who told me this was very proud of it.

> The point of that story: in the real world, there are generally functional
> email and DNS systems that do not work anything like the way you think they
> should now and really could not be adjusted to work as you want them without
> significant modifications to the software, hardware, and humans involved.

you 're talking about the Internet about 15 years ago. As someone
said...when using open relays was a "good" practice ! do not confuse
stability with no improvement !
No human intervention is needed to get dynamic updates to work. You
only need that NS trust you and accept your updates. And obviously if
those conditions are met you dont even need that NS are close to
you....they can stay in germany!


> It is not true today that every email message requires the creation of a new
> DNS record. This is not even true for domains that have deployed SPF and
> DKIM. It is quite possible for a domain to be stable for years with
> thousands of messages per day flowing from its users.

It is not true, right ! but I did not say that. I think you're
confusing a DNS query with a creation of a RR !
I said that today for every email there is at least one DNS query. If
your server checks for a fqdn HELO or a correct map between IP and
names you have a query. If your server checks SPF you have another. If
your server checks DKIM you have another. Its true that some of them
can be cached.

> .... I've worked with domains whose mail targets were
> focused enough that they got less than a thousand SPF queries per week for
> over a million messages sent, so 3 orders of magnitude boost in queries is
> definitely possible if there were to be a query per message. 5 OoM may be a
> stretch, but maybe not for a big bulk sender.

Well, you've worked in many places !  you got SPF queries in the
manner that others implement it or not. It is not an indicator of
query volumes !


>> sorry but you are stup.....
>
> OK, that's not a language issue. We're done here.

sorry about that
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.