Mailing List Archive

On Saturday 31 March 2007 18:17, Michael Deutschmann wrote:
> I thought of one way we could get the effect of a TENBOX/E ESMTP extension
> with less RFC-lawyering.
>
> (For those joining the list since the last discussions of TENBOX:
> "TENBOX" is a name coined by Julian Mehnle to refer to some kind of
> automatic system to make whitelisting of forwarders easy, solving the SPF
> "forwarding problem". TENBOX is presently just a stack of desired
> features with no concrete design yet.
>
> I've suggested that the best way to move towards a solution to the TENBOX
> spec is to split it into two protocols, TENBOX/E which allows forwarded
> mail to be associated with a nonvarying token that can be looked up in a
> recipient's whitelist, and TENBOX/O which helps nontechnical users manage
> a whitelist of such tokens.)
>
> RFC 2554, the AUTH extension for ESMTP, provides a little-used feature of
> an extra "AUTH=" parameter added to the MAIL FROM: command. This feature
> was intended so that a SMTP client could authenticate *itself* to another,
> yet indicate that a given mail's origins were either not authenticated or
> authenticated to be from somebody else.
>
> It bends the text a little, but I was thinking we might be able to
> register TENBOX as a special pseudo-SASL authentication type. This
> authentication type would never refuse the initial "AUTH" command, but
> would instead perform an SPF-like validation process on AUTH arguments to
> MAIL FROM:. If this process approves the argument (for the given sender
> IP), then that argument is used in place of the envelope sender for
> whitelist-checking purposes.
>
> The point of doing this (rather than pursuing a seperate ESMTP extension)
> is that there seems to be much less red tape involved in registering an
> AUTH keyword than there is in allocating an EHLO keyword.
>
> This does mean that TENBOX/E can't be used at the same time as another
> authentication method, but that shouldn't be a problem since most
> presently authenticated connections are already exempt from SPF.

OTOH, if you do it this way, you've got to change auth related libraries to
support the new method. I wonder how motivated they would be to expend
resources to implement new functionality that solves what is really a mail
transfer problem.

For initial experimentation would could use an X- ESMTP keyword without having
to go through all the RFC lawyering.

Scott K

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

Michael Deutschmann wrote:

> RFC 2554, the AUTH extension for ESMTP, provides a little-used
> feature of an extra "AUTH=" parameter added to the MAIL FROM

2554bis is in (or recently left) Last Call. I'm not aware of any
differences wrt AUTH= paramter, I think that's related to the SASL
concept "authz". Better check out if those vague assumptions are
related to reality. AUTH= could be also related to the famous
"enforced submission rights" in RFC 4409 6.1,

> This feature was intended so that a SMTP client could authenticate
> *itself* to another,

I'm not sure if that's the case, AUTH= is a MAIL FROM parameter for
individual messages.

> I was thinking we might be able to register TENBOX as a special
> pseudo-SASL authentication type.

Sounds a bit like the wild and wonderful SASL EXTERNAL mechanism :-)

> there seems to be much less red tape involved in registering an
> AUTH keyword than there is in allocating an EHLO keyword.

What's an "AUTH keyword" apart from the known 2554bis usage ? The
"red tape" for say the SUBMITTER keyword and parameter (RFC 4405)
wasn't too bad. In theory you could clone RFC 4405 replacing PRA
by what you need.

Or did you mean the "red tape" for new SASL mechanisms ? I think
that's considerably worse than registering SMTP extensions. BTW,
the SASL folks recently decided to ditch DIGEST-MD5, better ignore
the DIGEST-MD5 reference in 2554bis.

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

On Sun, 1 Apr 2007, Frank Ellermann wrote:
> > This feature was intended so that a SMTP client could authenticate
> > *itself* to another,
>
> I'm not sure if that's the case, AUTH= is a MAIL FROM parameter for
> individual messages.

You've misread the sentence -- here it is again with some extra
clarification in {}s.

