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 ! MUAs SHOULD
submit emails to an MTA who is in charge of the transport for a
domain. 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.
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?
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.....
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg