dean@coplex.uucp (Dean Brooks) (02/07/91)
Recently I have installed Smail 3.1.18 on our machine and everything
is working perfectly. No problems whatsoever.
However, I have a question:
When creating a "mailing-list" using the ":include:" structure
inside the aliases file, is it possible to have smail make the Reply-To:
appear to be the mailing list name? Or perhaps the From: line?
What I want is to make the mailing list look as though the
mailing list (called "Area-Users") was the actual sender. This would
be lovely, as all replies would go back to the mailing list.
Anyone have any tips on how to accomplish this? Currently, the
(From:) line continues to show my name. The only way to get it
to work is to put a "Reply-To:" field. But replied messages will
of course not have this appended to THEM.
Thanks...
--
dean@coplex.UUCP Dean A. Brooks
Copper Electronics, Inc.
Louisville, Ky
UUCP: !uunet!coplex!deankyle@uunet.UU.NET (Kyle Jones) (02/07/91)
dean@coplex.uucp (Dean Brooks) writes: > Recently I have installed Smail 3.1.18 on our machine and everything > is working perfectly. No problems whatsoever. > > However, I have a question: > > When creating a "mailing-list" using the ":include:" structure > inside the aliases file, is it possible to have smail make the Reply-To: > appear to be the mailing list name? Or perhaps the From: > line? Please don't do either of these things. The From header shoudl reflect who the mail really is from. And the Reply-To header is for the author's use, not the use of forwarding agents such as mailing list exploders. If you make the From or Reply-To headers point at the mailing list, you make it difficult for subscribers to reply to just the author of the message. If you leave the headers alone the reply and reply-all commands of most mailers will do the expected thing. Reply will use From or Reply-To, and reply-all will these plus the contents of the To and Cc headers, one of which will presumably contain the mailing list address.
les@chinet.chi.il.us (Leslie Mikesell) (02/07/91)
In article <121545@uunet.UU.NET> kyle@uunet.UU.NET (Kyle Jones) writes: >dean@coplex.uucp (Dean Brooks) writes: > > When creating a "mailing-list" using the ":include:" structure > > inside the aliases file, is it possible to have smail make the Reply-To: > > appear to be the mailing list name? Or perhaps the From: > > line? >Please don't do either of these things. The From header shoudl >reflect who the mail really is from. And the Reply-To header is >for the author's use, not the use of forwarding agents such as >mailing list exploders. >If you make the From or Reply-To headers point at the mailing >list, you make it difficult for subscribers to reply to just the >author of the message. If you leave the headers alone the reply >and reply-all commands of most mailers will do the expected >thing. Reply will use From or Reply-To, and reply-all will these >plus the contents of the To and Cc headers, one of which will >presumably contain the mailing list address. There are some problems any way you try to handle this, mostly due to lack of compatibility among mailers. If you simply leave the message alone and forward it to everyone on the list, delivery error messages will go back to the sender who is unlikely to be able to do anything about the bad addresses in the list. If everyone ran sendmail perhaps you could use the Errors-To: header. They don't. Another recently-posted message shows how to get the "Envelope-From" of the message to point to the list maintainer, so the error messages will go there instead. However, lots of UA's on uucp machines generate replies back to the Envelope-From (the From_ line in uucp mail), since that is often more likely to work than whatever your neighboring site did to the "From: " line. So you're going to get some replies tossed at the list maintainer. Also, I haven't seen a mailer that allowed replying only to the "To:" address, so the reply will include a copy to the sender who is undoubtedly also on the list. Some software is smart enough to transport a single copy back to the list exploder which might be able to figure out that there is a duplication and eliminate it. Only some... Many UA's on uucp machines will generate replies to the To: and Cc: headers by evaluating the From_ line to generate a path back to the sending machine to be sure the address is evaluated in the same context as when originally sent. This means that if you do not rewrite the From_ line at the list exploder site, the reply is likely to be routed back through the senders site before going to the list exploder (and replies to the reply will keep growing longer paths). Does anyone have a universal solution? Les Mikesell les@chinet.chi.il.us
lear@turbo.bio.net (Eliot) (02/08/91)
What Kyle said, doubly so if members of your mailing list are being passed through mailers that lose the message envelope. We (bionet) just had the rather embarrassing situation where one of our JANET distribution nodes was doing just what you want, and we ended up in a mailer loop. Furthermore, if you modify the default behavior of a mailer, you will end up with people sending public messages that should have been private. -- Eliot Lear [lear@turbo.bio.net]
kyle@uunet.UU.NET (Kyle Jones) (02/08/91)
les@chinet.chi.il.us (Leslie Mikesell) writes about twiddling
with headers before sending mail to a mailing list:
> There are some problems any way you try to handle this, mostly due to
> lack of compatibility among mailers.
> If you simply leave the message alone and forward it to everyone on the
> list, delivery error messages will go back to the sender who is unlikely
> to be able to do anything about the bad addresses in the list.
True enough. I run a couple of mailing lists and I use a
program that adds a Sender header pointing to the -request
address for the lists. It also uses the sendmail's -f flag to
forge the envelope information for added insurance.
> If everyone ran sendmail perhaps you could use the Errors-To:
> header. They don't.
The Sender header should be sufficient for RFC 822 compliant mail
agents. Forging the envelope should suffice for the rest.
> Another recently-posted message shows how to get the
> "Envelope-From" of the message to point to the list
> maintainer, so the error messages will go there instead.
> However, lots of UA's on uucp machines generate replies back
> to the Envelope-From (the From_ line in uucp mail), since that
> is often more likely to work than whatever your neighboring
> site did to the "From: " line. So you're going to get some
> replies tossed at the list maintainer.
True enough. The question is whether the number of misdirected
messages be managable. I'd rather have a few messages come back
to me, than have even one bounced message fly back into the faces
of a hundred fifty mailing list readers. Forwarding the
occasional misdriected message to the list isn't difficult.
> Also, I haven't seen a mailer that allowed replying only to
> the "To:" address, so the reply will include a copy to the
> sender who is undoubtedly also on the list.
Not undoubtedly. Most of the time, if the mailing list isn't
gatewayed to the news system. Considerably less often than that
if there's a bidirectional link between USENET and the mailing
list. If you're not the list maintainer, you'll have a tough
time figuring it out whether the author is on the list or not.
> Some software is smart enough to transport a single copy back
> to the list exploder which might be able to figure out that
> there is a duplication and eliminate it. Only some...
Receiving a duplicate is better than receiving no reply at all!
> Many UA's on uucp machines will generate replies to the To:
> and Cc: headers by evaluating the From_ line to generate a
> path back to the sending machine to be sure the address is
> evaluated in the same context as when originally sent. This
> means that if you do not rewrite the From_ line at the list
> exploder site, the reply is likely to be routed back through
> the senders site before going to the list exploder (and
> replies to the reply will keep growing longer paths).
This reason aside, I recommend rewriting the From_ to keep UUCP sites from sending
boucnes back to the message author, instead of to the list
maintainer.
Old UUCP mailers simply don't have a way of distinguishing the
sender from the author, so I don't think there's any way to help
them, other than installing more capable mailers. The mailer
doesn't have to conform to the Internet RFCs as long as there is
_some_ way translating between the two and not losing essential
information. I.e. some way for a gateway between the two nets to
do the right thing.
> Does anyone have a universal solution?
Well, I don't, but I do have mailing list gateway software that
works well for the lists that I run. I understand that Rich $alz
also has some code that he's willing to share.tneff@bfmny0.BFM.COM (Tom Neff) (02/08/91)
I advocate sending them out this way:
From: originalguy@his.site (Original Posting User)
To: listname@my.site (The Mailing List)
Subject: Whatever
Reply-To: listname@my.site
Errors-To: listname-request@my.site
Sender: listname-request@my.site
original message text...
with the Envelope-From set to "listname-request," and Envelope-To
containing the actual list of recipients. This may not be what Kyle
likes, but I find it works best in the vast majority of cases, and
generates lots of nice revenue for Kyle's friends at UUNET.
Specifically, I do NOT want the default behavior of 'reply' to be only a
private response to the original poster. I do NOT want the user to have
to go to extra effort, or learn a different command, in order to respond
to the list as a whole. I set these lists up for discussion! That's
their raison d'etre, and it's my job as moderator to make it as easy as
possible for discussion to proceed. If someone wants to take a topic
"off the reservation" and continue it privately, let THEM make the
effort to edit headers.
Does this sometimes result in stuff that should be private getting sent
to the entire list? Yes, but only very rarely. I'm definitely erring
on the right direction. (I also have safeguards - see below.)
Does this ever result in bounce messages getting rebroadcast to the
entire list? Never! It just doesn't happen. Either mailers are smart
enough to see Errors-To: and Sender: and use that, or they're so dumb
they use the Envelope-From. Occasionally something will use From:
instead, so that the original poster gets the bounce, but not too often.
I periodically remind subscribers to forward me anything funny they
might get from the list. Certainly this would happen under anyone's
scheme, Kyle's included.
Finally, to keep things buttoned up, I have filters. Nothing from
MAILER-DAEMON, uucp et al. is permitted to go to the list. Nothing with
a null Subject line or a message body shorter than a few lines goes out.
Nothing saying "please {subscribe|add|remove|drop|change}" or a few
other variants is transmitted. Nothing from specified "watch list"
users, or mentioning "watch list" topics, goes. What doesn't go, gets
shunted to a holding pen for my inspection. If the filter was
overzealous I pipe the message back through with an approval stamp and
it goes out.
The goal is to make it easy for users to discuss topics of interest
worldwide, and easy for me to moderate the resulting flow.rickert@mp.cs.niu.edu (Neil Rickert) (02/09/91)
In article <20452337@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: >I advocate sending them out this way: > > From: originalguy@his.site (Original Posting User) > To: listname@my.site (The Mailing List) > Subject: Whatever > Reply-To: listname@my.site > Errors-To: listname-request@my.site > Sender: listname-request@my.site > > original message text... Most of what you described makes lots of sense. But not the 'Reply-To: ' header. Most reasonable MUAs will not generate a reply to the 'From: ' header if there is a 'Reply-To: ' present. This means hand typing the address, probably juggling multiple windows to look it up. In short, it is an invitation to mistyping and incorrect addresses. If you really must put the listname on 'Reply-To:' (and I obviously wish you wouldn't), can you also put the originator's address there. Unlike the 'From: ' header, the 'Reply-To: ' can have multiple addresses. With Reply-To: listname@my.site, originalguy@his.site (Original Posting User) then the MUA will generate both addresses, and someone who wishes to only respond to the originator can edit the headers as needed. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
tneff@bfmny0.BFM.COM (Tom Neff) (02/09/91)
In article <1991Feb8.194340.32390@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > Most reasonable MUAs will not generate a reply to the 'From: ' header if >there is a 'Reply-To: ' present. Quite right -- just the intended effect > This means hand typing the address, probably >juggling multiple windows to look it up. In short, it is an invitation to >mistyping and incorrect addresses. Oh, I don't know about that. Most 'reasonable' MUAs let you do stuff like including the entire message being responded to, including the header. When you do that you get the old From: line, and you can steal the address for your new To: field. Some MUAs even let you edit the original message in-place; you could then delete the Reply-To: line, save, and then hit 'r' for those cases where privacy was important. I agree that unsophisticated mail users will tend to reply to the list rather than the original poster under my scheme. That is exactly how I want it. My bet, and I think it's a good one, is that knowing when a _truly_ private response is called for correlates well with knowing how to tweak one's mailer to make it happen. If I were to set up a mailing list for some purpose other than public discussion, like NET-PEOPLE or FOR-SALE, then I'd set it to leave off the Reply-To: header line. Even within a standard discussion list, if someone sends me an article (to list-request) and asks that it be posted with replies redirected somewhere else, I can set it up. (Haven't automated it entirely.) I do that for special offers, association announcements and so forth, where I really DON'T want "yes, sign me up" responses to go to the list. > If you really must put the listname on 'Reply-To:' (and I obviously wish >you wouldn't), can you also put the originator's address there. Unlike the >'From: ' header, the 'Reply-To: ' can have multiple addresses. With > > Reply-To: listname@my.site, originalguy@his.site (Original Posting User) > > then the MUA will generate both addresses, and someone who wishes to >only respond to the originator can edit the headers as needed. Yes but unfortunately this would have the almost universal effect of making people get two copies of every response to their articles. I post an article about stereoscopes, then BOOM BOOM, here come all the answering articles, BOOM BOOM, one two. That's not cool. I'd spend X% of my moderator energy calming people down about it. Or more likely, neophytes would start posting followups twice because the first one didn't "take" or something. I guess it boils down to how one runs a list. I take a fairly aggressive, Digest-style approach, where I want to retain control over what appears and how. For the kinds of purposes I run lists to serve, this works well. There are other, more casual or private models where you'd want the header to look different.
kyle@uunet.UU.NET (Kyle Jones) (02/09/91)
Neil Rickert writes about Tom Neff's suggestions abotu mailing list gateways: > Most of what you described makes lots of sense. But not the 'Reply-To: ' > header. > > Most reasonable MUAs will not generate a reply to the 'From: ' header if > there is a 'Reply-To: ' present. This means hand typing the address, probably > juggling multiple windows to look it up. In short, it is an invitation to > mistyping and incorrect addresses. > > If you really must put the listname on 'Reply-To:' (and I obviously wish > you wouldn't), can you also put the originator's address there. Unlike the > 'From: ' header, the 'Reply-To: ' can have multiple addresses. With > > Reply-To: listname@my.site, originalguy@his.site (Original Posting User) > > then the MUA will generate both addresses, and someone who wishes to > only respond to the originator can edit the headers as needed. Good idea. I'd only add that you should put the list address at the end of the Reply-To header so that users of Berkeley Mail can easily rubout this address if they want to reply only to the author (i.e. when using ~h). BTW, a look at RFC 822 shows that multiple address _are_ allowed in the From header. But if From has multiple addresses the Sender header cannot be present. Odd. I recommend sticking with From and Sender.
lear@turbo.bio.net (Eliot) (02/09/91)
tneff@bfmny0.BFM.COM (Tom Neff) writes: >I advocate sending them out this way: > From: originalguy@his.site (Original Posting User) > To: listname@my.site (The Mailing List) > Subject: Whatever > Reply-To: listname@my.site > Errors-To: listname-request@my.site > Sender: listname-request@my.site > original message text... >with the Envelope-From set to "listname-request," and Envelope-To >containing the actual list of recipients. This may not be what Kyle ... Well, there are at least two issues here. First, you may be overwriting information given by the user - it is certainly not unheard of for a user to have a Reply-to address. Second, you are modifying the expected behavior of the recipient's UA. I would be very surprised if you haven't already seen messages sent through your mailing list that were meant to be private. When it comes to this area, it's a matter of erring on the side of privacy, or getting the message out to your list. The former will cause you grief because you won't see messages you should have seen; the latter will cause you grief because you will see a message that you shouldn't have seen. I believe the latter is worse because its hard to embarrass yourself by accidentally NOT sending a message out. It should be noted that RFC 1123 *did* address this issue. Now if only there weren't all those mailers that don't believe in envelopes. -- Eliot Lear [lear@turbo.bio.net]