473,418 Members | 2,267 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,418 software developers and data experts.

Gateway to python-list is generating bounce messages.

Could whoever is responsible for the gateway that is grabbing
my postings off of Usenet and e-mailing them out please fix the
headers in the mail messages so that I don't get the bounce
messages?

While you're at it, might as well fix it for everybody else
too. ;)

Its a bit rude to send out mass e-mail messages with headers
faked up so that the bounce messages go to somebody else.

--
Grant Edwards grante Yow! As President I have
at to go vacuum my coin
visi.com collection!
Sep 10 '08 #1
18 2345
Grant Edwards <gr****@visi.comwrites:
Could whoever is responsible for the gateway that is grabbing
my postings off of Usenet and e-mailing them out please fix the
headers in the mail messages so that I don't get the bounce
messages?
The bounce messages are sent to you because you sent the original.
Its a bit rude to send out mass e-mail messages with headers faked
up so that the bounce messages go to somebody else.
Indeed it is rude, and the person subscribed to the mailing list whose
software is sending these bounce messages is the one responsible for
making it stop. The mailing list software can't help (nor can the
news-to-mail gateway).

In the meantime, the usual fix is for the list administrator to
unsubscribe the offending party (the one sending automated bounce
messages).

--
\ “He who laughs last, thinks slowest.” —anonymous |
`\ |
_o__) |
Ben Finney
Sep 10 '08 #2
On 2008-09-10, Ben Finney <bi****************@benfinney.id.auwrote:
Grant Edwards <gr****@visi.comwrites:
>Could whoever is responsible for the gateway that is grabbing
my postings off of Usenet and e-mailing them out please fix the
headers in the mail messages so that I don't get the bounce
messages?

The bounce messages are sent to you because you sent the
original.
Wrong. I didn't send _any_ e-mail. Why should I get bounce
messages?

Isn't sending e-mails pretending they're from somebody else
considered unethical (if not illegal)?
>Its a bit rude to send out mass e-mail messages with headers
faked up so that the bounce messages go to somebody else.

Indeed it is rude, and the person subscribed to the mailing
list whose software is sending these bounce messages is the
one responsible for making it stop.
No, the one who's sending e-mail with forged headers is the one
who ought to make it stop. That e-mail was not from me. It
was from somebody who grabbed the article off a usenet server
and mailed it to a bunch of people.
The mailing list software can't help (nor can the news-to-mail
gateway).

In the meantime, the usual fix is for the list administrator
to unsubscribe the offending party (the one sending automated
bounce messages).
I think the list administrator ought to stop putting other
people's e-mail addresses in the From: headers of e-mails he's
sending.

--
Grant

Sep 11 '08 #3
Grant Edwards <gr****@visi.comwrites:
On 2008-09-10, Ben Finney <bi****************@benfinney.id.auwrote:
Grant Edwards <gr****@visi.comwrites:
Could whoever is responsible for the gateway that is grabbing
my postings off of Usenet and e-mailing them out please fix the
headers in the mail messages so that I don't get the bounce
messages?
The bounce messages are sent to you because you sent the
original.

Wrong. I didn't send _any_ e-mail. Why should I get bounce
messages?
You asked for email to be sent, by sending a Usenet post to
comp.lang.python. That's what a news-to-mail gateway does.
Isn't sending e-mails pretending they're from somebody else
considered unethical (if not illegal)?
No, since it's clearly the function of a news-to-mail gateway to make
this forum operate as a single pool of communication, seamlessly
passing the messages between two distinct media. That happens by
preserving the messages as intact as feasible in both media.
Indeed it is rude, and the person subscribed to the mailing list
whose software is sending these bounce messages is the one
responsible for making it stop.

No, the one who's sending e-mail with forged headers is the one who
ought to make it stop. That e-mail was not from me. It was from
somebody who grabbed the article off a usenet server and mailed it
to a bunch of people.
You seem to be arguing that the news-to-mail gateway of this forum
should stop functioning.

I don't know if you're claiming to be ignorant of the news-to-mail
gateway before now; if so, I hope you'll agree that having a large
body of mostly well-behaved contributors on this joint forum is worth
effort to keep it operational.
I think the list administrator ought to stop putting other people's
e-mail addresses in the From: headers of e-mails he's sending.
(Note that an email message has exactly one header, by definition; it
consists of separate fields, of which the From field is one.)

It's unfortunate that you don't like how the news-to-mail gateway
functions, but I'm not convinced that one person's surprise at how it
operates should be reason to break its primary function.

I sympathise completely with your irritation at receiving bounce
messages from poorly-configured software, but the solution is not to
break the news-to-mail gateway.

The correct solution is to unsubscribe the badly-behaving address from
the mailing list, and refuse re-subscription from that address without
assurance that the bad behaviour has ceased.

--
\ “A child of five could understand this. Fetch me a child of |
`\ five.” —Groucho Marx |
_o__) |
Ben Finney
Sep 11 '08 #4
On Thu, 11 Sep 2008 15:25:57 +1000, Ben Finney wrote:
The bounce messages are sent to you because you sent the original.

