On Sun, 8 Apr 2007, Frank Ellermann wrote:
So as far as I'm concerned forwarders can use whatever they
like best wrt NONE or NEUTRAL. The SOFTFAIL scenario is as
always tricky, I propose to ignore SOFTFAIL for the moment.
The problem is that "whatever they like best wrt NONE or NEUTRAL" is to
simply not implement SRS, and insist that any forwarding failures due to
SPF at the recipient MTA are the recipient's fault.
Because of this, the fact that SRS would cause some pressure on the
forwarders to not accept SPF-fail is irrelevant, because nobody is taking
the bait.
I think those "entities" are stupid. At least for an SPF PASS
it's IMO obvious that the sender wishes to get DSNs (and other
auto-replies, where some excl. me draw the line at challenges.)
Call them stupid if you want, fact is they are *out there*. For the
moment, any entity afraid of backscattering SPF-fail messages will also be
afraid to backscatter SPF-none/neutral/softfail messages.
Hence, there are two kinds of forwarder. One kind doesn't worry about
their reputation as a backscatter emitter -- these will happily implement
SRS without any SPF checking. Another does care deeply -- these will
refuse to implement SRS at all.
Better make sure that forwarders using [TENBOX/E] MUST reject SPF FAIL
at their border (we can talk about a SHOULD :-), otherwise I'd
consider it as potentially harmful wrt what SPF does today.
That would forbid the possibility of a forwarding chain. Sure,
forwarding chains are a little bit daft -- but note that SRS takes pains
to optimize the case.
If the final recipient trusts the forwarder's TENBOX token
enough to stand down SPF, it would be silly not to also stand
down their content filters (SpamAssassin, ClamAV, DCC, etc.).
I doubt it. [ Users probably will be silly ]
Such conditions are the user's fault, not the forwarder's. The forwarder
shouldn't be punished for them, but that will always happen under SRS.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735