[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





--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
_______________________________________________
Asrg mailing list
Asrg at irtf.org
http://www.irtf.org/mailman/listinfo/asrg