SPONSORED LINKS
Some background: In addition to runing the thinkpad mailing list, I have also written several email-related RFCs (including part of the MIME stuff) and a master's thesis on email gatewaying. I also used to chair the working group that is rewriting the core Internet email RFCs. (I had to abandon the role of WG chair when I accepted a position on the group that oversees development of such standards.) So if I have strong opinions about these issues, it's because I've been working on improving Internet email for the past ten years or so, and because I'm pretty well plugged into the Internet email standards community. Donald Whitestone writes: > Jim's problem is that the thinkpad list does not reset the FROM field to > the list, so his email client sees the message as from an individual, not > from the list. Thus, the auto replies - it's not possible for him to > filter his replies so the list doesn't get it because the list doesn't > identify itself! Jim's problem is that his mailer (or vacation program, or whatever) is sending automatic responses to the From field, when it should be using the SMTP MAIL FROM reverse-path, or address in the Return-Path field. A very many mailers -- including essentially every LAN mail system which connects to Internet mail via a gateway -- botch this. One result is that bounce messages from a list go to the sender of a message and not to the list maintainer. In general, automatic notifications (whether delivery notifications, nondelivery notifications, receipt notifications, or whatever) go to the return address in the message envelope, not to the From address in the message header. The return address on such notifications should be the empty string. This mechanism has been around for fifteen years or so, and is specifically intended to prevent various kinds of forwarding loops. The existing mail standards don't make this clear for anything except nondelivery reports, but they're currently being revised to clarify all kinds of things that have surfaced since they were written (c. 1980). It's inappropriate for a list to rewrite the From field. The From field indicates on whose behalf the message was sent (which is usually, but not always, the person who sent the message). Rewriting the From field makes it difficult for a list member to see who actually sent the message. It also makes it difficult for a list member to send a private reply to the author of that message. Ping Mai writes: > another problem with this list is it does not have a "Sender:" field in > the mail headers; every other mail list i've seen has the "Sender:" > field. i use the elm filter to divert mail from mailing > lists to separate folders. elm filter uses keywords like "To:", > and "Sender:" to filter mail. a lot the times people use > "cc" to send their messages to this mail list. and since the filter > does not support "cc", those messages would clobber my default mail > box. > > whoever administrating this list, would you please add > "Sender: owner-thinkpad" to the mail headers. Sender is supposed to indicate the person who actually sent the message (as opposed to the person or people on whose behalf the message is sent). RFC 822's description of the Sender field is somewhat muddy, but the examples make it clear that Sender is supposed to contain the address of the person *who actually sent the message* as opposed to an indication of any later processing. (In those days, lists were almost unknown, and it was common for a user agent to deliver mail directly to a recipient's SMTP server without any relaying.) RFC 822 includes a couple of examples of appropriate use of Sender. One is when a message is sent "From" several people, but the Sender field indicates who actually sent the message. Another is a message sent by a secretary on behalf of his/her boss: the From field has the boss's address, and the Sender field contains the secretary's address. You should be able to sort mail using the Return-Path field, which is derived from the SMTP MAIL FROM address, which (for this list) is always set to owner-thinkpad@cs.utk.edu. (RFCs 821 and 1123 require the MTA to add the Return-Path field when a message is delivered.) > While you can certainly argue that this is irrelevant to this point, there > are some other worrysome issues - the list does not indicate messages as > being from a mailing list AT ALL. No revamped from: address, no > X-Mailing-List: header, nothing. The danger there is that if some wiseass > subscribed this list to another similarly configured list, they would loop > messages forever, over and over again. Lists should contain some clear > indication they are lists in order to prevent such mischief. Agreed that this would be useful, but at present there is no standard marking for such. I'll add an X-Mailing-List field if I can determine that there's much support for using it for loop prevention. Axel Hartmann writes: > agreed. also, it would help to change the FROM field, > because I hate having to cut and paste the actual > adress of the list whenever I reply to something. > just as now, I have to change the adress, because > the default re: is your address, not the list's. > and I don't like to reply directly, because it bypasses > the list and I know that _I_ like to lurk and read > other peoples' questions _and_ answers... Most decent Internet mail user agents have separate functions for "reply to sender only" and "reply to sender and all recipients". If the list rewrites the From address you can only reply to the list. If the list *doesn't* rewrite the From address, and you have a decent user agent, you can do whichever one you wish. (I notice you are using Eudora Light. I don't use it myself, but I know the guys who write the Mac version and I'd be *very* surprised if they failed to include such a feature.) Josuha Hosseinof writes > Shouldn't the list set the precedence field when it is sent out to bulk? > I don't see that header in the messages sent out from the thinkpad list > and it usually prevents vacation programs from responding to the message. No. Precedence is nonstandard and not documented. In practice, it is used for so many different things, and its usage varies widely. My experience is that there is no Precedence keyword which has any beneficial effect (such as preventing some versions of vacation from responding) which does not also PREVENT THE MESSAGE FROM BEING DELIVERED through one or more gateways or mail exploders. Some gateways bounce mail which has a Precedence field which does not have one of certain keywords (hint: bulk is not one of them, and neither is list), and some list exploders refuse to forward any message containing a Precedence header (as a means to prevent loops). I used to use Precedence on my lists. I stopped doing so after several complaints from subscribers who weren't getting their mail, and only after I had tried every Precedence keyword I could find. Getting rid of Precedence has decreased the number of bounces and complaints from people who don't get their mail, and hasn't noticibly increased the number of vacation notices I get when I send messages to my lists. (Many auto-responders, particularly those on LAN email systems, don't recognize it.) Some vacation programs refuse to respond to any message that does not have the recipient explicitly listed in a To or CC message header. There was a proposal for an RFC describing an "auto-submitted" field which is intended to tip off auto-responders to not respond to such messages. (Unlike Precedence, it's not also intended to be used to determine queueing priority or whether a bounced message contains the subject content.) The proposal has expired, but I just asked the author to re-submit it, and will try to get it approved this time around. Keith Moore