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

[Ian Eiloart]

--On 12 January 2009 17:20:46 +0000 Graeme Fowler <graeme at graemef.net> 
wrote:

> On Mon, 2009-01-12 at 11:06 -0500, Seth wrote:
>> And the recipients of the bounces should feel free to report your
>> bounces as spam.  And they should also feel free to cut your Internet
>> connection to block further spam from your site, to encourage you to
>> stop spamming.
>
> I have a sneaking suspicion that there may be a terminology problem
> here: Ian more than likely means "reject" when he says "bounce". The
> thread becomes rather less argumentative if you do that replacement.

No, actually I mean bounce. I mean "generate a new message". Domain owners 
are able to help the world detect forgeries. If they don't do that, then 
perhaps the rest of the world should not feel too bad about using SMTP in 
the way that it was designed by generating a bounce message.

> Of course, I may be putting words into Ian's mouth which he *didn't*
> mean, but before anyone else replies I would like to see Ian clarify
> whether he means "bounce" or "reject".
>
> Knowing him at least a little in my professional capacity I would be
> *very* surprised if he did intend to write "bounce", unless he was being
> deliberately controversial...

Thanks. I am deliberately trying to generate discussion of the idea. I'm 
well aware, that it's not very nice to be on the receiving end of 
collateral spam. And have for some time thought that the solution is to 
argue that nobody should bounce email.

However it occurred to me recently, that actually you don't need to be on 
the receiving end of collateral spam. Rather than trying to persuade people 
to NEVER bounce an email, it might be better to let people know which 
emails can be bounced - those with proper SPF or DKIM matches.

There are at least two very good reasons for wanting to bounce rather than 
reject emails.

a) when a message has two or more local recipients, you can't have 
different policies for each recipient about what to reject. You reject for 
all or no recipients. There are some workarounds, but they're kludgy and 
cause their own problems.

b) when you reject a message you can try to explain why, but often the 
sending MTA will throw away some or all of your explanation. Usually, it 
will wrap your explanation inside it's own. The end result is that the 
recipient of the bounce message (if there is one) doesn't understand what's 
going on. If you generate a bounce, you have full control of what the 
bounce recipient sees. For example, you could include an explanation of why 
they should lobby their domain controller to publish SPF records.

> Graeme
>
> _______________________________________________
> Asrg mailing list
> Asrg at irtf.org
> http://www.irtf.org/mailman/listinfo/asrg



-- 
Ian Eiloart
IT Services, University of Sussex
x3148