[Asrg] where the message originated (was: DKIM role?) (SM)

[Ian Eiloart]

--On 19 January 2009 09:44:05 -0500 Rich Kulawiec <rsk at gsp.org> wrote:

> On Mon, Jan 19, 2009 at 01:02:49PM +0000, Ian Eiloart wrote:
>>> The days when sending bounces was acceptable are fading into the
>>> distance.
>>
>> Yes, and that's a bad thing. It's bad that spammers have made an
>> effective notification system virtually unusable.
>
> I don't see a problem here that needs solving.  Rejects are far more
> efficient, and have two huge advantages: (a) they don't generate
> more largely-worthless SMTP traffic at a time when we're drowning in
> largely-worthless SMTP traffic (b) they're much harder to co-opt
> for abusive purposes. [1]

I agree, but bounces have two huge advantages,

1. You can bounce selectively. IE, you can accept a message for one 
recipient, while bouncing it for another, even after seeing the content. 
So, you can have different delivery policies for different people.

2. The content of the bounce message is generated by the MTA that made the 
decision. Therefore, it can contain content that's easier to understand.

So, you may not agree that the balance is in favour of bouncing, but it 
certainly would be better to bounce if you KNOW that the sender address is 
not forged - regardless of how you know that.

In fact, we adopt that policy when we know that the sender is local and 
authenticated. Because most mail clients are very unhelpful when you reject 
their mail submissions.

> There are other areas where the damage spammers have done (or are likely
> to do when it suits their purposes) is much more of an issue.  And it's
> certainly not worth trying to salvage a fundamentally-broken technology
> like SPF in order to fix a problem we don't have.

It's not fundamentally broken. It's a tool that has some useful 
applications, even if you can use it to shoot yourself in the foot. For 
example, two organisations that want to improve their email communications 
could agree to deploy SPF and whitelist each other when SPF passes happen. 
It'll work better when they also ensure that their users use their message 
submission services, and when their networks are secure, and when they can 
easily contact each others administrators.

That works because they trust each other, and because they can now reliably 
associate the domain with the organisation under certain circumstances 
(with SPF passes). The trust model can be extended through domain 
reputation servers.

Is there any other way to do this, that doesn't involve publishing 
information that says where my email can originate, or signing outbound 
email?

> ---Rsk
>
> [1] And in most of the scenarios I've worked through where they *could*
> be co-opted, they're a distant third or fourth choice, because attackers
> in a position to carry those approaches out will quite likely already have
> preferable means at their disposal.
>
> _______________________________________________
> Asrg mailing list
> Asrg at irtf.org
> http://www.irtf.org/mailman/listinfo/asrg



-- 
Ian Eiloart
IT Services, University of Sussex
x3148