Gateway to python-list is generating bounce messages.
maric at aristote.info
Tue Sep 16 15:26:55 CEST 2008
Le Monday 15 September 2008 16:45:12 Maric Michaud, vous avez écrit :
> 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.
Oh, no ! to the list itself of course.
This could also avoid the common mistake mailing list users do in replying
private mail accidentally when the adress of the list is only present in CC
> 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.
> > 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
> 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 ?
I re-send this correction to my previous post because the first got held as
spam, :' (, is there really a moderator, as the bounce says, and he decided
to censor me ?
More information about the Python-list