"This feature was intended so that a SMTP client could authenticate
*itself* to another {using the ordinary AUTH command}, yet indicate that a
given mail's origins were either not authenticated or authenticated to be
from somebody else {using the AUTH= argument to MAIL FROM:}"

BTW, it's good for our purpose that AUTH= is per message, since this
would allow a forwarder MTA to collect messages which need different
TENBOX tokens attached and send them all in a single connection.

> Or did you mean the "red tape" for new SASL mechanisms ? I think
> that's considerably worse than registering SMTP extensions. BTW,
> the SASL folks recently decided to ditch DIGEST-MD5, better ignore
> the DIGEST-MD5 reference in 2554bis.

I'm just going by the fact that section 2.2.2 of RFC 2821 [ESMTP] says
regarding new ESMTP extensions:

# Each service extension registered with the IANA must be defined in a
# formal standards-track or IESG-approved experimental protocol
# document. The definition must include:
# [...]

While section 7.1.1 of RFC 4422 [SASL] gives a mail-in template requesting:

# SASL mechanism name (or prefix for the family):
# Security considerations:
# Published specification (recommended):
# Person & email address to contact for further information:
# Intended usage:
# Owner/Change controller:

So for ESMTP it seems one must submit to the RFC sausage-machine to bag a
keyword. Meanwhile, to reserve a SASL keyword, it's merely "recommended"
to have any spec at all...

---- Michael Deutschmann <michael@talamasca.ocis.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

Michael Deutschmann wrote:

> "This feature was intended so that a SMTP client could authenticate
> *itself* to another {using the ordinary AUTH command}, yet indicate
> that a given mail's origins were either not authenticated or
> authenticated to be from somebody else {using the AUTH= argument
> to MAIL FROM:}"

Yes, thanks, I missed the "yet..." part.

> it's good for our purpose that AUTH= is per message, since this would
> allow a forwarder MTA to collect messages which need different TENBOX
> tokens attached and send them all in a single connection.

What's a "TENBOX token" ? In the AUTH RFC the AUTH= parameter value is
an <addr-spec>. 2554bis fixes that to a <Mailbox> as secified in 2821,
eliminating the optional CFWS (comments, folding, white space) in 2822.

[SMTP extension]
> # Each service extension registered with the IANA must be defined in
> # a formal standards-track or IESG-approved experimental protocol
> # document.

Right, no SMTP extensions by independent submissions directly to the
RFC editor, or in other informational RFCs.

[SASL mechanisms]
> # SASL mechanism name (or prefix for the family):
> # Security considerations:
> # Published specification (recommended):
> # Person & email address to contact for further information:
> # Intended usage:
> # Owner/Change controller:

