Musings from a small IPP

The scourge of the Internet is SPAM mail.  So much rubbish arrives each day — it is a major part of the service we offer to our customers that we block tag and pre-file most of it for them, so they can (we hope) have uncluttered real communication.

With our efforts to clean-up what comes in goes a responsibility to keep the outgoing stream of mail clean.  In general we trust our customers to keep their anti-virus up-to-date but there remains a risk of their computer becoming infected in some way, or worse becoming part of a bot-net (q.v.). We would expect to notice if their sending pattern suddenly changed, and we require an authenticated connection before we will forward mail.

Many domestic market ISPs will intercept IP port 25 traffic — mail traffic — for just this reason — they don’t want to be seen as hosters of SPAM.  As we’re not in the local loop business we are set up to accept outgoing mail on Port 587 (submit) which lets our customers bypass the blocks on port 25 and get their mail out from the right place, and lets our anti-spam software take note of their correspondent’s addresses to facilitate the replies.  Our customer’s SPF records have a clause include:oa5.com to allow their mail to come from our servers.

This leads on to some thoughts about SPF and ISP relayed mail.  There are really three cases that spring to mind

1. The user has their mail in the ISP’s domain eg aol, waitrose, tiscali, and does not use their own domain
2. The user has their own domain, but actively uses the ISP’s mail servers to handle the outgoing traffic
3. The user has their own domain, and their own mail server, but the ISP actively intercepts outgoing traffic on port 25 to mediate for SPAM

Cases where the ISP is not involved are not interesting here.

Case 1 is just for the ISP. If the ISP is at all concerner for its reputation it will set up appropriate SPF records to prevent its own, and its customer’s mails being spoofed.

Case 2 is more interesting for the concerned domain owner.  If the ISP has an SPF record, that can be pulled into the domain’s own SPF record with an ‘include:‘ clause.  Absent that ISP record though; the domain owner has two choices:

• Do without an SPF record – or –
• Run a full mail server, and deliver mail directly

as there is no way for the customer to enumerate the ISP’s outgoing mail servers.

The third case is even more interesting in it’s own way.  The ISP is doing something that in Britain should be restricted by RIPA (The Regulation of Investigatory Powers Act otherwise known as the official snoopers charter).  By interposing itself as a relay the ISP is breaking the customer’s SPF configuration, and so needs to run the Sender Rewriting Scheme on the outgoing messages to enable them to be delivered.

I don’t think any do.