RE: Can you ever reject mail based on RFC2821 MAIL FROM?

--Harry Katz <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> wrote:
> > From: Greg Connor [mailto:gconnor(_at_)nekodojo(_dot_)org]
> >
> > trusted-forwarders.org is such a whitelisting service, and it seems to
> work.
> >
> This may be a fine list during early development or beta testing.  But
> are you suggesting this needs to be a permanent part of the MARID
> solution?  Based on the experience of similar list providers, I would
> guess that both DDOS attacks and litigation will follow.

I can imagine a time when forwarders all do what I think is the "right" 
thing, and take responsibility for their own bounces, rather than passing 
messages along with a return path that goes to someone else (and in many 
cases, that they didn't even verify).
This will require a bit of time and hard work, but I think it's worth the 
effort.
The trusted-forwarder.org list is intended to be a shorter-term measure, to 
get forwarders "over the hump" so to speak.  It should be phased out in 
time, to encourage people to forward "more correctly".
In a "better world" it will be possible to reject on only the MAIL FROM, 
and whitelisting will not be needed.  For now I would rather deal with the 
hassle of whitelisting than continue to deal with (and pass on) bounced 
forged mail.


> > I'm certainly willing to have a reasonable discussion here,
> > but if you're
> > going to be evasive, dismissive, or continue to take a
> > condescending tone,
> > I'm going to choose to focus my time on responding to
> > *sincere* discussion
> > rather than your style of discussion.
> >
> > Perhaps you're not being "deliberately" abrasive, but I think
> > if you wanted
> > to tear this group apart from the inside you're making an
> > admirable start.
> It's not my intent to be condescneding or abrasive and I apologize if my
> words came across that way.

OK.  My apologies if I'm reacting to something that's not there.  I get 
sort of a negative vibe from the thread, because I feel you're dismissing 
other conflicting opinions unfairly, but I'll accept that you're not 
intending to be insulting, condescending, etc.
I'll try to hold up my end of the discussion and set my feelings aside for 
the time being...

> What I am trying to do is draw attention to the fact that relying solely
> on 2821 MAIL FROM as a way to both reject lots of mail and prevent false
> bounce messages carries serious risks  and relies for its effectiveness
> on near universal adoption of SRS or similar schemes.

SRS is not the only solution to forwarding woes, but it's probably the best 
and may end up being the most popular.  Whitelisting will probably always 
be part of the equation, especially for machines within the same 
organization.
I know this will not come about quickly or easily.  I don't want to 
reinvent email as we know it, but I also don't want to leave it totally 
alone.  I would like this group to strike a balance between "not changing 
anything that works now" and "steering people toward better practices for 
the future".
My gut feeling is that a forwarder (really an agent for the receiver and 
not related to the sender) should not be asserting the sender's identity, 
in MAIL FROM or otherwise.  If the forwarder is allowed to pass along the 
existing MAIL FROM, they can also forge messages with my return path and 
cause bounces to be sent to me, even if my domain is not mentioned in any 
2822 header.
So.  SPF (or some MAIL FROM scheme) is part of my desired/imagined future, 
and in my mind, whitelisting is a way to get there but it's not the 
ultimate destination.

> I have also been trying to draw attention to the fact that we can't
> succeed in restoring user confidece in the mail system unless we attack
> the phishing problem.  Likewise, we must provide a mechanism for
> legitimate senders to protect their brands from such fraud.  That means
> we also need to look at the 2822 headers.  In this context I do agree
> with your point on another post that it's critical that domains are able
> to express a single policy that covers both 2821 and 2822 validation.

Thanks.  I think most folks here agree that BOTH the MAIL FROM and 
From:/Sender: need to be protected.  I am a strong advocate of SPF but it's 
not the ultimate anti-forgery scheme, only a part of an overall picture. 
Hopefully we can solve everyone's requirements with a single/consistent 
policy... it may be more difficult but I think everyone will be happier.

I'm going to go off on a tangent for a bit, regarding "pick and choose" 
algorithms...
I am a little bit uncomfortable with proposals that have an "algorithm" to 
pick the "one true identity" that needs to be validated in any given 
message.  Perhaps our best guess will leave out some messages to not be 
validated at all.  Perhaps an algorithm will pick an identity and validate 
it (like Sender:) and the user will still be misled and think it's a 
forgery.  Perhaps spammers will get smart and start varying 
From:/Sender:/MAIL FROM even in places where they are fairly consistent 
today.
Instead of "pick and choose one identity to verify", we might instead 
choose to consider each field on its own, and give the receiver some 
recommendation on how to validate that one field.  Then they can pick and 
choose which fields to validate.  HELO, MAIL FROM, From: and Sender: could 
all be checked independently.  There might be different effects, too... the 
From: field checks out OK when the message is direct from a trusted source. 
If the Sender: field checks out OK, but not the From, the user might see a 
"As relayed by imc.org" message instead of the "Direct Verified" message. 
MAIL FROM or HELO checking might not alert the user of anything, but could 
be used to reject, filter, or in some cases bypass filters if the name is 
known and trusted.
OK that's all for now.
gregc

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>