Gateway to python-list is generating bounce messages.

[Maric Michaud]

Le Thursday 11 September 2008 06:51:19 Dennis Lee Bieber, vous avez écrit :
> On Wed, 10 Sep 2008 21:36:36 -0500, Grant Edwards <grante at visi.com>
>
> declaimed the following in comp.lang.python:
> > Wrong.  I didn't send _any_ e-mail.  Why should I get bounce
> > messages?
>
> 	One: Comp.lang.python is dual-routed with a mailing list; anything
> you post to either CLP or the mailing list gets cross-posted to the
> other -- the FROM header retains that of the original author (which
> could be you).
>
> 	Two: Somebody else is subscribed to the mailing list, and sets up an
> "out-of-office" reply or has other problems (like an overfilled mailbox,
> causing a bounce, or a discontinued account) when the forwarded post
> reaches their address.
>
> 	Three: The bounce/ooo-reply is sent to the message author, not to
> any intermediate host(s). After all, on that end, it's normal email
> failure response -- notify the author of the message. It doesn't matter
> that the original message was posted on a Usenet newsgroup if that group
> is automatically relayed to members of a mailing list.


Given RFCs, the problem should not be, for DSN, the MTA should rewrite the 
FROM envelope address to the one of the list maintainer :

RFC 3464 :
> 3. Conformance and Usage Requirements
>
> ...
>
>    By contrast, successful submission of a message to a mailing list
>    exploder is considered final delivery of the message.  Upon delivery
>    of a message to a recipient address corresponding to a mailing list
>    exploder, the Reporting MTA SHOULD issue an appropriate DSN exactly
>    as if the recipient address were that of an ordinary mailbox.
>
>        NOTE: This is actually intended to make DSNs usable by mailing
>        lists themselves.  Any message sent to a mailing list subscriber
>        should have its envelope return address pointing to the list
>        maintainer [see RFC 1123, section 5.3.7(E)].  Since DSNs are sent
>        to the envelope return address, all DSNs resulting from delivery
>        to the recipients of a mailing list will be sent to the list
>        maintainer.  The list maintainer may elect to mechanically
>        process DSNs upon receipt, and thus automatically delete invalid
>        addresses from the list. (See section 7 of this memo.)

and 

> Appendix C - Guidelines for use of DSNs by mailing list exploders
>
>  - Guidelines for use of DSNs by mailing list exploders
>
>
>    This section pertains only to the use of DSNs by "mailing lists" as
>    defined in [4], section 7.2.7.
>
>    DSNs are designed to be used by mailing list exploders to allow them
>    to detect and automatically delete recipients for whom mail delivery
>    fails repeatedly.
>
>    When forwarding a message to list subscribers, the mailing list
>    exploder should always set the envelope return address (e.g., SMTP
>    MAIL FROM address) to point to a special address which is set up to
>    receive non-delivery reports.  A "smart" mailing list exploder can
>    therefore intercept such non-delivery reports, and if they are in the
>    DSN format, automatically examine them to determine for which
>    recipients a message delivery failed or was delayed.


This is not sufficient for auto-responses, and given the following rfcs, it 
would smart to both :

- add an "Auto-Submitted: Python User Group" header,
- add or modify the Return-Path and/or Reply-To header for badly implemented 
auto-responders to point to list maintainer.

RFC 3834:

> 4.  Where to send automatic responses (and where not to send them)
>
>
>    In general, automatic responses SHOULD be sent to the Return-Path
>    field if generated after delivery.  If the response is generated
>    prior to delivery, the response SHOULD be sent to the reverse-path
>    from the SMTP MAIL FROM command, or (in a non-SMTP system) to the
>    envelope return address which serves as the destination for non-
>    delivery reports.


and

> 5.  The Auto-Submitted header field
>
>
>    The purpose of the Auto-Submitted header field is to indicate that
>    the message was originated by an automatic process, or an automatic
>    responder, rather than by a human; and to facilitate automatic
>    filtering of messages from signal paths for which automatically
>    generated messages and automatic responses are not desirable.


RFC 1123 :

>     5.3.7  Mail Gatewaying
>
>          Gatewaying mail between different mail environments, i.e.,
>          different mail formats and protocols, is complex and does not
>          easily yield to standardization.  See for example [SMTP:5a],
>          [SMTP:5b].  However, some general requirements may be given for
>          a gateway between the Internet and another mail environment.
>
>          (A)  Header fields MAY be rewritten when necessary as messages
>               are gatewayed across mail environment boundaries.
>
>               DISCUSSION:
>                    This may involve interpreting the local-part of the
>                    destination address, as suggested in Section 5.2.16


I'm also frustrated by some (rare) of my mails which are actually blocked for 
confirmation by a moderator with this message :

> Is being held until the list moderator can review it for approval.
>
> The reason it is being held:
>
>     Message has a suspicious header

I think it's probably my domain name which makes this, do the anti-spam engine 
use whitelists ? How to resolve the problem if not ?

-- 
_____________

Maric Michaud