Re: Do the must 'bounce' rules need to be relaxed for virus infected messages?
--On Tuesday, 23 March, 2004 20:05 -0500 Keith Moore
An SMTP server MAY decide not to send the "undeliverable
mail" notification message when it can determined that the
original message had malicious or deceitful intent.
Determination of such intent is beyond the scope of this
This would be an accurate reflection of what many servers are
This seems much closer to what I think would be appropriate,
although I'd prefer, e.g., to see "be accurately" or "be
positively" in front of "determined".
"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.
Personally, I've got a strong sense of morals and
appropriateness where these issues are concerned, and I find the
idea of silently discarding a message, or even a non-delivery
report, when there is any chance it is legitimate to be really
scary. If it becomes general practice, we will quickly lose the
general perception that email is reliable. And that is the
point at which many of us go back to the post, or fax, or even
letters in bottles.
We've already got an exception or two in 2821 that authorizes
servers to bend the rules when they conclude that they are under
attack and need to protect themselves. Those exceptions come
with strong cautions. They don't have any hairsplitting, or
even examples, about what is or is not appropriate because
circumstances may be different in different cases and
If we say to someone in the standard "you are forbidden to do
what you believe is necessary to protect yourself or the
Internet" we don't promote good and consistent behavior. What
we promote is non-conformance and, worse, the potential for
people to conclude that the standard is not to be taken
seriously when it does make a definite statement.
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.