comments on draft-zinn-smtp-bounces-01.txt

[Markus Stumpf <[e-mail]>]

[ as the draft references this mailing list and has impact on documents
  produced by this group I hope it is ok to send my comments here also
  for a broader discussion ]

> A virus spawned message contains no useful information and the bounce
> is of no interest to the forged sender.

I don't think this is true in general.

What I am missing in the draft is that the problem arises from
two distinct types of "bounces" that need different handling:

1) are "real bounces" in the sense of NDN (DSN rfc1894).
2) are autogenerated messages from virus scanners

Both use an empty RFC2821.MAILFROM ("<>"). However I'm not happy
with the wording in the draft that equals empty envelope senders
and bounce messages:
> Recent viruses take advantage of bounce messages to spread.  They
> forge the "reverse path" of the messages they send.  Some even
> send fake bounce message.
With that wording autoresponder messages (like vacation notifications)
using <> as 2821.MAILFROM also send "bounces" which is IMHO not true.

While messages of type 1) often provide useful information like the
headers of the original email und thus the originator of the message
(at least hostname/ip address), messages of type 2) don't, but these
are not real bounces.

Messages that contain the original headers do contain a lot of useful
information, like which IP address the virus abusing my email address
was sent from.
This is even more interesting if it belongs to a company/competitor, because
then they are easy subject to legal actions because of abusing my name and
email address to discredit me/my company in public.

 [ While I am not a fan of lawsuits in general my impression is that this
   will be the only way to make people fully aware of how unfunny it is
   not to take care and get infected. With all the reports in public
   media not updating computer software is no longer a peccadillo
   but clearly missing due diligence.]

For that reason I am not too happy with the draft and its intention
to change the wording of RFC2821. Even more as the problem is not
arinsing during the SMTP conversation but in most cases afterwards.
Messages of type 2) outnumber type 1) messages with regards to
worms/viruses significantly (at least in my mailbox).

I'd be much more happy to have a draft that would provide a solution
in the form of
   draft-moore-auto-email-response-04.txt
(which expired from internet-drafts repository :(( but is still
available at
   http://bgp.potaroo.net/ietf/all-ids/draft-moore-auto-email-response-04.txt
where those messages from virus scanners would be in a special defined
format/marked as virus reports and could be filtered by users that do
not wish to receive that kind of notification messages. This is
currently a very hard task, as every scanner uses own wordings per
default that can be modified by adminstrators as they wish.

Deployment of such a standard would be really easy and fast if all users
would bounce non conformant virus notifications to the AV vendors support
team *evil grin*

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: [phone]
Research & Development |       D-80807 Muenchen    | Fax: [phone]
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"