Subject: Autoresponder lameness

From: Bruce Lilly <[email-masked]>
Date: Sun, 28 Aug 2005 14:46:12 -0400

The IETF discussion mailing list's recipients seem to be particularly lax
about conforming to IETF mail specifications.  If it weren't sad, it would
be funny, as shown by the following real example and related commentary
(some message header fields elided for brevity):
-------------------------------------------------
Return-Path: <[email-masked]>
[...]
Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56])
  by mx05.mrf.mail.rcn.net with ESMTP; 28 Aug 2005 10:16:14 -0400
[...]
From: "David Monachello" <[email-masked]>
To: Bruce Lilly <[email-masked]>
Subject: Out of Office AutoReply: Last Call: 'Tags for Identifying Languag
	es' to BCP
Date: Sun, 28 Aug 2005 09:16:05 -0500
[...]

Effective immediately, this e-mail account is no longer in service.
You will only receive this notice once.

As part of the Nortel Networks acquisition of PEC Solutions Inc., this
e-mail 
address has been changed to: 
                         [email-masked]

Please update your contact information.  To obtain the individual's new
phone
number please call Nortel PEC Solutions Front Reception at (703)679-4900.

This e-mail has been auto forwarded.   Subsequent e-mail messages will be 
forwarded for a limited transition period.
------------------------------------------------

Comments on this instance of a delivery notification message:

1. Delivery notifications should have the return-path (SMTP envelope sender)
   set to a null value to prevent loops.  In this case, the return-path was
   set to what is presumably the specific non-functional mailbox which is the
   subject of the message text (although nowhere does the message say so
   explicitly)!  Note that the message From field is also set inappropriately.

2. Delivery notifications should be sent to the original message return path.
   In this case, as I have never sent any message to the individual in
   question, the message must have resulted from delivery of an IETF
   discussion list message, which would have had <[email-masked]> as
   the original message return path.

3. The most appropriate action for Nortel Networks would have been to have
   notified Mr. Monachello of the change and to have requested him to have
   revised the mailbox used for receipt of mailing list messages, in which
   case there would have been no need to send any sort of delivery
   notification message at all.  Failing that, notification should have been
   sent to [email-masked], where the notification of a change could be
   effectively handled; I can do nothing with the "information" about the
   change of mailbox for Mr. Monachello; the notice sent to me personally is
   annoying and causes me to hold Mr. Monachello, Nortel Networks, and
   Microsoft (purveyor of "Internet Mail Service") in lower esteem than prior
   to receipt of the message.

4. None of the above is rocket science; it is clearly specified in RFC 3834,
   which has the unsurprising title "Recommendations for Automatic Responses
   to Electronic Mail", and which itself distills long-standing practice
   regarding such responses as documented in the SMTP specifications and in
   such obscure documents as the Host Requirements standard (RFC 1123, a.k.a.
   STD 3).  It's also common sense.

The message has been dealt with as spam; future messages of a similar nature
are likely to be automatically filtered (and automatically reported to Pyzor
and SpamCop as spam).  And this isn't an isolated instance; I've seen quite a
few similar messages, as other contributors to the IETF discussion list no
doubt have.

Fellow IETFers: please make sure that any "vacation"-like automatic
responders under your control or in use at your organizations comply with the
Host Requirements, the SMTP specifications, and the recommendations in RFC
3834.  And to those of you who are responsible for the non-conforming
behavior of certain automatic responders, shame on you.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Aug 2005 21:15:08 +0200

Bruce Lilly wrote:

> Delivery notifications should be sent to the original message
> return path.

Yes, I've mentioned RfC 3834 in my first three complaints (some
obscure script sending "Alerts" to the mailing list From, I'm
not sure which list, mxcomp or IETF general or both).  I also
proposed to killfile me, or to discuss the "problem" - whatever
it might be, I have no clue - with the list moderator / owner.

> The message has been dealt with as spam

Same here.  I could also bother the list owner / moderator,
but it's a weekend, maybe my direct complaints have an effect.
 
> Fellow IETFers: please make sure that any "vacation"-like
> automatic responders under your control or in use at your
> organizations comply with
[...]
> the recommendations in RFC 3834.

Seconded.  Bye, Frank

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 30 Aug 2005 04:57:54 +0200

On Sun, Aug 28, 2005 at 02:46:12PM -0400, Bruce Lilly wrote:
>    set to a null value to prevent loops.

RFC 3834 says "MAY" have:

3.3.  Message envelope
    [ ... ] Since in most cases it is not appropriate to respond to
    an automatic response, and the responder is not interested in
    delivery status messages, a MAIL FROM address of <> MAY be used for
    this purpose.  A MAIL FROM address which is specifically chosen for
    the purpose of sending automatic responses, and which will not
    automatically respond to any message sent to it, MAY be used instead
    of <>.

> In this case, the return-path was

The message said:
*> Effective immediately, this e-mail account is no longer in service.
*> You will only receive this notice once.
So they probably run some database for that account. So setting the
envelope-sender and the From: to that database account exactly
guarantees the intended (and wanted) behaviour.

>    STD 3).  It's also common sense.

No, it is no common sense. Would it be that my mailboxe (and the
postmaster box) wouldn't be filled with zillions of brained Outlook
away/vacation messages.

For the rest of your message I fully agree.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"