Re: [Asrg] antiphishing idea

Please fix your MUA to respect Reply-To headers.

Christian Grunfeld wrote, On 11/19/11 9:55 AM:
> > The absurd idea of publishing valid MID's in DNS does nothing to stop this.
> > The average user doesn't see MID's either, so a phish message can have an
> > evil.com Message-ID and a paypal.com From header.
> >
> > The reason the idea is absurd (beyond being utterly worthless as a practical
> > matter) is that MID headers are frequently generated by MUA's that do not
> > have any way to communicate the MID to the DNS authority for the domain part
> > they use and frequently use domain parts that they really should not. For
> > example,<4EC749E5(_dot_)5040906(_at_)gmail(_dot_)com>  is a MID I recently used 
> > on a
> > perfectly valid piece of email. Thunderbird generated it. A few seconds
> > later I used another MUA to send an identical piece of mail with the MID
> > <26F5BCB8-3977-452A-AA9B-6D64C9F90D69(_at_)gmail(_dot_)com>. If I logged into 
> > GMail and
> > sent another copy, it would be some very long local part @mail.gmail.com. I
> > could legitimately send an identical message (except for the MID) with my
> > GMail address as the From via another SMTP submission system and it would
> > get a MID in the domain of the authentication identity I use with that
> > sending system OR in gmail.com OR under the hostname of the submission host
> > depending on which MUA I use. For many years I used a MUA which by default
> > used an IP literal as the domain part of all of its MID's, which can be a
> > reasonable tactic in some common circumstances.
> >
> > At no point does any current MUA have to inject a new DNS record anywhere
> > when it constructs a message. A MID is supposed to be globally unique, but
> > it isn't really possible for any MUA to assure this perfectly since there is
> > no strict standard for how a MID domain is selected or how a MID local-part
> > is generated. There is no certainty that a MUA will submit mail through a
> > system that will be related to the domain part of the MID.
> I think you really dont know what is a MUA and a MTA !
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.
> MUAs SHOULD
> submit emails to an MTA who is in charge of the transport for a
> domain.
That is something many people have been arguing about for many years. If you 
dig through the Google Groups archive you can find me going into the 
question at length in the late 1990's. I was wrong then because I thought 
that a mechanism equivalent to SPF would force people to use well-defined 
submission and transport paths tightly bound to the domains they use in 
their email addresses. SPF in widespread deployment has proven me wrong on 
that point. It is somewhat quaint to see someone still insisting on that 
sort of binding.
> Call them smarthosts or whatever you want.
> MTAs for a domain should be close related to domain NS and could be
> authorized to dinamically update records.
It would be useful for you to think about how you are using the words 
"should" and "could."
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.

> > The next problem is scale. It is not uncommon for a middling company to
> > generate many thousands of messages daily with peak rates of multiple
> > messages per second, while changing the externally visible DNS zone for the
> > domain used in the MID and From on most messages very rarely, perhaps less
> > than once in a year. Such an organization would need to make major
> > infrastructural changes to deploy your idea, and might well see many (3? 5?)
> > orders of magnitude more DNS query traffic on a domain they would now need
> > to provision in a radically different way.
> you really dont know ! nowdays for EVERY sent email there is a DNS
> query...authoritatlvely or cached anywhere answered ! but there is ONE
> !....SPF makes one more....DKIM makes one more...my idea makes one
> more......how do you absurdely get 3 o 5 orders of magnitud more? do
> you know what an order of magnitud is?
Yes, or I would not have used the term. The above paragraph convinces me 
that we have a communication problem due to language.
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.
Query traffic for an authoritative DNS server due to mail can be trivial. 
Yes, there are queries as a result of each message sent, but today those are 
queries for records that can have TTL's of a day or longer. This means they 
are cacheable so that the authoritative server has query traffic that is a 
function of the diversity of recipients (i.e.how many DNS caches their MX 
hosts use in aggregate) rather than the number of unique messages. For large 
mail systems this can mean that the queries to their authoritative servers 
tops out in the low thousands per day that is attributable to mail. If there 
is to be a mechanism that requires a unique query per message by the MX host 
for a recipient, the authoritative server will get no help at all from the 
existence of DNS caches. 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.
> > This is a concept that shares the fundamental flaws of SPF because it
> > presumes that people will change how they send mail to adhere to an
> > authentication protocol they know nothing about. It supplements that by
> > requiring all MUA's to change and by requiring all domain owners whose users
> > send mail to deploy new DNS infrastructure which will in many cases require
> > new functionality (authenticated dynamic updates) which most domains do not
> > currently use. All for a form of authentication that is inherently weak and
> > does nothing that existing authentication mechanisms could do if it weren't
> > so meaningless.
> >
> > You will note that at no point have I suggested that you are crazy.
> sorry but you are stup.....
OK, that's not a language issue. We're done here.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg