> Neil's answer:
> [...]
> I always use the relevant ISP's outgoing SMTP server, so when I'm
> connected to the BTYahoo ADSL gateway I send emails through
> mail.btinternet.com, when connected via the NTLHome wireless gateway I
> send emails through smtp.ntlworld.com, and when connected via the
> Virgin dial-up gateway I send emails through smtp.virgin.net.
>
> I regularly do things like sending from my BTYahoo address via the NTL
> server, and vice versa - which is all perfectly acceptable as far as
> normal, courteous, non-spamming internet usage is concerned.

What Neil is doing will become more and more difficult. With the recent ceasing of hostilities between the Microsoft Caller_ID and the SPF camps (Sender Policy Framework - http://spf.pobox.com), ISPs are starting to implement sender verification of email. For example, AOL is already using SPF, and Hotmail is using Caller_ID. BT and Yahoo have signalled intent to use SPF as well as Yahoo's 'domain keys' cryptographic signature solution (see http://docs.yahoo.com/docs/pr/pdf/asta_soi.pdf ). As of version 3 (this summer), Spam Assassin will do SPF checks as part of computing a message's spam score. SPF has become part of the landscape.

What is SPF? It is a method to (try to) detect mail forgeries by verifying that a message was really sent from the domain listed in the From: address. The domain owner publishes via DNS a list of IP addresses (expressed in various forms) of machines that are acceptable message sources for the domain. A receiving machine asks for that list, then verifies that a sending machine is on it. By default, a message arriving from a machine not on the domain-owner's list is assumed to have a forged sender and is immediately rejected. As 99% of spam fits this pattern, the technique neatly identifies and tosses spam.

To illustrate, the mail system I run uses SPF and Spam Assassin. As of today, the combination correctly identifies around 98% of the spam entering our mail server. Approximately 85% of the messages are rejected on entry, with the remaining 13% marked as spam but delivered. Before adding SPF, the percentages were approx 95% identified, 70% rejected, and 25% marked and delivered. In other words, today SPF helps somewhat when identifying spam, but helps enormously when deciding to reject a message outright. As more and more sites publish SPF records (some 21,000 domains are known to have done so), the % identified and % rejected numbers will both go up.

Unfortunately, SPF is not without cost. A problem arises if one sends a message through an ISP that is not the one named in the message sender's 'from' address (as Neil is doing). The same problem arises if the message is sent through a private mail server. Clearly ISPs will not name each other as authorized senders, so there is a rapidly-increasing probability that a message will be rejected by the receiving mail server because it originated on a non-approved machine. This situation already exists because of the various RBL (real-time black hole) anti-spam lists (these are why mail from private servers is often trashed), but SPF/Caller_ID will make the problem much worse.

The SPF/Caller_ID-recommended way to avoid getting your mail bounced as spam is to *always* use the machine authorized for your domain as your outgoing mail server. Unfortunately, doing so can be difficult, as many ISP's authorize mail relaying based on IP address; you must be connected to their network to use their mail server. On the plus side, more and more ISPs are providing authenticated SMTP support, permitting one to transfer mail even if not connected to the ISP's network. This is done using an alternate mail submission port (port 587), normally encrypted using SSL.
Connections to this port must be authenticated, permitting the ISP to both have confidence that the sender is authorized and to know who to shut down if the sender has been compromised or is a spammer.

The email consortium (AOL, Hotmail, Yahoo, etc) recommends that a user take the following steps:

1. Ensure that your mail user agent (your mail client - Eudora, Outlook,
etc) supports TLS (encrypted mail delivery).

2. If your ISP supports authenticated mail transfer, use it. While you are at it, see if the ISP supports encrypted mail reception and, if so, use that as well. If the ISP doesn't support authenticated mail transfer, lobby them. If they refuse, change ISPs.

3. Ensure that you use the outgoing server that corresponds to the return address you are using. This is especially important if you use multiple addresses.

A final note: owners of vanity domains will be particularly hard-hit by SPF/Caller_ID. Many vanity domain owners do not control their DNS, and so are unable to create authorization records. Over time, the absence of an authorization record will be interpreted as 'possible forgery'. Vanity domain owners should pressure their ISPs to publish appropriate SPF/Caller_ID records, or to give the domain owner an interface to the DNS permitting the owner to do it. Some other ideas can be found on the spf.pobox.com website.

Regards,
Charles, Loughton