On Tue, Oct 07, 2003 at 01:09:09PM +0200, Justo Alonso wrote:
|
| Meng, please... can you write it ?!?!
|
The new draft is being written in committee fashion together with the
authors of RMX/DMP/DRIP/etc, which is why it's taking so long.
Right now I'm worrying over the .forward problem. I want to be sure it
can be reasonably solved; if it can't be solved, many people are going
to complain, and SPF will be mired.
So far I see three classes of solutions.
Scenario:
Phase 1: alpha(_at_)yahoo(_dot_)com sends mail to
beta(_at_)pobox(_dot_)com(_dot_)
Phase 2: beta(_at_)pobox(_dot_)com forwards to gamma(_at_)hp(_dot_)com(_dot_)
Problem:
Phase 1: Pobox tests SPF. Result: pass.
Phase 2: HP tests SPF. Result: fail.
Solutions:
1) SRS: change the envelope sender.
2) per-recipient custom whitelisting.
3) change SMTP, introducing a COOKIE as Saez has suggested.
* * *
Solution 1: SRS
Code:
use Mail::SRS;
Mail::SRS::set_secret("my secret");
my $sender = q"alpha(_at_)yahoo(_dot_)com";
my $alias = q"beta(_at_)pobox(_dot_)com";
my @rcpts = [q"gamma(_at_)yahoo(_dot_)com"];
my $newsndr = Mail::SRS::forward(sender => $sender, alias => $alias, rcpts
=> \(_at_)rcpts);
print $newsndr;
Result:
bounce-alpha#yahoo(_dot_)com-laNsR7A9Bb*sU(_at_)êBÚ??ñ? æó È?
This is not vaporware: Mail::SRS has been written and runs.
Solution 2: per-recipient custom whitelisting.
This solution was suggested by Ted Cabeen.
We can assume gamma(_at_)hp(_dot_)com knows that beta(_at_)pobox(_dot_)com is
forwarding to
him.
If he wants to get beta(_at_)pobox(_dot_)com mail, he can tell HP's MTA "if
you
get mail for me, if it comes from pobox.com's servers, let it
through." So hp.com's MTA would have to do two sets of SPF checks:
one on the envelope sender domain, and another on the domains
specified by the user. In this case, gamma(_at_)hp(_dot_)com would tell
HP.com's
MTA to also SPF-allow pobox.com.
This assumes pobox.com publishes SPF. If pobox.com does not publish
SPF, HP's MTA would return "unknown" and it would have to accept the
mail.
Solution 3: add some sort of call-back-to-sender cookie to the MAIL FROM
command.
This solution was suggested by David Saez.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200310/0049.html
It reflects ideas suggested by mjd
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200309/0017.html
And can be seen as an upside-down version of djb's IM2000.
This seems like a good idea but of course requires patching MTAs, and
at first glance relies on end-to-end support.
* * *
Evaluation of Solutions
1) pobox.com's MTA has to change: it has to do SRS.
2) hp.com's MTA has to change: per-user whitelisting is rare and
cutting-edge. To my knowledge only Colander supports it.
3) yahoo, pobox, and hp all have to change: cookies would be new to SMTP.
Possibility of Abuse
1) if a spammer gets hold of an SRS-encoded path, it can forge bounce
messages with MAIL FROM:<> that would go back to the original sender.
spammers can do this in a number of ways: SRS-encoded return paths
could be exposed on web archives. Or a spammer could sign up for a
pobox account, forge a message from alpha(_at_)yahoo(_dot_)com, receive it,
and
then spam via pobox.
To solve this, SRS cookies --- the laNsR7A9Bb*sU part of the new
sender --- can be expired over time (eg. after one week) or by the
number of times they've been used.
Expiring SRS cookies is fine if the rewritten sender addresses are
only used as a return path. However, some overzealous mailing list
software use envelope senders as subscription addresses.
2) less open to abuse.
3) less open to abuse.
-------
Sender Permitted From: http://spf.pobox.com/
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/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