----- Original Message -----
From: "Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com>
Yes, but it is a problem with education for SPF checkers. The caution
senders have for publishing -all is misplaced. Instead, receivers
should be cautioned not to reject on SPF until they REALLY UNDERSTAND
what they are doing. They need to know and understand their forwarders,
including secondary MXs.
I am going to have to takes sides on this issue once and for all since I think
you have cross the line blaming implementations and receivers for SPF woes.
The problem is the protocol. If the PROTOCOL does not provide a technical
functional specification to implement or address what you consider are
"forwarded" related issues, then you can't blame no one else but the SPF
protocol itself.
The issue is both SENDER and RECEIVER. Both must make sure that each
compliment each other.
How will a SPF ready ISP/MSA handle an authorized USER using an alias name
(non-ISP related domain)?
The only proposed solution I've seen for this is SUBMITTER and hence, both the
SENDER, the MIDDLE WARE, and the RECEIVER must be compliant.
So if SPF has forwarding and alias problems, it is because the SPF protocol
failed to address it properly.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com