I'd like to put my TENBOX/E proposal back on the table, with a few
changes.
First, I'm changing the "marketing" to be more a whitelisting enhancement
with many uses, instead of just a solution to the forwarding problem.
I'm now thinking my Sham-SRS idea is the better approach to the
forwarding problem *as caused by SPF*, however forwarder whitelisting is
still a necessary idea. Sham-SRS protects the forwarder from SPF and
post-transaction bounces, but not in-transaction rejections.
So it might be a good idea to use a different acronym. "Substitute
Whitelist Key" covers what this proposal is really about.
(I initially thought of "Alternative Whitelist Key", but that would
hash-collide with a common unix utility. Also, the other expansion of
"sealed with a kiss" is perhaps not entirely inappropriate.)
Second, I'm changing the way a forwarder would use the proposal. Instead
of passing the original MAIL FROM unchanged and counting on TENBOX/E to
stand down SPF, the forwarder should simply rewrite the MAIL FROM to <>,
unless they are also using some sort of real SRS.
Third, I've added a way to probe for whitelisting.
So here's a draft:
TENBOX/E provides a means to attach a third envelope address to a given
e-mail. This third address, the Substitute Whitelist Key (formerly called
a "TENBOX token"), asserts the identity of the sender, but is not
guaranteed to be deliverable like the MAIL FROM. This allows senders to
direct bounces to addresses not familiar to the recipient, while still
identifying themselves to the recipient via the SWK.
(Note: It's possible Microsoft intended their PRA to be used as the
equivalent of an SWK. However, unlike PRA, SWK has no defined
relationship to the RFC 822 headers, and has no known patents.)
TENBOX/E works as a special pseudo-SASL method. No keyword is allocated
at present, but the word "TENBOX" will be used below.
On a recipient MTA that supports it, the initial authentication command
"AUTH TENBOX =" command will always succeed. It will have no pratical
effect however, except by enabling recipients to specify SWK via the AUTH=
argument to MAIL FROM:
A message carrying an SWK is only accepted if the sending MTA passes a
modified SPF check, using the SWK instead of the MAIL FROM. This test
must return Pass. The SWK will only be present and meaningful on the
smarthost-to-MX hop.
If an receiving MTA sees a message with a MAIL FROM: address under the
.invalid domain and a SWK, it is to return 250 to RCPT TO: commands if and
only if the particular SWK is valid (passes SPF) and is so trusted by the
given recipient that no spam filtering would be done. (The MTA probably
shouldn't accept DATA in that state, but that isn't a protocol
requirement).
By implementing TENBOX/E, an organization implicitly consents to
call-forward verification using the above technique. It does not however,
implicitly consent to any other form of callout, such as call-back address
verification.
Example usages:
The following examples use the characters:
Sarah, the sender <sarah(_at_)example(_dot_)com>
Ralph, the recipient <ralph(_at_)example(_dot_)net>
"Fred", a pseuonym of Ralph <fred(_at_)example(_dot_)org>
1. Forwarder whitelisting:
Example.org is very afraid of being blacklisted as a backscatter emitter,
and example.com has not deployed -all SPF records. Thus, should a mail
come from Sarah to Fred that is ultimately blocked en route to Ralph by
example.net, they would be in a pickle.
So they lay down the law with Ralph -- all forwarded mail is to be
delivered all the way. If a forwarded message is ever rejected
in-transaction, they will immediately start 450ing all attempts to mail
"Fred". This will continue until Ralph contacts them out-of-band and
tells them the problem is resolved, at which point they manually re-insert
the blocked message into their queue, and release the 450ing once it has
gone through.
Since both example.org and Ralph agree this would be a bad thing to
happen, they both implement TENBOX/E to prevent it.
When the forwarding relationship starts, example.org first does the
following:
MAIL FROM: <tenbox-test(_at_)invalid> AUTH=fred(_at_)example(_dot_)org
RCPT TO: <ralph(_at_)example(_dot_)net>
QUIT
If the RCPT command returns 550, they know the whitelisting is not yet in
place, and advise Ralph to fix it. If they get 250, they are in business.
Mail sent initially:
MAIL FROM: <sarah(_at_)example(_dot_)com>
RCPT TO: <fred(_at_)example(_dot_)org>
Is rewritten as:
MAIL FROM: <> AUTH=fred(_at_)example(_dot_)org
RCPT TO: <ralph(_at_)example(_dot_)net>
and is hopefully never blocked.
2. DSNs in a goldlisting universe:
One possible endgame in the spam wars is universal goldlisting, combined
with SPF. Goldlisting is the practice of configuring one's mail system to
reject all mail by default, only relenting when the MAIL FROM: address is
on a whitelist.
In such a universe, bounce messages will never work, as to prevent mail
loops, they always have a MAIL FROM of <>. SPF cannot defend this
address, so spammers would resort to it if goldlisters allowed it.
TENBOX/E comes to the rescue here, by allowing the bounce to be marked
with the address that failed:
So if Ralph's mailbox is full, a bounce to this message:
MAIL FROM: <sarah(_at_)example(_dot_)com>
RCPT TO: <ralph(_at_)example(_dot_)net>
comes as:
MAIL FROM: <> AUTH=ralph(_at_)example(_dot_)net
RCPT TO: <sarah(_at_)example(_dot_)com>
and reaches her even if she is using goldlisting.
3. Whitelisting a mailing list
The most natural "handle" to use when whitelisting a mailing list would
be its submission address. However, the submission address can never be
used as the MAIL FROM, as in the event of a bounce that would cause a
catastrophe worse than a mail loop. Mailing lists also tend to use VERP
these days, which defeats attempts to note a list's bounce address in
order to whitelist it.
With TENBOX/E, this problem can be resolved by having the mailing list
always use it's submission address as the SWK.
A mailing list can also now reliably confirm opt-in without disturbing
the user, by using the @invalid method to see if its submission address
is whitelisted.
One pratical example, which really happened recently, was with the
spf-discuss list itself. At the start of 2007, the list was using a
VERPed address under the "v2.listbox.org" domain. In September, it
abruptly shifted to "jeeves.archives.listbox.com", breaking my
whitelisting. The submission address didn't change, so if it had been
present as a SWK the problem would have been avoided.
4. Mitigation of ordinary-user VERPing (eg: SES, BATV):
Some users seek to use a form of VERP to protect themselves from
backscatter, accepting only direct mail to their principal address, and
directing the bounces to constantly-changing addresses.
Unless the receiving MTA has ad-hoc knowledge of how to derive the
principal address from the VERPed address, whitelisting and greylisting
are broken, or at least degraded to operating on entire domains instead of
mailboxes.
TENBOX/E allows whitelisting and VERP to coexist, since the SWK can
always be the principal address. An exchange of messages might go:
MAIL FROM: <sarah+32823667(_at_)example(_dot_)com>
AUTH=sarah(_at_)example(_dot_)com
RCPT TO: <ralph(_at_)example(_dot_)org>
MAIL FROM: <ralph+59458894(_at_)example(_dot_)org>
AUTH=ralph(_at_)example(_dot_)org
RCPT TO: <sarah(_at_)example(_dot_)com>
MAIL FROM: <sarah+20954045(_at_)example(_dot_)com>
AUTH=sarah(_at_)example(_dot_)com
RCPT TO: <ralph(_at_)example(_dot_)org>
MAIL FROM: <ralph+10998494(_at_)example(_dot_)org>
AUTH=ralph(_at_)example(_dot_)org
RCPT TO: <sarah(_at_)example(_dot_)com>
And work perfectly with greylisting and without ad-hoc decoding of
localparts. Sarah and Ralph can also whitelist each other, innocent of
each other's VERP.
5. All together now:
Suppose example.com has deployed -all SPF records, and example.org is
willing to use a form of SRS when the original message has an unambiguous
SPF pass. Sarah and "Fred" are both subscribed to
<list(_at_)example(_dot_)info>.
Everyone is using VERP, and everyone is goldlisting (the list has
subscriber-only posting).
Sarah sends a message to the list which is the decisive straw for Ralph's
mailbox quota.
So, Sarah first sends her message:
MAIL FROM: <sarah+23094054(_at_)example(_dot_)com>
AUTH=sarah(_at_)example(_dot_)com
RCPT TO: <list(_at_)example(_dot_)info>
The list explodes it. Among many sent messages is:
MAIL FROM: <fred%example(_dot_)org+37(_at_)example(_dot_)info>
AUTH=list(_at_)example(_dot_)info
RCPT TO: <fred(_at_)example(_dot_)org>
Example.org rewrites and forwards:
MAIL FROM:
<fred%example(_dot_)org+37%example(_dot_)info+77(_at_)example(_dot_)org>
AUTH=fred(_at_)example(_dot_)org
RCPT TO: <ralph(_at_)example(_dot_)net>
For some reason, example.net doesn't realize Ralph's mailbox has
overflowed until after the transaction, so they bounce:
MAIL FROM: <> AUTH=ralph(_at_)example(_dot_)net
RCPT TO:
<fred%example(_dot_)org+37%example(_dot_)info+77(_at_)example(_dot_)org>
Example.org reverses the rewrite:
MAIL FROM: <> AUTH=fred(_at_)example(_dot_)org
RCPT TO: <fred%example(_dot_)org+37(_at_)example(_dot_)info>
And then the list receives that and logs the non-deliverability of
"Fred". Note that the list didn't actually need to VERP, because the
information it wanted to preserve by VERPing is actually in the SWK.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=82526747-7d35d8
Powered by Listbox: http://www.listbox.com