Re: when spoofing isn't
2004-03-19 14:08:58
On Fri, Mar 19, 2004 at 12:07:32PM -0800, Greg Connor wrote:
My guess is that RFC2821 MAIL FROM will match From: or Sender: most of
the time. But, spammers/phishers are crafty- if MAIL FROM /
Return-Path validation starts in earnest, they may start to diverge
from this. Spammers will change their behavior a lot faster than admins
will update their normal MTAs. If we want to validate RFC2822 From:
address as Phase 2, let's start this research now. If we can
anticipate the logical "next move" by the spammer we can be ready.
--"Mark C. Langston" <mark(_at_)bitshift(_dot_)org> wrote:
But here, you assume that the RFC2822 identities would be the logical
next target. I'd think that the spammers would be more likely to take a
less subtle approach and try to subvert the authorization mechanism. In
the case of several approaches, this would mean DNS poisoning, denial of
service attacks against nameservers, and other such trickery.
I'm assuming that RFC2822 is "a" logical next target, but not the only one.
It is possible for spammers to use a different domain in the envelope than
what's in the data, but it's not the only reaction possible. The other
reactions you stated are quite possible too, as well as others. (Also,
spammers will not move as a group, they will probably move in ALL available
directions at once :)
There is a good reason for checking RFC2822 From: - that is, it is highly
visible to the user. If we plan to start protecting that, sometime in the
future, we might benefit a great deal by finding out where it already
matches RFC2821 MAIL FROM and warning the user if it starts to NOT match.
But, I'm not actually suggesting anything to be done with RFC2822 headers
right now, apart from researching what patterns exist now.
How do people feel about coming up with a draft RFC that focuses on RFC2821
MAIL FROM first and following up with a DATA/Headers extension to it later?
Can we have multiple draft RFC's come from the same working group?
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
|
|