--On Monday, 19 April, 2004 10:47 -0500 bz
<bz+ietf(_at_)chemserv(_dot_)chem(_dot_)lsu(_dot_)edu> wrote:
I am preparing to rewrite
http://www.ietf.org/internet-drafts/draft-zinn-smtp-bounces-00
.txt taking into account the comments that have been made and
a discussion on a related topic that took place on usenet.
If anyone has specific wording that they would like to suggest
for use in draft-zinn-smtp-bounces-01.txt, please let me know
what to say and where to say it.
Précis of comment received so far. Credits and context of
comments are in the appended longer version of the text, after
the first line of dashes.
My responses to the points are marked **bz:.
1. Title may be too broad. It may have the effect of making it
harder for your document to get approved.
**bz: I am open to suggestions. Unless a better title is
suggested, I am staying with the one I have now.
Try some variation on "Some exceptions to the SMTP requirement
to bounce undelivered messages"
...
5. This RFC won't address cases where viruses forge the bounce
message. It seems like there are at least three separate
problems: - virus filter writers are too eager to tout their
products :) - bounces to spam and viruses are often useless
and they clog up the mail system - some software does issue
multiple messages in an error condition, which is especially
bad if the recipients of those messages can be chosen by an
attacker.
**bz: Agreed.
I recommend that you explicitly include identification of those
three cases in the document and identify which ones this
proposal addresses/solves.
...
10. The RFCs should state that when it would be harmful to the
network to propagate an email (because of a virus or trojan)
*any* MTA may drop it and, in fact, shouldn't reject or bounce
unless there is a reasonable expectation that the sending
address is correct.
However it should also be made clear that this is for network
protection only and not for general email policing - the old
distinction between "abuse of the net" and "abuse on the net".
We don't want to encourage vigilantism or the equivalent of
flame wars between MTAs.
In fact perhaps the RFCs should consider viruses explicitly as
a type of email whose handling is to be specified.
Rejecting/bouncing a virus is just as bad as delivering it.
Even if a bounce goes back correctly to its originating system
it might re-infect a cleaned system or infect other systems
there - there may be load balancing so that a different machine
receives it.
For the reason the author identifies in the second paragraph,
this is an extremely dangerous suggestion. Many people (and
even MTA operators) have a lot of trouble distinguishing between
things they find distasteful and things that are clearly
network-harmful or user-harmful.
...
15. I agree that the RFCs need to be fixed, but not to open
the gates to silent dumping.
...
In this case, a
notification should be sent to an abuse address for the
sending MTA and wait for the upstream to fix their problem.
We have _far_ too many worked examples of this -- automatic
notification of "abuse addresses" is at least as bad as
forwarding viruses. People will get it wrong and multiple
reports flooding those addresses can actually act as a DoS
attack on the process of getting things tracked down and fixed.
Similarly for several other "alert the upstream" comments --
that is exactly the disease you are trying to stamp out.
Just my thoughts...
john