Here is one possible "extreme SPF" scenario. I do not expect the
average ISP to actually follow it to the letter, but it is useful for
keeping in mind as an ideal case. In practice there is friction due to
old email clients, etc, but we can't let the past hold back the future.
1) ISPs are expected to be the point of control for outbound mail.
Getting users to secure their machines is a lost cause. ISP SMTP
servers have to be responsible for performing virus and spam
filtering.
2) ISPs ensure that all end-user accounts are funneled through the ISP's
mail servers. They can either use SS or just block port 25.
Business DSL may or may not want to also take advantage of this
protection. This is already the recommended configuration anyway.
3) ISPs perform outbound virus filtering. This is not a hard problem.
4) ISPs perform outbound spam filtering. There are a number of
approaches: you can do content filtering or rate limiting (develop
usage profiles, throttle back if suddenly user suddenly sends 100 /
minute) or some other approach or combination of approaches. ISPs
keep up with the spam vs antispam evolutionary race by upgrading
their MTA pool.
5) ISPs are now responsible for blocking worms and viruses. Many worms
and viruses forge the return-path. Let's restate the goal as "ISPs
are now responsible for blocking forgeries" and see what that buys
us.
An ISP could require that outbound mail submitted through its servers
must contain the ISP's return-path.
This is a convenient way to prevent outbound spam and is not
inconsistent with ISP "crackdown" policies. Power users can work
around by submitting elsewhere to 587. Average users are using
webmail anyway.
6) If the ISP already has SMTP AUTH enabled, you get a bonus: you can
enforce that not just the domain but the entire return-path matches
the local user, whose name is known thanks to AUTH.
7) If requiring a local envelope domain is too draconian, ISPs could
waive the return-path restriction by performing *pre-emptive* SPF
checks on *outbound* mail. This solves the vanity domain problem;
all a vanity domain would have to do is indicate the ISP in some
form. If the SPF test passes, the outbound mail would be accepted
from the user and transmitted. In the simple case this is compatible
with (5).
8) The benefits of matching the return-path to the actual sending user
are as follows:
* bounces go to the right place; if a spam run manages to go out, the
resulting bounces will be contained in the user's mailbox and not
anybody else's. As sender address verification becomes more
popular, if a mailbox over quota the spam run becomes self-limiting
because nobody will accept the mail.
* you reduce liability (could envelope sender forgery be considered
libel or a CAN-SPAM violation? If a joe-jobbing virus/spam that
passed through an ISP's mail server deliberately forges a target
address rendering it unusable due to bounce volume, could that
target sue the ISP for negligence?)
* once you do this, you might not even need to put in outbound
spam/virus content filters; the return-path is a very good
approximation.
9) MUAs are encouraged to make the following changes:
* display the "responsible sender" header (from Caller-ID) as well as
the purported "From:"
* allow configuration of envelope return-path / Sender header as
separate from "From" address.
* display the "From:" in full, not just the name part. Phishing is a
tough problem. Consider the following scenario:
From: service(_at_)paypal(_dot_)com (PayPal Customer Service)
would be protected by some form of header authentication, but
From: badguy(_at_)spammer(_dot_)net (service(_at_)paypa1(_dot_)com)
meets or exceeds all technical requirements!
10) note: You can get around the unpalatable block-port-25 problem by
doing outbound transparent SMTP proxying in much the same way as ISPs
are already doing transparent HTTP proxying. The argument stands.
-------
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.5.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