[Top] [All Lists]

Re: collected comments on "When NOT to Bounce Email"

2004-04-22 05:49:36

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

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

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