Re: Do the must 'bounce' rules need to be relaxed for virus infected mes

> > "positively determined" or "reliably determined" roughly fits
> > my sense of what is appropriate, though I'd be more
> > comfortable if there were some examples for both what was
> > reliable and what was not considered sufficiently reliable.
> >
> > for instance, I don't think it would be acceptable to silently
> > drop messages on the basis of an SPF record, because the
> > problem could actually be a configuration error rather than
> > malice or deceit.
> Keith,
>
> The examples, and moving into the sort of topic your last paragraph 
> above raises, takes us down the slippery slope.
It's difficult to avoid some slippery slope, and I'm not sure it can be 
done.  But it seems to me that there are two slippery slopes back to 
back with not much room in the middle.  One of them is the risk that we 
will encourage people to drop messages for poor reasons (even though 
they may think they're good reasons).  Another is the risk that by 
trying to define (or even give examples) as to just what is and what 
isn't a good reason we'll exclude some valid reasons and/or permit some 
invalid ones, fail to anticipate some changes in conditions, and/or 
generally make things more difficult to understand and less likely to 
be implemented correctly.
I actually think it's more correct to say "don't send NDNs when there 
is a reliable indication that the MAIL FROM is forged" than "don't send 
NDNs in response to malicious or deceitful messages", because the real 
issue is sending NDNs to people who can make little use of them.  But 
that opens up its own set of problems, not the least of which is that 
we don't have any standard, reliable indications that MAIL FROM is 
forged.  (another is - how much work should an MTA do to determine 
whether MAIL FROM is forged?)
It would be interesting to consider separating the protocol 
specification (state machine, syntax, response codes, etc) from the 
recommended operational practice - with the expectation that the 
protocol specification limits itself to broad recommendations where 
operational issues are concerned, and also the expectation that the 
recommended operational practice document may be updated more 
frequently than the protocol specification.  Though I'm not sure how 
well this translates into implementations (or customer support issues) 
- do we then insist that implementations have knobs in appropriate 
places so that they can be tweaked according to the latest 
recommendations?
So there are lots of slippery slopes to be found in this area...

> So it seems to me that saying "this is generally a bad idea, but, if 
> you conclude you absolutely must do it to protect yourself, please be 
> very cautious" or "if you know the message had evil intent and that 
> producing an NDN or other notification might make things worse, it is 
> ok to make a decision to not make the notification" is reasonable.  
> But going into "evil-identifying technique X isn't as good as you 
> think it is" would just get us into long-term trouble.  It might even 
> give X a lifetime longer than it deserves or would otherwise have.
> A separate document on the subject of "dropping NDNs considered 
> harmful and dropping messages is considered _really_ harmful" would, I 
> think, be in order, and it might be (probably should be) filled with 
> lurid examples.  I'd be willing to review and contribute to it if 
> someone else made a start.  But, e.g., a discussion of the strengths 
> and weaknesses of SPF in the base mail standard seems just wrong to 
> me, almost as wrong as the recommendation that blackhole support be 
> required that appears in RFC 3552.
just to clarify - the mention of SPF wasn't intended as a suggestion 
for something to put in the SMTP specification, just an example of 
something that people might mistakenly _think_ was a reliable 
indication of malice or deceit - to support the argument that "reliably 
determined" language might not be good enough by itself.