spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Re: TENBOX/E as an AUTH type

2007-04-08 21:01:02
On Sun, 8 Apr 2007, Scott Kitterman wrote:
Yep.  SRS transfers a final recipient bounce to a forwarder bounce, but
without SRS final recipient rejects still result in forwarder bounces.
Forwarders reliably getting backscatter control correct is pretty well
impossible no matter what we do here.  It's one of the reasons I think the
days of transparent forwarding are numbered.

I concede SRS exacerbates the problem rather than creating it.

But TENBOX/E has the potential to reduce the problem.  The problem can be
eliminated if there is no tomfoolery at the recipient.  Even if there is
tomfoolery at the recipient (defined as 5xx-ing forwarded mail, or 4xx-ing
it for an extended time), the forwarder can avoid bouncing with a little
nerve.  (For better flow of my argument, I've moved the paragraph 
describing how to apply "nerve" to the bottom of the message.)

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.

Absolutely not.  Not Forged != Not Spam/Phish/etc.

Mail that is forwarded and caught late by SpamAssassin et al. probably
really is "bad mail".  But it's still "silly" to reject it for another
reason.

It is irresponsible for an ISP to silently discard mail (which has a tiny
chance of being an FP) or create backscatter.  It's equally irresponsible
to force someone else to backscatter, which is what happens when forwarded
mail is content-filtered.  The lesser evil is to let the recipient "eat
his spam".

Now, with traditional forwarding or SRS forwarding, the recipient MTA
cannot detect which messages are forwards, so we can't really blame it for
following the same rules it must apply to normal mail.  (At the moment,
you can probably assume any mail from an <SRS[0-9]=*(_at_)*> address is an SRS
forward, but that'll change fast if such messages get treated
specially...)

But under TENBOX/E, once the MTA has validated the TENBOX token and found
it on the recipient whitelist, it *KNOWS* that the message is indeed a
forward, and that blocking it *even if it is indeed spam* will just push
the "backscatter or drop" dilemma on someone else acting in good faith.



Now, as promised above, what a TENBOX/E forwarder can do when faced with
in-transaction rejections of the forwarded mail:

Instead of bouncing, he can freeze the rejected message and any others
"in flight", and set a flag so that any message to the forwarding input
address gets 4xx-ed.  Then he sends an out-of-band message to the
recipient saying "There is a *serious configuration error* at your ISP --
our TENBOX token isn't whitelisted.  Let us know when this is corrected --
your forwarding is disabled until then".  Once the recipient indicates the
problem is fixed, the forwarder can re-queue the messages.  If they all go
through, then he unlocks the input address.

---- 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