spf-discuss
[Top] [All Lists]

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

2007-04-04 15:04:19
On Wed, 4 Apr 2007, Frank Ellermann wrote:
Okay, let's see if I now understand the complete scheme:

1 - forwarder gets mail from x to user(_at_)fwd(_dot_)example, this user 
arranged
    to forward mails to him to user(_dot_)next(_at_)hop(_dot_)example

2 - one of the mailouts of the forwarder connects with one the MXs of
    hop.example, mumbling something like EHLO mailout-N.fwd.example

3 - The MX of hop.example announces AUTH with a SASL mechanism TENBOX
    (or maybe SPFHELO) as one of its supported SMTP extensions

4 - The forwarder picks AUTH TENBOX (or maybe AUTH SPFHELO)


5 - The MX checks the SPF policy of mailout-N.fwd.example, expecting a
    PASS for the HELO.  If that's the case it accepts the AUTH (end of
    the SASL business, a kind of EXTERNAL mechanism).  Any other SPF
    result kills the AUTH.
TENBOX/E doesn't care about the HELO argument.  The "AUTH TENBOX" command 
always succeeds.


6 - The forwarder says MAIL FROM x AUTH=user(_at_)fwd(_dot_)example (or 
another
    kind of "TENBOX token"), the MX accepts it on probation.

You've missed the most important step:

6a - the MX looks up a "v=tenbox1 ..." TXT record for fwd.example (or
whatever the domain part of the TENBOX token was), and does something
very similar to SPF with it.  If the result isn't PASS, then the MX has
detected a "meta-forgery" and should probably just 5xx the message.

7 - The forwarder says RCPT TO user(_dot_)next(_at_)hop(_dot_)example, and 
the MX is
    supposed to know that this mailbox is willing to accept the given
    "TENBOX token", in other words the MX now skips its SPF MAIL FROM
    check and accepts the RCPT TO.

And the MX should probably skip any other spam defenses or reputation
adjustments.  The main reason TENBOX/E might be expected to do better than
SRS is that it can lessen backscatter and reputation-blackening effects
that presently occur when a bad mail (spam, virus, etc.) gets past a
forwarder's own defenses but is detected by a downstream MX server.  So
forwarders have an incentive to deploy it.

In contrast, SRS solves only one problem forwarders have, which the
forwarder can more conveniently solve by simply insisting that the
recipient not use SPF.

8 - If the forwarder says RCPT TO shit(_dot_)happens(_at_)hop(_dot_)example 
the MX
    would check the MAIL FROM and likely reject it if it has an SPF
    FAIL policy not permitting the IP(s) of mailout-N.fwd.example
Right.

Actually this brings up one fuzzy bit of the specification -- what to do
when the TENBOX token is valid but not in a given recipient's whitelist.

One idea would be to block the message in such a case, giving a forwarder
a warning that he isn't actually whitelisted, and may want to contact the
recipient out-of-band to correct that situation before forwarded spam
blackens his IP reputation.

But another is to just follow normal mail policies, as you've suggested
above.  I'm lately thinking this is the way to go, because it allows an
auxiliary use of TENBOX/E.  A sender who VERPs could use TENBOX/E to
provide a nonvarying "principal" e-mail address to the recipient MX, which
might not accept bounces but is more likely to be in the recipient's
whitelist.

Similarly, it could be used to allow bounces to get through in a
"goldlisting" situation, where only whitelisted sender addresses get
through.  Bounces always have an envelope sender of "<>", which is useless
for whitelisting.  A "goldlisting" MX thus has to assume the worst of <>
mail and reject all bounces.  But with TENBOX/E, a mailserver could be
programmed to include the failed-original-recipient address as the TENBOX
token alongside the <> bounces-to address.  So a bounced mail originally
directed at a whitelisted person can get through.
 
9 - Some time later user(_dot_)next(_at_)hop(_dot_)example will find a mail 
from x via
    fwd.example (= for user(_at_)fwd(_dot_)example) in his inbox.  It might 
have
    an Received-SPF HELO PASS trace header field.

I'm not going to get into the question of whether including Received-SPF:
headers for the HELO is a good idea or not.  The mailserver will or will
not do that according to it's own policy, TENBOX/E doesn't care.

Although it might be a good idea to standardize a "Received-SPF: exempt"
value for the MX to use in place of the MAIL FROM result.

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