Autoresponder lameness

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: <dmonache@xxxxxxxxxx>
[...]
Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56])
  by mx05.mrf.mail.rcn.net with ESMTP; 28 Aug 2005 10:16:14 -0400
[...]
Received: from zrchb007.us.nortel.com (zrchb007.us.nortel.com [47.103.121.51])
	by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7SEGAs23776
	for <blilly@xxxxxxxxx>; Sun, 28 Aug 2005 10:16:11 -0400 (EDT)
Received: by zrchb007.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <RLR2HA26>; Sun, 28 Aug 2005 09:16:09 -0500
Message-ID: <C67783EBF67FCC4E8A99A8C5DC6F5EF5C1673B@xxxxxxxxxxxxxxxxxxxxxx>
From: "David Monachello" <dmonache@xxxxxxxxxx>
To: Bruce Lilly <blilly@xxxxxxxxx>
Subject: Out of Office AutoReply: Last Call: 'Tags for Identifying Languag
	es' to BCP
Date: Sun, 28 Aug 2005 09:16:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
[...]

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: 
                         david.monachello@xxxxxxxxxxxxx

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 <ietf-bounces@xxxxxxxx> 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 ietf-bounces@xxxxxxxx, 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]