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(_at_)nortel(_dot_)com>
[...]
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(_at_)erols(_dot_)com>; 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(_at_)zrchb007(_dot_)us(_dot_)nortel(_dot_)com>
From: "David Monachello" <dmonache(_at_)nortel(_dot_)com>
To: Bruce Lilly <blilly(_at_)erols(_dot_)com>
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(_dot_)monachello(_at_)nortelpec(_dot_)com
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(_at_)ietf(_dot_)org> 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(_at_)ietf(_dot_)org, 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf