Re: antiphishing idea

On 19/11/2011 06:54, Bill Cole wrote:
>> 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 !
> because I can have a proper configured domain, I can properly sign my
>
> 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. 

You're missing the point here.

If you sent a message like:

Message-Id: <[email protected]>
From: [email protected]

The receiving MTA would look for something like 
'12345-gmail.com._msgids.paypal.com'

It looks up the message ID in a zone related to the From address, NOT 
the zone related to the message id.

(I'm not saying there aren't other reasons against the original idea, 
but this isn't one of them)

Personally, I like the idea of a callback to validate that mail is what 
it says it is, but I'm not sure about using DNS as the callback mechanism.

> 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.
This is what I have problems with. Email at the moment is fundamentally 
flawed, because people send mail assuming totally lax authentication. 
10-15 years ago people used open relays and '% forwarding' all the time, 
but that changed, and people adapted. During the changeover period, lots 
of messages bounced, and people got frustrated (I had to deal with them 
all the time), but people quickly learned the 'right way' to do things 
(because they HAD to), and things improved.

  As long as the 'new authentication' method is implemented strongly, 
then people will adapt. IMV, the reason SPF doesn't work ATM is because 
even people who check it don't reject mail when they should. This lets 
badly configured systems 'sort of work' rather than failing totally. 
'sort of working' systems often stumble on with people getting 
frustrated, and maybe blaming the recipient rather than the sender. 
Failing totally would make the senders sort their stuff out.

Any new authentication method will have to make people change the way 
they work. The challenge is really finding one which will work 
effectively enough to make it worthwhile to need the changes. Rejecting 
solutions because they require changes to the way people work would have 
meant everyone would still be running open relays nowadays.