Wrong. I didn't send _any_ e-mail. Why should I get bounce messages?

You asked for email to be sent, by sending a Usenet post to
comp.lang.python. That's what a news-to-mail gateway does.
I wasn't aware that comp.lang.python was a news-to-mail gateway. How can
one tell the difference between news groups that use a news-to-mail
gateway, and news groups that don't?

Posting to a public newsgroup is obviously giving consent to forward that
news posting to news clients. Given the ability to opt-out with the X-No-
Archive header, there may even be an implied consent to allow archiving.
But I don't believe there is any such implied consent to format-shift
news messages to email.

In practice, I couldn't care less what format my news postings are
converted to, so long as it is invisible and transparent to me. If
somebody wants to build a news-to-carved-in-giant-stone-tablets gateway,
I don't care, so long as I don't get giant stone tablets aren't dumped in
my front yard.

Nor do I believe that by posting a news message I've automatically
consented to receive email messages. To imply that the one implies the
other is equivalent to arguing that because I've written a letter to the
editor of a newspaper, I therefore must accept private correspondence
from any person or corporation that has a subscription to that newspaper.

(In practice, I don't mind human-generated email messages, but not
automatic messages. If you can turn my munged email address into a real
email address, I probably won't mind you emailing me. Don't abuse the
privilege.)
[...]
I sympathise completely with your irritation at receiving bounce
messages from poorly-configured software, but the solution is not to
break the news-to-mail gateway.

The correct solution is to unsubscribe the badly-behaving address from
the mailing list, and refuse re-subscription from that address without
assurance that the bad behaviour has ceased.
The problem with that "correct solution" is that the party who suffers
isn't in a position to correct the problem, and the party who can correct
the problem has little incentive to do anything about it. That makes the
solution ineffective and therefore anything but "correct".

I hope the person running the mailing list does do the right thing, but
if he or she does, it will be an accident of policy or personality, and
not because the system is robust and self-corrects errors. To quote
Dennis Lee Bieber:

"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."

But that's wrong: it *shouldn't* be an normal email failure response,
because the message author is in no position to do anything about it
except to cease posting. That's a problem with all mailing lists (that I
know of).

--
Steven
Sep 11 '08 #5
Steven D'Aprano wrote:
I wasn't aware that comp.lang.python was a news-to-mail gateway. How can
one tell the difference between news groups that use a news-to-mail
gateway, and news groups that don't?
by reading the group's FAQ, perhaps?

http://www.faqs.org/faqs/python-faq/...newsgroup-faq/

comp.lang.python (or c.l.py for short) is the general discussion
newsgroup for users of the Python language. It is also available
as a mailing list; see below for instructions on subscribing to
c.l.py through the mailing list.

it's been this way since the group was formed ~14 years ago, and isn't
likely to change.

</F>

Sep 11 '08 #6
Steven D'Aprano <st****@REMOVE.THIS.cybersource.com.auwrites:
Nor do I believe that by posting a news message I've automatically
consented to receive email messages. To imply that the one implies the
other is equivalent to arguing that because I've written a letter to the
editor of a newspaper, I therefore must accept private correspondence
from any person or corporation that has a subscription to that newspaper.
The two are not equivalent in this important detail: to post a
newsgroup message, you must give a 'From' field in the header (note:
just like email messages, newsgroup messages have exactly one header,
comprised of multiple fields).

