spf-discuss
[Top] [All Lists]

[spf-discuss] Forwarder whitelisting counter-proposal: SPF "i-am=" modifier

2008-01-08 19:57:26
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Deutschmann wrote:
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.

[... revamped TENBOX/E proposal ...]

This seems like a clever idea, however I seriously doubt forwarders would 
be willing to implement an SMTP/AUTH extension.

Don't get me wrong, I really appreciate your effort.  This is a tough nut 
to crack.  However, as long as a proposed solution takes even just nearly 
as much work to implement as sender rewriting it's just as dead-on- 
arrival. :-(

However, here's another idea how forwarders could identify themselves.  
Suppose a new SPF modifier named "i-am=" that works exactly like
"redirect=", with one addition: the modifier's argument, for example
"forwarder.org", can be considered an additional authenticated identity by 
the receiver if SPF evaluation passes for that domain.  The receiver can 
then use that additional identity to whitelist the sender.

For example, a forwarder says: HELO mta02.forwarder.org

The receiver checks "mta02.forwarder.org" for an SPF record, which yields

  "v=spf1 i-am=forwarder.org redirect=forwarder.org"

The receiver finds "i-am=" and ignores "redirect=" (which is there just in 
case the receiver doesn't implement the "i-am=" modifier).
They then check "forwarder.org" for an SPF record, which yields

  "v=spf1 a:mta01.forwarder.org a:mta02.forwarder.org -all"

The forwarder's IP address matches the SPF record, so the HELO SPF check 
passes and the receiver also has authenticated "forwarder.org" as an 
additional sender identity (also with a HELO scope), which they can 
compare against their HELO whitelist.

Works for mailing lists as well.  More importantly, it doesn't require 
forwarders to implement any new SMTP magic.  All they have to do is 
publish some new SPF records in DNS.

(I could have named the modifier "cname=" instead.  That would have been a 
nice analogy but would have confused the hell out of DNS experts.
And, before anyone wonders: yes, the redirection behavior of "i-am=" is 
essential because the authority over whether the specified identity is 
legitimate for the sender's IP address MUST be delegated to the owner of 
the identity, i.e. the admin of the identity's DNS zone.  The common SPF 
principle.)

Anyway, perhaps I'm just in a destructive mode today, so please consider 
this posting of mine a counter-proposal rather than a dismissal of yours.


Now on to the odds'n'ends:

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.

Why do forwarders need to be protected from in-transaction rejections?

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.

(This was once called AGUPI (assumed guilty until proven innocent) by Meng 
Weng "SPF" Wong.)

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.

I understand that this use case is served nicely by your revamped TENBOX/E 
proposal, but I don't think _we_ need to care about this use case and it 
barely justifies the implementation effort required by your proposal, 
especially as it can be solved by something as simple as:

  MAIL FROM:<ralph(_at_)example(_dot_)net:bounce> (or 
<ralph(_at_)example(_dot_)net(_dot_)bounce>)
  RCPT TO:<sarah(_at_)example(_dot_)com>

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>

Of course this only helps if the receiver has implemented TENBOX/E.  Do 
you expect everyone who has implemented greylisting to also implement 
that?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHhDbNwL7PKlBZWjsRAixsAJ9SUWDzXYoQ/jjB1PqYKVen21hlZgCeIqy2
4j5l4n490VUZtqbBzPrKuBg=
=QXXm
-----END PGP SIGNATURE-----

-------------------------------------------
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=83481295-74791e
Powered by Listbox: http://www.listbox.com