Re: Spamming...

On Thursday, April 28, 2005 at 10:52 AM  "Brian Candler"objected:

> 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.

It is - if you follow your own suggestions below...

>
> 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.

Agreed .

>
> 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.

Here's where we differ.  It's the people whose domains are forged (e.g. 
'joe-job' victims) who have every incentive to publish SPF. And, yes, if you 
have a shared outbound SMTP server it needs to provide protection against 
sibling-customer forgery.  But that's not a flaw in SPF per se, just another of 
the architecturally-related bits of policy/practice  that have to be 
tightened-up to create a more trustworthy email infrastructure.

And it does not need the whole world to provide this sibling-customer forgery 
protection, only the servers _I_ use. With my outbound MSP doing these checks, I 
can safely publish a '-all' policy and get global protection against forgery - 
it does not need any other MSPs to have also done the same.

That's what attracted me to SPF as a tactical palliative: local/early  adoptors 
can gain benefits without the need for universal deployment.


> 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.

It's that ISP's customers who benefit - directly. So any MSP with a sincere 
commitment to customer value would presumably want to offer this.

I freely concede that there are no reports of any MSPs actually doing 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.

Not so - certainly w.r.t. SES & SRS.  (I've not examined BATV for the open 
Internet in depth). With SES you can be sure that _a_ message was sent by 
[email protected], within a certain time-slot, but not any _particular_ message 
which you may be inspecting. The message can be radically amended, or even the 
signed Mail From part used with a totally different message.

The 'obvious' defence of including some kind of cryptographic digest of the 
message itself cannot work in the 'real world'. See the posts I made to the SES 
list around 21 Dec 2004 , where I demonstrated the extreme difficulty 
(impossibility?) of guaranteeing cryptographically-ensured 'sameness' whilst 
simultaneously permitting message / header additions by forwarders, lists, etc.

BTW, I believe the problems I demonstrated there are a challenge to 'any' scheme 
which attempts to permit 'small' alterations or extensions to signed messages.

>
> 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.

There are some other possibilities I have thought of for dealing with this, but 
I agree they are all 'messy'.

>
> Regards,
>
> Brian.
>
>

I'm actually in agreement with what I understand the basic thesis of IM2000 to 
be - that the flaws in existing SMTP are sufficiently deep and 
architecturally-ingrained that _no_ combinations of SPF,SRS,SES, DK or whatever 
can give a wholly satisfactory long-term solution.

But I do try to understand what they _can_ do - there may be useful lessons 
there.


Regards,

Chris Haynes