I've never looked at that one before, no expert review, first come -
first served, no RFC required. RFC 4422 let's IANA decide what they
like or don't like. Outrageous. Until today I thought that it's a
no-nonsense registry maintained by the SASL WG... :-(

> for ESMTP it seems one must submit to the RFC sausage-machine to
> bag a keyword.

At least that guarantees that there is a proper spec. (like 4405).
For the SASL registry it's only coincidence that nobody submitted
ROT13-LOGIN with "intended use: common" so far.

Well, you can apparently turn SPF PASS into a SASL mechanism if
that's what you really want. RFC 4422 recommends (lower case) an
I-D and public review. There are some simple "xml2rfc" examples
in the openspf repository, maybe start with...

http://www.openspf.org/svn/project/specs/drafts/draft-kitterman-spf-tbd-00.xml

...as template.

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

On Sun, 1 Apr 2007, Frank Ellermann wrote:
> What's a "TENBOX token" ?

It's the name of a forwarding relationship, which the forwarder gives to
the recipient, and the recipient gives to his mail admin to be entered
into a whitelist.

It has the syntax of an e-mail address (so that the right of a host to
assert a given token may be judged using SPF-like means), but is not
necessarily a deliverable mailbox.

In practice, it will often be simplest to use the forwarded-from address
as the TENBOX token, but this doesn't have to be the case.

---- Michael Deutschmann <michael@talamasca.ocis.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

Michael Deutschmann wrote:

>> What's a "TENBOX token" ?

> It's the name of a forwarding relationship, which the forwarder gives to
> the recipient, and the recipient gives to his mail admin to be entered
> into a whitelist.

> It has the syntax of an e-mail address (so that the right of a host to
> assert a given token may be judged using SPF-like means), but is not
> necessarily a deliverable mailbox.

> In practice, it will often be simplest to use the forwarded-from address
> as the TENBOX token, but this doesn't have to be the case.

Okay, let's see if I now understand the complete scheme:

1 - forwarder gets mail from x to user@fwd.example, this user arranged
to forward mails to him to user.next@hop.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.

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

7 - The forwarder says RCPT TO user.next@hop.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.

8 - If the forwarder says RCPT TO shit.happens@hop.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

9 - Some time later user.next@hop.example will find a mail from x via
fwd.example (= for user@fwd.example) in his inbox. It might have
an Received-SPF HELO PASS trace header field.

Is that the idea, or did I miss something ?

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

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@fwd.example, this user arranged
> to forward mails to him to user.next@hop.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@fwd.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.next@hop.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.happens@hop.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.next@hop.example will find a mail from x via
> fwd.example (= for user@fwd.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@talamasca.ocis.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

On Wed, 4 Apr 2007, Michael Deutschmann wrote:

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

That part seems superfluous to me. Why not just use the real
SPF record for the 'fwd.example' domain? I already do that without
the benefit of the proposed AUTH by just trying each forwarder in a
list in turn. That is obviously very inefficient, and the AUTH
protocol would reduce that to trying just one forwarder. So

+1 for AUTH=originaluser@originaldest.domain

and

-1 for special new SPF like record type


--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

Scott Kitterman wrote on Saturday, March 31, 2007 5:44 PM -0500:

> On Saturday 31 March 2007 18:17, Michael Deutschmann wrote:
> > The point of doing this (rather than pursuing a seperate ESMTP
> > extension) is that there seems to be much less red tape involved in
> > registering an AUTH keyword than there is in allocating an EHLO
> > keyword.

> For initial experimentation would could use an X- ESMTP keyword
> without having to go through all the RFC lawyering.

IIRC, this is similar to the SUBMITTER extension proposed a long time
ago. That raised many howls at the time.

--
Seth Goodman

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

On Thursday 05 April 2007 23:47, Seth Goodman wrote:
> Scott Kitterman wrote on Saturday, March 31, 2007 5:44 PM -0500:
> > On Saturday 31 March 2007 18:17, Michael Deutschmann wrote:
> > > The point of doing this (rather than pursuing a seperate ESMTP
> > > extension) is that there seems to be much less red tape involved in
> > > registering an AUTH keyword than there is in allocating an EHLO
> > > keyword.
> >
> > For initial experimentation would could use an X- ESMTP keyword
> > without having to go through all the RFC lawyering.
>
> IIRC, this is similar to the SUBMITTER extension proposed a long time
> ago. That raised many howls at the time.

The howls were because it was tied to PRA. Not because it was an ESMTP
addition.

Scott K

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

Scott Kitterman wrote on Thursday, April 05, 2007 11:01 PM -0500:

> On Thursday 05 April 2007 23:47, Seth Goodman wrote:
> > Scott Kitterman wrote on Saturday, March 31, 2007 5:44 PM -0500:
> > > For initial experimentation would could use an X- ESMTP keyword
> > > without having to go through all the RFC lawyering.
> >
> > IIRC, this is similar to the SUBMITTER extension proposed a long
> > time ago. That raised many howls at the time.
>
> The howls were because it was tied to PRA. Not because it was an
> ESMTP addition.

Both were issues.

--
Seth Goodman

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

On Friday 06 April 2007 10:34, Seth Goodman wrote:
> Scott Kitterman wrote on Thursday, April 05, 2007 11:01 PM -0500:
> > On Thursday 05 April 2007 23:47, Seth Goodman wrote:
> > > Scott Kitterman wrote on Saturday, March 31, 2007 5:44 PM -0500:
> > > > For initial experimentation would could use an X- ESMTP keyword
> > > > without having to go through all the RFC lawyering.
> > >
> > > IIRC, this is similar to the SUBMITTER extension proposed a long
> > > time ago. That raised many howls at the time.
> >
> > The howls were because it was tied to PRA. Not because it was an
> > ESMTP addition.
>
> Both were issues.

I think the biggest issue is that there has to be a motivation for a reciever
to believe something that the sender tells them during the ESMTP dialogue.
The identities associated with SPF (and even SID to a degree) and DK/DKIM can
be validated out of band (in DNS).

Submitter was just a hack to get you to go to DATA. Note that Submitter was
also the SID solution to the forwarding problem. How would a TENBOX identity
(regardless of if it's an AUTH parameter or an ESMTP keyword) be different?

Scott K

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

On Fri, 6 Apr 2007, Scott Kitterman wrote:

> The identities associated with SPF (and even SID to a degree) and DK/DKIM can
> be validated out of band (in DNS).
>
> Submitter was just a hack to get you to go to DATA. Note that Submitter was
> also the SID solution to the forwarding problem. How would a TENBOX identity
> (regardless of if it's an AUTH parameter or an ESMTP keyword) be different?

Because it can be validated out of band via SPF by comparing the connect
IP to the SPF record for the alleged domain in AUTH=. Without AUTH=,
you have to consult a list of possible forwarders, validating each one
(or compiling to IP sets with TTL). AUTH= just saves time by telling
you which forwarder domain to validate. Note that you would *still*
check that the domain is in the list of authorized forwarders.

This of this application of AUTH= as providing the real MAIL FROM
to validate instead of the forged MAIL FROM. This is similar
to SRS, except that bounces go to the original sender instead of
the forwarder.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

On Friday 06 April 2007 12:07, Stuart D. Gathman wrote:
> On Fri, 6 Apr 2007, Scott Kitterman wrote:
> > The identities associated with SPF (and even SID to a degree) and DK/DKIM
> > can be validated out of band (in DNS).
> >
> > Submitter was just a hack to get you to go to DATA. Note that Submitter
> > was also the SID solution to the forwarding problem. How would a TENBOX
> > identity (regardless of if it's an AUTH parameter or an ESMTP keyword) be
> > different?
>
> Because it can be validated out of band via SPF by comparing the connect
> IP to the SPF record for the alleged domain in AUTH=. Without AUTH=,
> you have to consult a list of possible forwarders, validating each one
> (or compiling to IP sets with TTL). AUTH= just saves time by telling
> you which forwarder domain to validate. Note that you would *still*
> check that the domain is in the list of authorized forwarders.
>
> This of this application of AUTH= as providing the real MAIL FROM
> to validate instead of the forged MAIL FROM. This is similar
> to SRS, except that bounces go to the original sender instead of
> the forwarder.

But then it still comes down to reputation. Unless I have a whitelist of
forwarders that I trust, it could be any random forger using this protocol.
While I can see that this might save overhead for the receiver (it's a
smaller lookup list), I don't see how it fundamentally changes anything?

I don't think receiver table lookup efficiency is enough to drive a new
protocol deployment.

Scott K

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

On Fri, 6 Apr 2007, Scott Kitterman wrote:

> > Because it can be validated out of band via SPF by comparing the connect
> > IP to the SPF record for the alleged domain in AUTH=. Without AUTH=,
> > you have to consult a list of possible forwarders, validating each one
> > (or compiling to IP sets with TTL). AUTH= just saves time by telling
> > you which forwarder domain to validate. Note that you would *still*
> > check that the domain is in the list of authorized forwarders.
> >
> > This of this application of AUTH= as providing the real MAIL FROM
> > to validate instead of the forged MAIL FROM. This is similar
> > to SRS, except that bounces go to the original sender instead of
> > the forwarder.
>
> But then it still comes down to reputation. Unless I have a whitelist of
> forwarders that I trust, it could be any random forger using this protocol.
> While I can see that this might save overhead for the receiver (it's a
> smaller lookup list), I don't see how it fundamentally changes anything?
>
> I don't think receiver table lookup efficiency is enough to drive a new
> protocol deployment.

In my small office deployments, I can get by with 2 or 3 forwarders
in a list, and check SPF (the "pretend" domain approach) for each one for every
connection (stuff will be cached, so it's not that bad). However, a large ISP
with millions of users and tens of thousands of forwarders can hardly
use this approach. Having a specific domain to validate is essential
for forwarder whitelisting.

However, there could also be a small list for each user, with SPF checks
delayed until RCPT TO.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

Scott Kitterman wrote on Friday, April 06, 2007 11:20 AM -0500:

> But then it still comes down to reputation.

Whether the recipient truly whitelists all of the forwarders content, or
the recipient still does content checks and tracks forwarder reputation
is a separate question. Whitelisting forwarders, and protocols to pass
forwarding domains, may only mean that they get another chance to
generate an SPF pass where the HELO and MAIL FROM do not pass.


> Unless I have a whitelist of forwarders that I trust, it could
> be any random forger using this protocol.

Not exactly. The random forger would need control of an IP that the
claimed forwarding domain lists in its SPF record. Making it per user
at the recipient would definitely make it less abusable, but it then is
the same effort as a recipient explicitly tracking all of its users
forwarding relationships. That is what tenbox or similar must address
to be useful. How would the tenbox system reduce the effort required by
recipient systems and their users to whitelist user forwarding
arrangements?

--
Seth Goodman

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

Michael Deutschmann wrote:

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

Strange. Why bother with this SASL mechanism if it does nothing at all,
and any random spammer claiming to be mailout-N.fwd.example would "pass"
the EHLO step ?

You could replace "AUTH TENBOX" by "AUTH ANONYMOUS" (RFC 4505) if the
whole purpose of this exercise is to enable later AUTH= parameters.

I'd prefer a new AUTH SPFHELO requiring a HELO PASS, i.e. something in
the direction of SASL EXTERNAL instead of SASL ANONYMOUS. Please note
that we're talking about receivers suporting SPF, they should check the
HELO-identity anyway: An SPFHELO SASL mechanism would reenforce this.

>> 6 - The forwarder says MAIL FROM x AUTH=user@fwd.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.

I've never heard of any v=tenbox1 records. What's the difference from
v=spf1 TXT or SPF records ? But yes, I've missed that step - you talk
about it as if a draft exists, please post an URL if that's the case.

If this AUTH=user@fwd.example is almost the same as Stuart's "pretend
MAIL FROM" we might talk about something that's really better than SRS,
so far I was only curious... :-)

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

That's from a forwarder's POV. From my POV as original sender I'm not
interested in any bounces for mail not sent by me, that's why I have
an SPF FAIL policy. Does TENBOX guarantee that forwarders reject any
SPF FAIL before trying their TENBOX forwarding magic ?

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

Well, for an account at one of the three largest email providers in my
country I've just enabled "reject SPF FAIL", and it promptly rejected
a forged mail from google on my behalf (claiming to be a mail from me).

It's one of those Google beta tests, the mail was an "invitation" to
a service for "ordinary" accounts (= my own mail address, not gmail).

What I really want to say, I'd insist that my next mail provider does
not only publish SPF FAIL, but also rejects it.

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

On Fri, 6 Apr 2007, Frank Ellermann wrote:

> If this AUTH=user@fwd.example is almost the same as Stuart's "pretend
> MAIL FROM" we might talk about something that's really better than SRS,
> so far I was only curious... :-)

It is the same as "pretend MAIL FROM", except that instead of trying
potential forwarders in a list, the forwarder tells you which domain
to validate. Much more efficient. The effect is similar to SRS,
but bounces go to the original sender instead of the forwarder.

There is no real need for a v=tenbox record. It was only proposed in case
the forwarder doesn't want to publish an SPF record for some reason, or
wants to publish a "v=spf1 -all" policy (perhaps because they never send mail
from their own domain, "fwd.example" in the example scenario).

> That's from a forwarder's POV. From my POV as original sender I'm not
> interested in any bounces for mail not sent by me, that's why I have
> an SPF FAIL policy. Does TENBOX guarantee that forwarders reject any
> SPF FAIL before trying their TENBOX forwarding magic ?

No, but only trusted forwarders would be on your list. And AUTH=
would only be accepted for forwarders on your list.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

On Fri, 6 Apr 2007, you wrote:

> Michael Deutschmann wrote:
>
> >> 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.
>
> Strange. Why bother with this SASL mechanism if it does nothing at all,
> and any random spammer claiming to be mailout-N.fwd.example would "pass"
> the EHLO step ?
>
> You could replace "AUTH TENBOX" by "AUTH ANONYMOUS" (RFC 4505) if the
> whole purpose of this exercise is to enable later AUTH= parameters.
>
> I'd prefer a new AUTH SPFHELO requiring a HELO PASS, i.e. something in
> the direction of SASL EXTERNAL instead of SASL ANONYMOUS. Please note
> that we're talking about receivers suporting SPF, they should check the
> HELO-identity anyway: An SPFHELO SASL mechanism would reenforce this.
>
> >> 6 - The forwarder says MAIL FROM x AUTH=user@fwd.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.
>
> I've never heard of any v=tenbox1 records. What's the difference from
> v=spf1 TXT or SPF records ? But yes, I've missed that step - you talk
> about it as if a draft exists, please post an URL if that's the case.
>
> If this AUTH=user@fwd.example is almost the same as Stuart's "pretend
> MAIL FROM" we might talk about something that's really better than SRS,
> so far I was only curious... :-)
>
> > 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.
>
> That's from a forwarder's POV. From my POV as original sender I'm not
> interested in any bounces for mail not sent by me, that's why I have
> an SPF FAIL policy. Does TENBOX guarantee that forwarders reject any
> SPF FAIL before trying their TENBOX forwarding magic ?
>
> > 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.
>
> Well, for an account at one of the three largest email providers in my
> country I've just enabled "reject SPF FAIL", and it promptly rejected
> a forged mail from google on my behalf (claiming to be a mail from me).
>
> It's one of those Google beta tests, the mail was an "invitation" to
> a service for "ordinary" accounts (= my own mail address, not gmail).
>
> What I really want to say, I'd insist that my next mail provider does
> not only publish SPF FAIL, but also rejects it.
>
> 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

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

(Ignore previous message -- it was a slip of a key...)

On Fri, 6 Apr 2007, Frank Ellermann wrote:
> I've never heard of any v=tenbox1 records. What's the difference from
> v=spf1 TXT or SPF records ? But yes, I've missed that step - you talk
> about it as if a draft exists, please post an URL if that's the case.

There's no draft.

It would be a similar concept to "v=spf2.0/pra" -- nearly identical
procedure to derive a result from a IP-address/email-address tuple, but
different implications of the result.

I suggested seperate "v=tenbox1" records because the set of computers
that send on forwarded messages may not be the same as the set of
computers authorized to send ordinary mail from a given domain.

For example, if "example.org" is a forwarding service, they might have a
very lax SPF record so that their customers are not forced to use them as
a smarthost, but they would want a tight TENBOX record so that customers
cannot take advantage of the "super whitelisting" to spam each other.

However, opinion on the list seems to be overwhelmingly in favor of
folding the extra meaning into the ordinary "v=spf1" records. I suppose
it might be doable if we specify that only "PASS" is good enough for
TENBOX, since such domains will probably use "?all"...

---- Michael Deutschmann <michael@talamasca.ocis.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

Again, it sounds like we need serious discussion of scoping as part of
discussions of SPV v3. Creating new v= for each such record when they
are similar is just waste of resources.

On Fri, 6 Apr 2007, Michael Deutschmann wrote:

> (Ignore previous message -- it was a slip of a key...)
>
> On Fri, 6 Apr 2007, Frank Ellermann wrote:
>> I've never heard of any v=tenbox1 records. What's the difference from
>> v=spf1 TXT or SPF records ? But yes, I've missed that step - you talk
>> about it as if a draft exists, please post an URL if that's the case.
>
> There's no draft.
>
> It would be a similar concept to "v=spf2.0/pra" -- nearly identical
> procedure to derive a result from a IP-address/email-address tuple, but
> different implications of the result.
>
> I suggested seperate "v=tenbox1" records because the set of computers
> that send on forwarded messages may not be the same as the set of
> computers authorized to send ordinary mail from a given domain.
>
> For example, if "example.org" is a forwarding service, they might have a
> very lax SPF record so that their customers are not forced to use them as
> a smarthost, but they would want a tight TENBOX record so that customers
> cannot take advantage of the "super whitelisting" to spam each other.
>
> However, opinion on the list seems to be overwhelmingly in favor of
> folding the extra meaning into the ordinary "v=spf1" records. I suppose
> it might be doable if we specify that only "PASS" is good enough for
> TENBOX, since such domains will probably use "?all"...
>
> ---- Michael Deutschmann <michael@talamasca.ocis.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

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

Stuart D. Gathman wrote:

> It is the same as "pretend MAIL FROM", except that instead of trying
> potential forwarders in a list, the forwarder tells you which domain
> to validate. Much more efficient. The effect is similar to SRS,
> but bounces go to the original sender instead of the forwarder.

Yes, and that's where I'm *V*E*R*Y* *I*N*T*E*R*E*S*T*E*D* With SRS it
is clear that forwarders take the responsibility for mails forwarded
by them as they should under RFC 821 rules (and explicitly did by
adding their identity to the reverse path in the pre-1123 world).

How does TENBOX guarantee that the alleged original sender in fact is
the original sender ? If it doesn't guarantee this it's a part of the
problem, like open relays, zombies, spammers, and phishers. I report
all bounces I get as abuse if they're not related to mail originally
sent by me. My justification for this approach is my SPF FAIL policy

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

> There is no real need for a v=tenbox record. It was only proposed
> in case the forwarder doesn't want to publish an SPF record for some
> reason, or wants to publish a "v=spf1 -all" policy (perhaps because
> they never send mail from their own domain, "fwd.example" in the
> example scenario).

The example was a mail from user@fwd.example to user.next@hop.example,
so claiming that fwd.example never sends mail would be stupid. That
the forwarder notes this fact as AUTH= instead of MAIL FROM in the
envelope is the private business of the user, the forwarder, and the
next hop. Clearly I didn't send mail from me using any IP of this
forwarder, the forwarder did this on behalf of user@fwd.example

As far as it really was mail from me they can do what they like, but
if it was forged I'm as I said very interested to stop this abuse by
all means, legal, illegal, or outright ugly.

>> Does TENBOX guarantee that forwarders reject any SPF FAIL before
>> trying their TENBOX forwarding magic ?

> No, but only trusted forwarders would be on your list.

If forwarders don't reject SPF FAIL and keep the forged mail from as
is they are by definition spam supporters, and the next hop better
rejects this crap. One of us needs more coffee, is it again me ?

Frank
--
In any case, the SMTP adds its own identifier to the reverse-path.
[RFC 821, section 3.6 "RELAYING"]


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

william(at)elan.net wrote:

> Again, it sounds like we need serious discussion of scoping as part of
> discussions of SPV v3. Creating new v= for each such record when they
> are similar is just waste of resources.

Different version tags for completely different purposes like v=spf1
or spf2.0/pra are in theory fine. It's bogus to add redundant version
tags like "spf2.0/mfrom", "spf2.0/mfrom,pra", and "spf2.0/pra,mfrom"
when nobody is inclined to publish (or look at) anything "mfrom" in the
first place, old MARID cruft we might need to cleanup.

A few abuses of v=spf1 for PRA are plausible, routes permitted for the
MAIL FROM are for all practical purposes also okay for a PRA. Routes
FAILing for PRA would be at least suspicious for MAIL FROM - that case
could be relevant for somebody abusing spf2.0/pra for MAIL FROM. It's
a theoretical case, but IMO still interesting for explanations why PRA
was a bad idea.

Otherwise version tags can be used for different purposes, the receiver
gets the complete SPF RR set with one DNS query, and can then pick the
record(s) it needs. The available space for the complete record set is
limited by UDP, that's a known problem.

"spf2.0/mfrom,pra only=pra ip4:1.2.3.4 only=mfrom ip4:5.6.7.8 -all"
"spf2.0/pra ip4:1.2.3.4 -all"
"spf2.0/mfrom ip4:5.6.7.8 -all"

Different records can be shorter than convoluted "scoping" ideas. My
example wasn't fair, but actually different tags can have a different
syntax. The spf2.0 legacy is an exception re-"inventing" the wheel for
mostly non-technical reasons.

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

Michael Deutschmann wrote:

> if "example.org" is a forwarding service, they might have a very
> lax SPF record so that their customers are not forced to use them
> as a smarthost

Okay, a "v=spf1 a ?all" variant, some IPs PASS, all others NEUTRAL.

> they would want a tight TENBOX record so that customers cannot
> take advantage of the "super whitelisting" to spam each other.

I'm not sure what that means. How can the "neutral" SPF policy be
abused in conjunction with the forwarding from user@fwd.example to
user.next@hop.example ? Any user2@fwd.example sending via other
routes will get a NEUTRAL, but that's no problem wrt the forwarding.

> opinion on the list seems to be overwhelmingly in favor of folding
> the extra meaning into the ordinary "v=spf1" records. I suppose
> it might be doable if we specify that only "PASS" is good enough for
> TENBOX, since such domains will probably use "?all"...

Adding syntax for an op=tenbox is trivial, defining the semantics is
the difficult part. For a now long dead idea compare op=trusted in
the 3rd "options" draft (the current version is 10+2=12):

The "trusted" property is only used by trusted forwarders.
This trust has to be pre-arranged between clients (forwarders)
and affected servers (destinations).

If a receiver recognizes the FQDN of a trusted forwarder in a
HELO or EHLO, it verifies its IP as specified for the similar
"helo" property (6.3.1). If the "trusted" property is present
in the corresponding sender policy, all further SPF checks for
the SMTP session are disabled.

A forwarder specifying the "trusted" property MUST implement
SPF checks for all forwarded mails. It MUST NOT forward mails
to destinations without prior arrangement, if that could
result in a SPF "Fail".

Without prior arrangement forwarders with a "trusted" property
MUST either use a sender rewriting scheme, or reject the mail
with error code 551. For details about error 551 see [STD 10]
and [RfC 2821].

If a forwarder with the "trusted" property is also a MSA, then
it MUST enforce submission rights as specified in [RfC 2476].

That idea was killed because no decent receiver would believe a
single word of it without a white-list, and as soon as there's a
white list it's pointless to note this in any *_sender_* policy.

The requirements however are still a MUST, nothing less will do
from my POV as alleged "original sender" with an SPF FAIL policy.

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