RFC1891- looping message
Kari E. Hurtta
>
> This is more an SMTP problem than a sendmail one, but I can't seem to get
> access to info.ietf.smtp, if someone can forward it to this group then please
> do so.
>
> I have a problem with a looping message, I have tried to find out which of the
> systems involved is at fault, but I can't see what the problem is.
>
> A user sends to pe...@seven.com (the originator is not important).
>
> a)pe...@seven.com is a mailing list with one member, pe...@team.com, so the
> message is addressed to pe...@team.com. The envelope return address is now
> changed to pe...@seven.com (as per RFC1981 6.2.7.1.a) )and the NOTIFY value to
================
> whatever the list's default is. The original NOTIFY value must NOT be taken
> into account (as per RFC1891 6.2.7.1.b)). In this case the NOTIFY is set to
> FAILURE.
>
> b)The message can't be delivered to pe...@team.com (for whatever reason) so a
> DSN is generated. The DSN sender address has a blank return path ( <> as in
> RFC1891 7.1), and has a NOTIFY value of NEVER. The return address is
> pe...@seven.com so the DSN is sent to him.
>
> We are now back at a) which then leads to b) and hence to an infinite loop.
>
> Where is this going wrong? Is there something else apart from the return
> address and the NOTIFY=NEVER to indicate that this is a DSN and not a
> message? Should seven.com be handling the list differently?
Please reread RFC1981:
| (a) The envelope return address is rewritten to point to the list
=======
| maintainer. This address MAY be that of a process that recognizes
==========
| DSNs and processes them automatically, but it MUST forward
| unrecognized messages to the human responsible for the list.
List maintainer address != mailing list address.
So in point a) is:
The envelope return address is now changed to
pete-r...@seven.com
(as per RFC1981 6.2.7.1.a)
/ Kari Hurtta
------------------------------------------------------------------------------
6.2.7.1 mailing lists
When a message is delivered to a list submission address (i.e. placed
in the list's mailbox for incoming mail, or accepted by the process
that redistributes the message to the list subscribers), this is
considered final delivery for the original message. If the NOTIFY
parameter for the list submission address contained the SUCCESS
keyword, a "delivered" DSN MUST be returned to the sender of the
original message.
NOTE: Some mailing lists are able to reject message submissions,
based on the content of the message, the sender's address, or some
other criteria. While the interface between such a mailing list and
its MTA is not well-defined, it is important that DSNs NOT be issued
by both the MTA (to report successful delivery to the list), and the
list (to report message rejection using a "failure" DSN.)
However, even if a "delivered" DSN was issued by the MTA, a mailing
list which rejects a message submission MAY notify the sender that
the message was rejected using an ordinary message instead of a DSN.
Whenever a message is redistributed to an mailing list,
(a) The envelope return address is rewritten to point to the list
maintainer. This address MAY be that of a process that recognizes
DSNs and processes them automatically, but it MUST forward
unrecognized messages to the human responsible for the list.
(b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the
redistributed message MUST NOT be derived from those of the original
message.
(c) The NOTIFY and RET parameters MAY be specified by the local
postmaster or the list administrator. If ORCPT parameters are
supplied during redistribution to the list subscribers, they SHOULD
contain the addresses of the list subscribers in the format used by
the mailing list.
elev...@hotmail.com
thanks for your reply. It makes sense to me and will indeed solve my problem
as long as I can convince seven.com that they should be using
pete-r...@seven.com as the new return address.
Can you let me know where the concept of the list-maintaner is defined because
RFC1891 makes no mention of what form the list maintainer address should take,
and so leaves it open to being interpreted as it being possible for the list
maintainer address to be the original recipient address.
Can you refer me to another RFC?
Thanks
Paul
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own