Christian Grunfeld wrote, On 11/17/11 5:19 PM:
2011/11/17 John Levine<johnl(_at_)taugh(_dot_)com>:
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, <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.
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg