🚀 go-pugleaf

elevique@my-dejanews.com wrote:
> 
> 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 pete@seven.com (the originator is not important).
> 
> a)pete@seven.com is a mailing list with one member, pete@team.com, so the
> message is addressed to pete@team.com. The envelope return address is now
> changed to pete@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 pete@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
> pete@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-request@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.