On Sat, Dec 20, 2003 at 08:49:42AM +0000, Wechsler wrote:
|
| Include/redirect are essential, IMHO, and skipping 'exists' is just
| lazy. I see no benefits to weakening the protocol at this point; I'd
| rather concentrate on the forwarding issues.
|
So the two major warts with SPF were
1) traveling mailman
2) .forward
We have managed to solve #1 using the exists mechanism. Only .forward
is left. This message surveys two classes of solutions.
SIGNATURE SOLUTIONS
Yahoo Domainkeys does not suffer from the .forward problem because it
puts a signature in the message headers.
Any other solution that transmits a signature is sufficient: for
example, an extension to ESMTP that passes a SIG=... argument, like so:
MAIL FROM:<foo(_at_)bar> SIZE=1234 SIG=g24grgaqrgqa3hq2hrgbear/rbrw
Others have suggested a new SMTP command. The effect is the same.
DomainKeys is icky because it happens too late: from an ISP point of
view, once the message has crossed the pipe and hit the CPU, the damage
has already been done.
An ESMTP extension is icky because it would have to be preserved across
the entire ESMTP chain, and is therefore impractical. Can't expect
everybody to upgrade their MTAs.
SENDER REWRITING
At Pobox, we are solving the problem by applying sender rewriting.
Instead of a signature, we're using a one-time cookie. Instead of
putting it in the message headers or an ESMTP argument, we're putting it
in the envelope sender. There's nowhere else for it to go.
Sender rewriting appears to be the best solution for MTAs, as it is
transparent to the end user.
If an MTA does not want to do sender rewriting, savvy users can apply
this workaround:
old: .forward: target(_at_)address
new: .forward: |/usr/bin/sendmail -oi target(_at_)address
This is like sender rewriting, but without the cookie.
We can restore the cookie if we publish an "srsforward" executable:
new: .forward: |srsforward target(_at_)address
This proposed srsforward would have the benefit of correctly handling
the reverse case, where a bounce needs to go back to the original
sender, and it would defy replay attacks.
Mail::SRS has been written, but not deployed. I will put it on CPAN
once we test it locally.
OTHER SOLUTIONS
.forward remains a problem. Can you think of any other classes of
solutions? What might work for you?
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