Re: [Asrg] antiphishing idea
2011-11-19 10:40:15
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: <12345(_at_)gmail(_dot_)com>
From: info(_at_)paypal(_dot_)com
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Asrg] antiphishing idea, (continued)
- Re: [Asrg] antiphishing idea, Christian Grunfeld
- Re: [Asrg] antiphishing idea, Bill Cole
- Re: [Asrg] antiphishing idea, Christian Grunfeld
- Re: [Asrg] antiphishing idea, Bart Schaefer
- Re: [Asrg] antiphishing idea, Chris Lewis
- [Asrg] Please behave yourself on the ASRG list, John Levine
- Re: [Asrg] Please behave yourself on the ASRG list, Andrew Kirch
- Re: [Asrg] antiphishing idea,
Paul Smith <=
- Re: [Asrg] per message databases, was antiphishing idea, John Levine
- Re: [Asrg] per message databases, was antiphishing idea, Steve Atkins
- Re: [Asrg] per message databases, was antiphishing idea, Bart Schaefer
- Re: [Asrg] per message databases, was antiphishing idea, Steve Atkins
- Re: [Asrg] per message databases, was antiphishing idea, John Levine
- Re: [Asrg] per message databases, was antiphishing idea, Chris Lewis
- Re: [Asrg] per message databases, was antiphishing idea, Paul Smith
- Re: [Asrg] per message databases, was antiphishing idea, Chris Lewis
Re: [Asrg] antiphishing idea, Steve Atkins
|
|
|