On Sat, 2004-10-09 at 01:53, Greg Connor wrote:
Keeping the same Submitter at an intermediate hop might result in a Fail.
And that's the point of SUBMITTER/PRA.
An MTA either:
o trusts the mail client to not lie about the Submitter, in which case
it won't reject the message due to an un-spf-authenticated Submitter
anyway--so there's nothing an honest client has to gain in dropping
the information, or
o doesn't implicitly trust all claims of the mail client, and thus
tests Submitter against the spf/SenderID record--so again an honest
client wouldn't want to drop the information.
The first case is a client-is-agent-of-recipient situation, and the
second case is client-is-an-agent-of-the-sender situation. In neither
case does censuring information (dropping SUBMITTER) gain either honest
party anything.
I think the case you're concerned about is when an incoming border MTA
in an organization continues to use the current SUBMITTER value even
when relaying to an internal final-destination MTA. IMO that final MTA
shouldn't be doing senderID checks anyway from the trusted border
MTA's--by definition they're trusted by IP or verified HELO name.
If they're dong SUBMITTER/PRA checks, then IMHO that's a
misconfiguration of their mail network, not a reason to drop SUBMITTER
at the border. (And recipients can't blocklist individual SUBMITTERs
pre-DATA if SUBMITTER isn't used.)
(I don't object to them doing MAIL FROM spf checks, since if the border
MTA does SRS rewrites anyway that won't cause any additional problems,
and organizations who want to log bounce rates from internal machines
would then be able to do so--and they'd then be able to detect or block
outgoing forged bounces.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com