On 30 Jan 2004 at 20:24, Meng Weng Wong wrote:
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.
Only for their own mail servers.
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.
Again only for their own customers. If the customer runs their own mail
server then the ISP does not touch the traffic. The customer has to
request that port 25 blocking be removed and that the ISP can test
their mail server to make sure it does not run as an open relay.
For users that must connect to their corporate mail server to send mail
they should do that using the MSA port 587 which I note that you stated
below. ISP can check their customers mail servers using the MSA port to
make sure that the port does not accept any mail unless authenticated.
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.
Agreed.
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.
I used to see port 25 blocking as a problem but I don't anymore. When
the MSA port 587 was created there was no longer a reason that Port 25
should be allowed for other than mail servers use. All current MUAs can
set their outbound ports so setting the port to587 is not a problem.
Even ISPs should block port 25 access from their own customers, unless
their approved to run a MTA, and require them to use the MSA port.
-------
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;±¤Ö¤Íµø?¡
----------------------------------------------------------------------
John Warren
+--------------------------------------------------------------------+
| Any and all use of my email address for bulk email without my |
| expressed permission is prohibited. This means NO JUNK EMAIL, SPAM.|
| Support the anti-Spam amendment, Join at http://www.cauce.org/ |
+--------------------------------------------------------------------+
-------
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;±¤Ö¤Íµø?¡