Re: antiphishing idea

> 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.

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.....