-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of David
MacQuigg
Sent: zaterdag 26 februari 2005 21:47
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Email Forwarder's Protocol ( EFP )
The validity of the Return-Path depends on a fragile chain of
trust all the way back to the Source.
Return-Path correlates to the reverse-path (MAIL FROM entity).
If even one Relay is compromised, the Return-Path may be forged.
A forwarder doing SRS does not forge Return-Path; it just gets set along
the way, appropriately, to his new SRS address.
A Bounce to a forged Return-Path is a more serious problem.
That is the power of SPF. Although SPF, like Return-Path, relates to the
reverse-path, SPF gets to see the 'live' view of MAIL FROM entity. Which
is why I am currently only really interested in RFC 2821
authentication/authorization. SPF makes you not have to bother about the
validity of Return-Path (or any other header, for that matter).
I think we are in agreement on the necessity to not send
Bounces to the wrong domain. The key question is whether we
can trust the Return-Path after it has been through so many Relays.
Any and all information not added by your own MTA is inherently
untrustworthy, unless the message was digitally signed. Which is why I
believe checks against MAIL FROM entities are really best done at MAIL
FROM.
Overall, I feel that an MUA sending a bounce is actually acting 'out of
line' a bit. If his MTA has accepted the message, and made final delivery,
then the MUA should not try and second-guess that decision, and
start sending out bounces of its own.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx