Re: Spamming...

On Tue, Apr 26, 2005 at 05:38:02PM +0100, Chris Haynes wrote:
> >It's worse than that. SPF only ties *domains* to IP addresses, not E-mail
> >addresses to IP addresses.
> 
> Not so: you can publish a policy which, using macros, checks the IP address 
> in relation to specific addresses, not just the domain.

Well, perhaps so, but I can't see that's any use in forgery detection.

For example: I am a spammer. I sign up for account "[email protected]". I open
a connection to smtp.example.net, and I send a standard outbound mail
   MAIL FROM:<[email protected]>
   RCPT TO:<[email protected]>

OK, that's fine. But now I start forging, and send another outbound mail:
   MAIL FROM:<[email protected]>
   RCPT TO:<[email protected]>

[email protected] is a legitimate user of the example.net ISP service, but I
have forged their return address.

Now, any message which has MAIL FROM:<[email protected]> which is relayed via
smtp.example.net, will have the same source IP address, whether it was
legitimately sent from the real [email protected] account, or was forged by
me. SPF could (at best) stop me forging address which do not exist.

So if you want to prevent this in an SPF world, basically you need to:

1. force your entire customer base to switch over to SMTP AUTH (or the SMTP
   relay must authenticate each connection using some external mechanism,
   e.g. a real-time lookup into RADIUS accounting data)

And:

2. set up a database which maps SMTP AUTH IDs to legitimate sender addresses,
   and reject mails whose sender is not authorised

Of course, if everyone did this, there would be no need for SPF in the first
place. However, there's no incentive for anyone to do it at the moment. The
cost (in customer aggravation and ongoing maintenance of the AUTH ID to
sender database) is very high, and the benefit accrues mainly to the rest of
the Internet, not to the ISP implementing this.

In the SMTP world, I think SES/SRS/BATV-type solutions offer a better
solution. You can at least be sure that a mail with a return address of
<[email protected]> really was sent by <[email protected]>, since you
callback to the [email protected] mailbox.

At this point, the MAIL FROM value is performing two functions:
(1) The return address for bounces
(2) As a signature to prove the sender of a mail also own a particular
    mailbox

You can't divorce the two. If I wanted to give a signed sender of
[email protected] then I would also have to have my bounces sent there. I
would have to either add the cookie myself (and make sure pobox.com have the
same shared secret on my account), or I would have to relay my outgoing mail
through their SMTP server.

Regards,

Brian.