Michael Deutschmann wrote:
SRS also forces them to either "sign off on" or refuse to
accept SPF-neutral, SPF-none, and SPF-softfail mails. This
just isn't reasonable today.
Anything NONE or NEUTRAL is less interesting from my POV, my
policy guarantees PASS, FAIL, or - shit happens - TempError.
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.
Entities that punish backscatter, such as UCEPROTECT, generally
believe that backscatter should be prevented by abolishing DSNs
entirely, not by sender validation.
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.)
I also like to get "false positives" caused by checking SPF at
the wrong place (behind the border). If it's a bogus bounce I
report it as spam (the receiver had a fair chance to reject the
FAIL at their border). If it's a bounce related to mail I sent
I can try to send it again on another route (= 551 emulation).
Both cases (bogus bounce or 551-emulation) are very rare at the
moment. Apparently spammers avoid to forge my FAIL-protected
vanity host, therefore forwarders also won't get in trouble by
missing an opportunity to reject it at their border. Apparently
it's also very rare that receivers check SPF at the wrong place,
my complete number of pseudo-551 bounces is still one.
Clearly I'm interested to keep those numbers for simple PASS/FAIL
SPF policies where they are, introducing new loopholes would be
a bad plan from my POV.
for an SRS forwarder, abolishing DSNs entirely just isn't
possible.
I'm not sure what your model for SRS is. My model is a mailing
list with one subscriber (the forwarded-to address). Any DSNs
from hops behind the forwarder are not really my business, or
rather they are only my business if the forwarder decides that
I should know what went wrong.
There's also a privacy issue, a long section in RFC 2821, why
routinely using 251 might be not what the receiver wants. As a
simple example, maybe you use an @gmail address in public, and
forward whatever survives the Gmail filters to a less protected
address at another provider. Then you're not interested that I
learn the "direct" route and add it to my address book, because
this address book is later visible for any trojan I install.
For that reason you might also decide that DSNs from anything
behind your forwarder aren't for me. Almost the same idea as
for mailing lists.
How does TENBOX guarantee that the alleged original sender in
fact is the original sender ?
It doesn't. But TENBOX/E mail will very rarely be bounced, if
at all.
Better make sure that forwarders using it 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.
These "rare bounces" would include any "vacation" mails or other
auto-replies sent by the user. I'm interested to get it if the
mail triggering any auto-reply was a PASS at the border, and I
consider it as spam if it was a FAIL at the border (forwarder).
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.).
And content filters are the leading cause of forwarder bounces.
I doubt it. It's a clueless user arranging the forwarding, they
will cause havoc behind the final delivery MTA with their own
MUA if necessary. Report their own forwarder as spammer is one
example discussed here sometimes. Maybe there's a Web form where
they can configure a "sieve" working behind the border of the
next hop... <shudder /> If anything can go wrong it will go
wrong, we're lucky if some implementors understand what they do:
One early wannabe-SPF plugin allowed to bounce FAIL at the MUA.
Fortunately we could convince the developer that this is a bad
plan. Somebody implemented "barracuda". Another typical case
is "symantec". Some early "messagelabs" bounces told me that I
should publish a FAIL policy when I already had one, and they
bounced the forged mails to me. I got thousands of challenges
from earthlink, spamarrest, and a Brasilian provider (in 2004).
Trying to offer an alternative to SRS is a good thing, but it
should then preserve the basic feature of SPF: Reject FAIL at
the border (in this case at the border of the forwarder).
AFAIK I'm the _only_ user on the spamcop list who thinks that
an SPF FAIL is required, the others report all bogus bounces
right away, no questions asked.
They probably think the answer is to abolish bounces entirely.
Yes, some do. But I think some also try to avoid the necessity
of publishing a FAIL policy, because that would force them to
change their provider, and/or take the responsibility for FAIL
effects caused by inappropriate forwarding arrangements. Some
also believe in the FUD spread by interested parties, because
that's easier than to understand how email really works. Last
but not least the SC management failed to limit bounce reports
to users publishing a FAIL policy when they introduced this new
feature (misdirected bounce => spam) in January 2005...
Then the SPF status of a given mail is irrelevant.
...precisely the problem with those "entities". SPF works fine
without worldwide adoption by receivers, but it's in trouble if
senders try to get away without it. IMO SMTP is far too simple
to survive without (good) DSNs, there's too much that can go
wrong behind the border of the receiver (even after replacing
all unnecessary bounces by rejections as soon as possible).
Frank
-------
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