You can fake an address in that field, of course, but it's considered
bad form to do so. (That doesn't stop it being extremely common.) What
you can't do is claim that, without express permission, no-one may
send you an individual message to that address. On the contrary, that
is the express purpose of the From field in a newsgroup message: to
allow individual contact to the sender of the message.

In the case of a letter to the editor a newspaper, the protocol is
different. The newspapers are expected, by convention, to state the
name and, often, suburb (or other location) of the writer; i.e. not
enough information to send an individual message to the person. You
might wish that Usenet operated the same in this respect, but it
doesn't, and you can't reasonably expect that it does.

--
\ “If you were going to shoot a mime, would you use a silencer?” |
`\ —Steven Wright |
_o__) |
Ben Finney
Sep 11 '08 #7
On 2008-09-11, Steven D'Aprano <st****@REMOVE.THIS.cybersource.com.auwrote:
On Thu, 11 Sep 2008 15:25:57 +1000, Ben Finney wrote:
>The bounce messages are sent to you because you sent the original.

Wrong. I didn't send _any_ e-mail. Why should I get bounce messages?

You asked for email to be sent,
No, I didn't.
>by sending a Usenet post to comp.lang.python. That's what a
news-to-mail gateway does.
ROTFL. That's like saying: you asked to be mugged by walking
down a street where there was a mugger. That's what a mugger
does.
I wasn't aware that comp.lang.python was a news-to-mail
gateway. How can one tell the difference between news groups
that use a news-to-mail gateway, and news groups that don't?
One can't tell.
Posting to a public newsgroup is obviously giving consent to
forward that news posting to news clients. Given the ability
to opt-out with the X-No- Archive header, there may even be an
implied consent to allow archiving. But I don't believe there
is any such implied consent to format-shift news messages to
email.
I certainly don't care if the articles I post are sent to
anybody via any transport. I just don't like it being made to
appear that I'm the one who sent them. I supposed I could
break down and stop using my real e-mail address in the From:
field. Or I could add some procmail rules to try to filter out
the results of being joe-jobbed by the gateway.
In practice, I couldn't care less what format my news postings
are converted to, so long as it is invisible and transparent
to me.
That's the issue: it's not invisible to you if you're getting
bounce messages, out-of-office-replies, and other e-mail
traffic generated by the fact the somebody is grabbing articles
off Usenet and mailing them out as if it were you that sent
them.
If somebody wants to build a
news-to-carved-in-giant-stone-tablets gateway, I don't care,
so long as I don't get giant stone tablets aren't dumped in
my front yard.

Nor do I believe that by posting a news message I've
automatically consented to receive email messages. To imply
that the one implies the other is equivalent to arguing that
because I've written a letter to the editor of a newspaper, I
therefore must accept private correspondence from any person
or corporation that has a subscription to that newspaper.

(In practice, I don't mind human-generated email messages, but
not automatic messages. If you can turn my munged email
address into a real email address, I probably won't mind you
emailing me. Don't abuse the privilege.)
I don't mind receiving private e-mails from people who recieved
the posting (either via Usenet or the gatewayed mailing list).
If I did, I wouldn't use my real e-mail address. But, I don't
want to receive machined generated trash or to be cc'd by
people following up to the article.
"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."

But that's wrong: it *shouldn't* be an normal email failure
response, because the message author is in no position to do
anything about it except to cease posting. That's a problem
with all mailing lists (that I know of).
I know of other mailing lists aren't configured that way: the
original author doesn't get bounce messages -- the sender of
the bounced e-mail gets the bounce message.

--
Grant Edwards grante Yow! Clear the laundromat!!
at This whirl-o-matic just had
visi.com a nuclear meltdown!!
Sep 11 '08 #8
Grant Edwards <gr****@visi.comwrites:
Could whoever is responsible for the gateway that is grabbing
my postings off of Usenet and e-mailing them out please fix the
headers in the mail messages so that I don't get the bounce
messages?

While you're at it, might as well fix it for everybody else
too. ;)

Its a bit rude to send out mass e-mail messages with headers
faked up so that the bounce messages go to somebody else.
Messages you submit to the newsgroup are forwarded to the mailing list.
When mail messages bounce, the MTA (Message Transfer Agent--the program
that handles mail) *should* send the bounce message to whatever is in
the Sender header, and only if that header does not exist, should it
use the From header. Messages forwarded by the gateway get a Sender
header which points back to the gateway. In other words, if a message
gets bounced back to the From address, the MTA does it incorrectly.
There is nothing the list administrator can do about it. You can try
complaining to the postmaster of the bouncing system, but that's about it.

In other words, your question in the first paragraph is already
implemented and was implemented from the beginning. It is not the
gateway's fault that there are systems that don't follow the standards.

--
Sjoerd Mullender, python-list administrator
Sep 11 '08 #9
On 2008-09-11, Dennis Lee Bieber <wl*****@ix.netcom.comwrote:
On Wed, 10 Sep 2008 21:36:36 -0500, Grant Edwards <gr****@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.
OK, you win. Since I don't care to get the bounce and
out-of-office messages, I'll fix my from: header when posting
to this group.

--
Grant Edwards grante Yow! Am I having fun yet?
at
visi.com
Sep 11 '08 #10
On Thu, 11 Sep 2008 17:27:33 +0200, Sjoerd Mullender wrote:
When mail messages bounce, the MTA (Message Transfer Agent--the program
that handles mail) *should* send the bounce message to whatever is in
the Sender header, and only if that header does not exist, should it use
the From header.
Who makes up these rules, and why should we pay the least bit of
attention to them?

It's one thing to say "right or wrong, that's what list admins do and you
have to deal with their behaviour whatever way you can". It's another
thing altogether to take the legalistic attitude of "never mind the
consequences, the standard is the standard and must be unthinkingly
obeyed". If the standard does more harm than good, then ignoring the
standard is the right thing to do. (Better would be to change the
standard, but that probably won't happen until there's a critical mass of
people who ignore the existing broken standard and form their own de
facto standard.)

A standard isn't "correct" just because it's a standard, it's merely
something that a committee has agreed to do. In other words, it's a
compromise. Now, such compromises might be good and useful, or they might
combine the worst of all opinions. Just because something is standardized
doesn't make it the right thing to do. If you want proof of this, I give
you the recently approved ISO standard for Microsoft's so-called "Office
Open XML" OOXML file format.

The standard behaviour of sending bounce and out-of-office messages to
the sender works well when sending email to individuals, but for mailing
lists it is pointless and counter-productive. Pointless, because the
sender can't do anything to fix the problem he's being notified about.
And counter-productive, because it is an anti-feature, something that
makes the mailing list more unpleasant and less useful. Anyone who has
regularly emailed to a large mailing list has surely experienced the
frustration of receiving bounce messages from perfect strangers.

To anyone who wishes to defend the process of sending mailing list
bounces back the sender, ask yourself this: what do YOU do with such
bounces when you receive them? If you ignore them or delete them (whether
manually or via a procmail recipe or some other automatic system) then
what benefit does the standard behaviour offer?

--
Steven
Sep 12 '08 #11
Steven D'Aprano wrote:
On Thu, 11 Sep 2008 17:27:33 +0200, Sjoerd Mullender wrote:
>When mail messages bounce, the MTA (Message Transfer Agent--the program
that handles mail) *should* send the bounce message to whatever is in
the Sender header, and only if that header does not exist, should it use
the From header.

Who makes up these rules, and why should we pay the least bit of
attention to them?

It's one thing to say "right or wrong, that's what list admins do and you
have to deal with their behaviour whatever way you can". It's another
thing altogether to take the legalistic attitude of "never mind the
consequences, the standard is the standard and must be unthinkingly
obeyed". If the standard does more harm than good, then ignoring the
standard is the right thing to do. (Better would be to change the
standard, but that probably won't happen until there's a critical mass of
people who ignore the existing broken standard and form their own de
facto standard.)

A standard isn't "correct" just because it's a standard, it's merely
something that a committee has agreed to do. In other words, it's a
compromise. Now, such compromises might be good and useful, or they might
combine the worst of all opinions. Just because something is standardized
doesn't make it the right thing to do. If you want proof of this, I give
you the recently approved ISO standard for Microsoft's so-called "Office
Open XML" OOXML file format.

The standard behaviour of sending bounce and out-of-office messages to
the sender works well when sending email to individuals, but for mailing
lists it is pointless and counter-productive. Pointless, because the
sender can't do anything to fix the problem he's being notified about.
And counter-productive, because it is an anti-feature, something that
makes the mailing list more unpleasant and less useful. Anyone who has
regularly emailed to a large mailing list has surely experienced the
frustration of receiving bounce messages from perfect strangers.

To anyone who wishes to defend the process of sending mailing list
bounces back the sender, ask yourself this: what do YOU do with such
bounces when you receive them? If you ignore them or delete them (whether
manually or via a procmail recipe or some other automatic system) then
what benefit does the standard behaviour offer?
I think you misunderstand. He's referring to the Sender header, not the
>From header. The messages the listbot sends out have a Sender header of
"py**********************************@python.o rg" (supposing the
subscriber's email address is us**@example.com). Bounces should be
directed to the bitbucket or list admin or whatever, not the user in the
>From header. kring.com just has a broken mail server.
--
Sep 12 '08 #12
On 2008-09-12, Matt Nordhoff <mn*******@mattnordhoff.comwrote:
I think you misunderstand. He's referring to the Sender
header, not the From header. The messages the listbot sends
out have a Sender header of
"py**********************************@python.o rg" (supposing
the subscriber's email address is us**@example.com). Bounces
should be directed to the bitbucket or list admin or whatever,
not the user in the From header. kring.com just has a broken
mail server.
So the statement below by Dennis Lee Bieber in message
97******************************@earthlink.com isn't actually
correct?
>>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.
--
Grant

Sep 12 '08 #13
Grant Edwards wrote:
On 2008-09-12, Matt Nordhoff <mn*******@mattnordhoff.comwrote:
>I think you misunderstand. He's referring to the Sender
header, not the From header. The messages the listbot sends
out have a Sender header of
"py**********************************@python.or g" (supposing
the subscriber's email address is us**@example.com). Bounces
should be directed to the bitbucket or list admin or whatever,
not the user in the From header. kring.com just has a broken
mail server.

So the statement below by Dennis Lee Bieber in message
97******************************@earthlink.com isn't actually
correct?
>>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.
I have no idea. My post was assuming that Sjoerd Mullender was correct.

With headers like "Return-Path", "Errors-To" and "Sender", ISTM the
mailing list software is doing everything it can to avoid bounces
getting sent to the user in the From header. If it's completely wrong,
then, well, it would be silly to have gone to the effort.
--
Sep 13 '08 #14
On Sep 12, 11:15*pm, Matt Nordhoff <mnordh...@mattnordhoff.comwrote:
Steven D'Aprano wrote:
On Thu, 11 Sep 2008 17:27:33 +0200, Sjoerd Mullender wrote:
When mail messages bounce, the MTA (Message Transfer Agent--the program
that handles mail) *should* send the bounce message to whatever is in
the Sender header, and only if that header does not exist, should it use
the From header.
Who makes up these rules, and why should we pay the least bit of
attention to them?
It's one thing to say "right or wrong, that's what list admins do and you
have to deal with their behaviour whatever way you can". It's another
thing altogether to take the legalistic attitude of "never mind the
consequences, the standard is the standard and must be unthinkingly
obeyed". If the standard does more harm than good, then ignoring the
standard is the right thing to do. (Better would be to change the
standard, but that probably won't happen until there's a critical mass of
people who ignore the existing broken standard and form their own de
facto standard.)
A standard isn't "correct" just because it's a standard, it's merely
something that a committee has agreed to do. In other words, it's a
compromise. Now, such compromises might be good and useful, or they might
combine the worst of all opinions. Just because something is standardized
doesn't make it the right thing to do. If you want proof of this, I give
you the recently approved ISO standard for Microsoft's so-called "Office
Open XML" OOXML file format.
The standard behaviour of sending bounce and out-of-office messages to
the sender works well when sending email to individuals, but for mailing
lists it is pointless and counter-productive. Pointless, because the
sender can't do anything to fix the problem he's being notified about.
And counter-productive, because it is an anti-feature, something that
makes the mailing list more unpleasant and less useful. Anyone who has
regularly emailed to a large mailing list has surely experienced the
frustration of receiving bounce messages from perfect strangers.
To anyone who wishes to defend the process of sending mailing list
bounces back the sender, ask yourself this: what do YOU do with such
bounces when you receive them? If you ignore them or delete them (whether
manually or via a procmail recipe or some other automatic system) then
what benefit does the standard behaviour offer?

I think you misunderstand. He's referring to the Sender header, not the>From header. The messages the listbot sends out have a Sender header of

"python-list-bounces+user=example....@python.org" (supposing the
subscriber's email address is u...@example.com). Bounces should be
directed to the bitbucket or list admin or whatever, not the user in the>From header. kring.com just has a broken mail server.
Ah, kring.com. I've been receiving bounces from there as well since
Wednesday. I just added it to my spam blacklist and forgot about it.

I'm just wondering what would happen if someone posted from
there... :-)
Sep 13 '08 #15
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 <gr****@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
Sep 15 '08 #16
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 <gr****@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.
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
field.

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 ?
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 ?

--
_____________

Maric Michaud
Sep 16 '08 #17
Le Monday 15 September 2008 16:45:12 Maric Michaud, vous avez crit*:
This is not sufficient for auto-responses, and given the following rfcs, it
would smart to both :
...
- 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
field.
--
_____________

Maric Michaud
Sep 17 '08 #18
Maric Michaud <ma***@aristote.infowrites:
Le Monday 15 September 2008 16:45:12 Maric Michaud, vous avez écrit*:
This is not sufficient for auto-responses, and given the following
rfcs, it would smart to both :
...
- 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.
Those fields have a defined use, and neither is suitable for munging
by mailing list software
<URL:http://woozle.org/~neale/papers/reply-to-still-harmful>.

The mandatory 'Return-Path' field records the address given in the
MAIL FROM command that transported the message. This is defined in RFC
2821.

The optional 'Reply-To' field, if used at all, records the address
that the author of the message suggests for return correspondence.
This is defined in RFC 2822.

Neither of these fields is suitable for tampering by mailing list
software; 'Return-Path' is set when the message is first sent, and
'Reply-To' is for use by the *author* of the message, not by software
that later handles it.

Mailing list programs record their information in several fields all
of which start with 'List-' and defined in RFC 2369. The purpose you
seem to be describing, the list posting address, is recorded in the
'List-Post' field, which records the URL to use for sending
contributions to the same maling list.

A summary of all header fields for use in mail and MIME is at RFC
4021.
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 field.
That mistake is easy to correct, without breaking standard definitions
of fields: the user can simply send the message again to the correct
destination. (I would suggest that, to help avoid repetition of this
mistake, the user then pressure their software vendor to incorporate
the "Reply to list" function making use of the standard 'List-Post'
field in every list message.)

Munging other fields such as 'Reply-To' leads to other common mistakes
that are far more damaging: replies that were intended only for the
author are sent to the 'Reply-To' address (as defined by the
standard), but instead get sent to the entire list. This damage is
usually impossible for the user to undo.

If the software you use still isn't following the internet mail
standards, then fix the software, or pressure your vendor to do so.

--
\ “Are you pondering what I'm pondering?” “Umm, I think so, |
`\ Brain, but what if the chicken won't wear the nylons?” —_Pinky |
_o__) and The Brain_ |
Ben Finney
Sep 17 '08 #19

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: Premshree Pillai | last post by:
Hello, I wrote an SMS to LiveJournal gateway using which you can post to your LiveJournal by sending an SMS. The source is available at...
7
by: Jim Hubbard | last post by:
First of all.....Happy New Year to you! I hope you have a successful and joyous new year. As for the HTTP Gateway examples.... I'm looking for some sample code that may illustrate techniques...
2
by: global | last post by:
Hi all, has anyone experience with XA transaction with twophase commit via gateway to host-db, my question is : where do I have to configure the parameters syncpoint=2 and connecttype=2 ? on...
1
by: global | last post by:
We have a Linux Server with UDB-EE 8.1.5, which is used as gateway for client connections to zOS-UDB. Our question : How many memory on the gateway does every connect user need ? We intend to...
0
by: Andy | last post by:
Hi, I'm currently developing my B2C application using ASP.NET. I have several questions regarding planning this application: In my application, I'll use my own shopping cart (developed totally...
0
by: bweaver4usenet | last post by:
Hi, all. I need some help getting a client up and running. Client Issue Client is using vc++ 6 and the Soap Tkt. Our web service is built with c# vs.net 2003. Can someone refer me to a sample I...
5
by: Godwin Burby | last post by:
Dear Pythoneer, I need to toggle the gateway ip of my windows xp machine quite often due to some software requirements. I just want to know whether i could do it programmatically using Python. If...
4
by: DierkErdmann | last post by:
Hi, I am trying to query google from within a python script using the Google-Api (pygoogle). The following piece of codes gives me a "SOAPpy.Errors.HTTPError: <HTTPError 502 Bad Gateway>", the...
0
by: Cameron Laird | last post by:
Who knows and/or manages bag.python.org? My e-mail server and the clp gateway are having a configuration disagreement that I'd like to solve. Please e-mail me privately. I'll report back to...
0
by: karpalmera | last post by:
We are currently migrating from OS/390 to Z/OS and our DB2 from DB2 4 to DB2 UDB8. However, our Oracle Database and Oracle gateway will remain the same..Oracle database is 7.2.3 and Oracle gateway is...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development projectplanning, coding, testing,...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.