On Wed, 9 Jan 2008, Julian Mehnle wrote:
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.
I don't think that's a good use of 60-odd bytes of SPF record space.
Also, it fails in one common situation. Suppose two forwarding
organizations (or mailing list hosters) use the I-AM= proposal. Then, they
merge, desiring to keep both of their original domains in operation. They'd
like to use one mailserver to serve both domains without making their users
re-configure. Then which domain gets the "I-AM=" reference?
TENBOX/E easily handles this case, since the MTA can use an appropriate SWK
for each message.
I-AM doesn't handle the AGUPI or VERP-mitigation cases well. It can only
give a coarse-grained solution that will break whenever a mailserver serves
multiple domains.
Why do forwarders need to be protected from in-transaction rejections?
Because the forwarder fears being blacklisted as a backscatter emitter, if
an email arrives with neither SPF-pass nor SPF-fail, and cannot be delivered
forward.
(TENBOX/E will exploit this fear to get faster deployment on the forwarder
end. SRS ignores this fear, and in fact charges into it's eye, since it makes
post-transaction bounces just as bad as in-transaction rejects.)
To protect themselves, a forwarder can make a policy of freezing (not
bouncing or blackholing) the message in question, and then also freezing the
forwarding relationship until the ultimate recipient fixes his system to
never reject forwarded mail. Without TENBOX/E, the recipient can always cry
"That's no fair. How was my MTA to know that message was a forward?"
TENBOX/E gives a way.
[...] but I don't think _we_ need to care about [AGUPI] 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>
That still requires some kind of extension signalling, otherwise your
bounces will be rejected by legacy mailservers that detect you as forging a
domain that doesn't even exist -- or is a syntax error.
Also, accomodating AGUPI should be very important to SPF, since for many
people it is SPF's killer app.
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?
If SES or BATV takes off, they'll have to downgrade their greylisting to
only work on a domain basis, or put up with false-positive delays all of the
time. For some time also, SES/BATV users will have to put up with the same
delays, from users who don't mind them enough to give up mailbox-granular
greylisting.
TENBOX/E, when implemented by both sides, allows both to get timely
deliveries without giving anything up.
---- 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=83559913-a7c64b
Powered by Listbox: http://www.listbox.com