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

[Ian Eiloart]

--On 20 January 2009 07:06:17 -0500 Rich Kulawiec <rsk at gsp.org> wrote:

> n Mon, Jan 19, 2009 at 03:38:39PM +0000, Ian Eiloart wrote:
>> 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.
>
> (a) I don't want to bounce at all, ever and (b) I don't see the value in
> this approach.  If the message is from a spammer (or is classified as spam
> by some mechanism), then it gets rejected [for all recipients] no matter
> who wants it or why.  I don't permit users to selectively decide to
> receive bogons; I don't permit them to selectively decide to receive
> spam, and for the same reason: I think it's very poor security policy.

I work in an academic environment with a medical school, where a word like 
"viagra" or "penis" can mean spam to some people, or a vital research grant 
application to others.

I don't like content filtering at all, and only apply it quite lightly. I'd 
like to allow people to opt in to heaver filtering (eg, those that are 
particularly sensitive to obscenity), or opt out completely. While I'm not 
permitted to bounce messages (I don't) I can't do that well when there are 
multiple recipients.

Pre-data, of course, I can apply selective filtering, but only for policies 
that most people don't understand (source IP address reputation, and EHLO 
string). And not based on the sender address. Blacklisting specific senders 
is ineffective, whitelisting creates holes in my spam filter.


>> 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.
>
> This doesn't follow.  Reject messages, like bounces, are also generated by
> the MTA that made the decision.  Any sufficiently-broken mail system
> that mangles those is probably going to mangle bounces or do other
> silly things as well.  If you need to transmit a long, detailed message,
> then provide a static URL, as in:
>
> 	550 blah blah Your message rejected because your momma dresses
> 		you funny; see http://www.example.com/rejects/your-momma.html
>
> Of course there's no guarantee that will survive transit either.  The
> bottom line is that you can't do anything to fix other peoples' broken
> mail systems.

Yes, I thought that's what I said. Not only might it not survive, but it 
might be replaced with a misleading error message. For example, if I reject 
a sender address after RCPT TO (in case the rcpt is postmaster), some MTA's 
will generate a bounce message which says the recipient doesn't exist.

Anyway, it's almost always embedded in some other message. Does anyone know 
of an MTA that doesn't add something to a reject message when generating a 
bounce message? Would such a bounce be of any value?

I do put URLs in my messages, usually on the first line because that seems 
more likely to survive. IIRC, there are MTAs that preserve only the first 
line of an error message in a bounce. I also use enhanced error codes, in 
the hope that some MTAs might generate better bounce messages.

I don't buy the argument that an MTA that mangles reject messages (that 
requires little or no administrative effort) will also mangle bounce 
messages (that requires more effort). Perhaps I'm wrong. Does anyone know 
of an MTA that mangles bounce messages in its default configuration?

-- 
Ian Eiloart
IT Services, University of Sussex
x3148