Re: antiphishing idea

Christian Grunfeld wrote, On 11/17/11 5:19 PM:
> 2011/11/17 John Levine<[email protected]>:
>>> Domains should have to publish in their DNSs the message-id (among any
>>> other thing) through a TXT or A record of any legit mail sent by them.
>>> The TTLs of those records can be adjusted to compensate for queued
>>> mails, etc.
>>
>> Maybe I'm missing something, but why would you want to do this rather
>> than a DKIM signature?  DKIM validates against the DNS, and protects
>> the whole message.
>
> because I can have a proper configured domain, I can properly sign my
> mails but I can send you an email with From: paypal.com header !
> DKIM does not protect you against this ! DKIM says that evil.com signs
> correctly the email and no alarms will trigger. The average user only
> see and "trust" the From: paypal.com mail header !

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, <[email protected]> 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 
<[email protected]>. 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.

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.

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.