[Top] [All Lists]

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

2004-03-23 21:33:05

"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.


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.

<Prev in Thread] Current Thread [Next in Thread>