Gateway to python-list is generating bounce messages.
maric at aristote.info
Mon Sep 15 16:45:12 CEST 2008
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.)
> 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 , 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.
> 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.
> 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.
> 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 ?
More information about the Python-list