Archive-name: mail/addressing Last-modified: (18/05/97 02:39:03) URL: http://www.netusa.net/~eli/faqs/addressing.html Reason-for-last-modification: Lots of cleanup and clarifications. Reason-for-previous-modification: Added to tin, added elm information. Note crossposts and followups. If you can add information PLEASE DO. This is a lynx dump of an HTML file. Hyperlinks in the original are preceeded with [numbers] here and indexed at the end. Questions covered __________ 1. [1]What? 2. [2]Why? 3. [3]Things to consider 4. [4]With qmail, how? 5. [5]With sendmail, how? 6. [6]With MMDF, how? 7. [7]With other MTAs, how? 8. [8]With mutt, how? 9. [9]With elm, how? 10. [10]Using them in trn, how? 11. [11]Using them in slrn, how? 12. [12]Using them in tin, how? 13. [13]Using them in nn, how? 14. [14]Using them in Gnus, how? 15. [15]Using them elsewhere, how? 16. [16]Any other addressing suggestions? * [17]Appendix 1. [18]General format of a From: header 2. [19]Filtering 3. [20]A word on address types 4. [21]Comprehensive plan for a new account A good many of the examples in this FAQ are for a generic user, Alice, who receives mail at bobs-home.com. Her "login" at that host is "alice" and she uses boxes called "mail" and "news" in the localpart of her address. (The word "localpart" comes from RFC 822 which defines the now standard internet email address. It refers to the portion of the email address before the "@".) Bobs-home.com uses sendmail, and the examples reflect that. I find this a slightly more interesting way of giving examples than the crude "localpart@fully.qualified.domain.name" and "localpart@hostname.tld" that earlier versions of this FAQ used. Questions and answers: __________ 1. What? Mail transfer agents (MTAs) usually deliver mail to a single location for each user on the system. There are ways of having mail sent to more than one email address being delivered to the same user. The simplest conceptually is a mail alias. Aliases affect the whole machine and generally can only be set up by administrators. This is not convenient for anyone involved. So some MTAs have special ways of creating user level aliases. To keep these from interfering with other aspects of mail on the machine, these addresses are the username with a piece of punctuation and a boxname appended. ___________________ 2. Why? Traditionally it has been useful for special sorting of mail, eg casanova+anna@love.org, casanova+beth@love.org, casanova+cathy@love.org, etc. so that each of Anna, Beth, and Cathy send mail to a particular address and it gets treated specially. These days it is becoming popular as a way of providing special filtering (such as with procmail) on email addresses exposed to insecure channels such as Usenet. Nancy McGough's Filtering Mail FAQ, available at the URLs below, is a good start to finding out how to filter once you have the use of these addresses. See also the [22]appendix of this FAQ. FAQ "launchers" for the Filtering Mail FAQ: o [23]http://www.ii.com/internet/faqs/launchers/mail/filtering-faq/ o [24]http://www.best.com/~ii/faqs/archive/mail/filtering-faq/ FTP sites for the Filtering Mail FAQ: o [25]ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/filtering-faq (and at the rtfm mirror sites) o [26]ftp://ftp.netusa.net/users/eli/mail.filtering-faq.txt (not strongly recommended) ___________________ 3. Things to consider For these to be useful you really must have several things working together. Some of these things require system administrator privileges to implement, if they are not working on your system already, some do not. Some programs are as easy to configure as adding a line by hand to the headers shown, others require patching the code and recompiling. Hopefully the patches will become part of the official distributions, when needed, to prevent too much duplication of effort. Of primary importance, your system will need a mail transfer agent (MTA) that can understand these addresses when there is an attempt to give them to the system. Installing the MTA is definitely a task for a system administrator. In some cases, configuring the MTA will be as well. As a secondary, but not much less important, concern you will need to be able to configure the various user-level mail handing programs to use these aliases. There has not been a lot of interest in these in the past, so very few programs make it easy to do. The interest in filtering spam sent to addresses culled from Usenet has made configuring news posters my primary concern for this. I would like to add Q&As for mail user agents (MUAs), those programs that generally act as a user interface to mail, but I do not have a strong familiarity with any myself. As a last concern, you will want to know how to filter and sort mail for maximum effectiveness. The appendix currently has that information. Stephen R. van den Berg's procmail utility, available in source form at [27]<URL:ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail/>, is probably the best tool around. I found it difficult to learn without lots of well-documented examples, so I have tried to provide examples here. ___________________ 4. With qmail, how? Qmail is an MTA. Dave Sill <de5@sws5.ctd.ornl.gov> told me that with qmail all Alice has to do is "touch ~/.qmail-news" to indicate that she wants to receive mail at <alice-news@bobs-home.com>. Or she can put the name of a mailbox in the file and mail will be delivered there. If she doesn't have the .qmail-news file mail will normally be bounced. She can also use a .qmail-default file to catch any other case. If her .qmail is a single line consisting of just # all her mail will silently be dropped. This might be a useful way to force people to only send mail to her sub-boxes. She should be sure to have files specified for her other mail, however. Since silently discarding mail is the same as getting it and not responding (to an outside observer), arranging to have the mail bounce might be more useful. I don't know how to do that with qmail, though. This is a user level configuration; it creates boxes of the form <alias-boxname@bobs-home.com>. (At qmail compile time you can change the '-' delimiter to any character you wish by changing the value of CONF-BREAK in conf-unusual.h. Thanks to Claus Assmann <ca@informatik.uni-kiel.de> for pointing this out. This may seem trivial, but '-' is a legitimate character in a Unix username and I have seen it used.) ___________________ 5. With sendmail, how? Sendmail is an MTA. Phil Edwards <pedwards@cs.wright.edu> talked about how to do it with sendmail. Quoting him, because it doesn't paraphrase well, "The usual setup is in ruleset 5, consisting of a couple lines like R$+ + * $#local $@ $&h $: $1 R$+ + $* $#local $@ $2 $: $1 + * with another one or two later on in the same ruleset. (I'm doing this from memory; it'll probably differ from your .cf.) From there, it's up to your local delivery program." He suggests using procmail as the local delivery program; refer to the procmail installation instructions for (a little) more information. This is an admin level configuration; it creates boxes of the form <alias+boxname@bobs-home.com>. Once sendmail is configured, usage of the mailboxes is user controlled. Recent releases of sendmail come with this working already. (You can try to send yourself mail at login+boxname to see if this is already set up on your system. If not, you'll need to contact your system administrator.) ___________________ 6. With MMDF, how? MMDF is an MTA. _Jerry Sweet, maintainer of the [28]MMDF FAQ, has provided this detailed answer._ MMDF has long had an addressing feature of the form "mailbox=string", which causes a message so addressed to be delivered to "mailbox". The "=string" part is made available at receipt-time in the out-of-band (aka the envelope) recipient information--specifically the $(address) variable--for use in a user's MMDF .maildelivery file. That information can be used to sort incoming e-mail automatically somewhat more reliably than using the To: or Cc: fields. Unfortunately, MMDF doesn't preserve the out-of-band information for use following delivery. Unless a message specifically contains the address "mailbox=string@domain" in one of the RFC 822 header fields, then that address information is lost after the message is delivered, for example, to a POP mailbox. Therefore, all handling of the out-of-band information must take place at receipt-time. For detailed information about using the "=" feature in one's $HOME/.maildelivery file, refer to the MMDF maildelivery(5) on-line man page. This is a user level configuration; it creates boxes of the the form <alias=boxname@bobs-home.com>. ___________________ 7. With other MTAs, how? Nobody responded with smail, exim, etc solutions. If you are using the Andrew Messaging System (AMS), which you probably are if you have any other Andrew stuff on your system, then you have all of this already. In fact AMS introduced the concept. Read the documentation on FLAMES to find out how to use this. ___________________ 8. With mutt, how? Mutt is a MUA. To change the from header, Alice in her .muttrc defines additional lines with the command "my_hdr": my_hdr From: alice+mail@bobs-home.com (Alice) To just change the Reply-to: header, she can use: my_hdr Reply-To: alice+mail@bobs-home.com (Alice) ___________________ 9. With elm, how? Elm is a MUA. Elm stores extra headers to be used in mail in a .elm/elmheaders file in her home directory. She just needs to add a From: and/or Reply-To: header in that file and it will be used automatically. The headers should be properly formatted for mail. The appendix has sample formats acceptable for a [29]from line. ___________________ 10. Using them in trn, how? Trn is a newsreader. Trn uses two environment variables, NEWSHEADER and MAILHEADER, to control the headers that appear in posts and replies respectively. For the default values Alice can read the man page for her copy of trn. In the [30]comprehensive plan for a new account there is a sample configuration for trn. Suffice to say that she can add a from header herself with those variables, or she can add one by hand every time she sends mail or news. (I use a combination approach myself.) Note that newer versions of trn can be controlled by a user level configuration file to do this stuff, so she doesn't need to clutter the environment. The documentation should cover this. ___________________ 11. Using them in slrn, how? Slrn is a newsreader. Alice can add to her .slrnrc: username "alice-news" With newer versions of slrn, she can set them per-group with the article_mode_hook in the .slrn.sl file. ___________________ 12. Using them in tin, how? Tin is a newsreader. Some versions of tin use the USER environment variable to generate the local part of the email address. Here are two aliases resetting it just while using tin: csh or tcsh alias tin "env USER=alice+news tin" ksh or bash alias tin="env USER=alice+news tin" If you already have a tin alias, it will not be used. Both aliases will still allow you to give arguments to tin normally. Apparently there are some versions of the "unofficial" tin floating about that would allow her to set a "forged" address from the menu of configuration options. These are probably not too commonly installed. ___________________ 13. Using them in nn, how? Nn is a newsreader. As in trn, Alice can add the from line by hand while posting or configure nn to add them all the time. To get the latter, she would add this to her .nn/init file: set news-header From: Alice <alice+news@bobs-home.com> She should be careful using semicolons (;) in it, unless escaped they separate lines. The appendix has sample formats acceptable for a [31]from line. There is a mail-header setting for replies which works the same way. In an over-zealous interpretation of RFC 1036, nn will add a sender header to her posts with her un-boxed address. I don't know any way around this. Using my [32]inews may work, but I have not tried. ___________________ 14. Using them in Gnus, how? Gnus is a newsreader and MUA. To change them in news she adds to her .gnus: (setq message-default-news-headers "From: Alice <alice+news@bobs-home.com>\n") For news and mail she can change message-default-headers instead. The appendix describes the consideration for a [33]From: header. If she would also use Gnus to read and filter your mail, she can add an entry like the following to nnmail-split-fancy: ("to" "alice\\+news" (| ("subject" "re:.*" "misc") ("references" ".*@.*" "misc") "spam")) This says that all mail to this address is suspect, but if it has a Subject that starts with a Re: or has a References header, it's probably ok, and will be put in the "misc" group. All the rest goes to the "spam" group. This combines filters I use with those used by Tim Pierce. This will sort virtually everything into the right group. She still must check the "spam" group from time to time to check for legitimate mail, though. See the Info documentation for nnmail-split-fancy for details and variations. Mark T. Gray offers this further advice: Also gnus rather unfortunately will insert a Sender: line if it finds that the From: line has a different username than it thinks it should. To correct this put the following function redefinition in your .gnus file: (defun message-make-sender () "Return the \"real\" user address. This replaces the function in message.el which tries to ignore all user modifications, and give as trustworthy answer as possible." (cadr (mail-extract-address-components (message-fetch-field "from")))) It basically will return the same name as you stuck in her From: field above and gnus is then happy to leave out the Sender: line. Era Eriksson points out that this behavior is a configurable option of Gnus: (nconc message-syntax-checks '((sender . disabled)) ) This will preserve any existing overrides for message-syntax-checks by merely adding (sender . disabled) to the end of any preset values. If the variable is already being set e.g. in your site-wide initialization files, you should still be able to use this without clobbering anything. Another very useful function to put in her .gnus is the following hook which will query the user for the alias to add on the username whenever she sends a message: (defun my-address-choice () "This function chooses which alias-suffix to use" (interactive) (let ((alias-suffix (read-string "Which alias-suffix: ")) (alias)) (setq alias (concat user-login-name "+" alias-suffix "@bobs-home.com") mail-default-reply-to alias user-mail-address alias) (message "%s" alias))) (add-hook 'message-header-setup-hook 'my-address-choice) One person I have corresponded with is uncertain that will work and believes it to be of dubious value anyway. Caveat emptor. All of this question was written with Gnus 5.x in mind. I don't know how much will apply to earlier versions. ___________________ 15. Using them elsewhere, how? Well, if Alices uses sendmail directly to send mail (as I often do) it is pretty obvious how. Otherwise, I am not sure. Netscape and other programs which ask her to provide her own address will doubtlessly accept these addresses readily. If she uses a program which has inews inject news into an NNTP server, you might find the mini inews that I have hacked up useful. It works like inews with programs that use it in one of these forms: + inews -h < file (new inews) + inews < file (old inews) + inews -h file (new inews) + inews file (old inews) Anything that counts on command line options working is going to be disappointed. Older versions of lynx and all versions of rn, trn and nn that I know use inews in this fashion. This mini inews is from nn by way of lynx and has a number of hacks and bug fixes by me. Of primary concern is that it is now influenced by a NEWSMAILBOX environment variable when generating the From: header. If you would like to use it, the source is kept at [34]ftp://ftp.netusa.net/users/eli/mini-inews.tgz in a tar/gzip file. Alice would use one of these two set ups with this: A. In her .login or her shell rc file (.cshrc or .tcshrc) for csh or tcsh she would have: setenv NEWSMAILBOX +news B. For sh/ksh/bash she would have this in her .profile: NEWSMAILBOX=+news export NEWSMAILBOX ___________________ 16. Any other addressing suggestions? RFC822 is a long and complex document for those without strong computer science backgrounds. Parts of it will be understandable to most who read it, parts will not. Among other things it specifies how email addresses can be formatted. News and SMTP mail use RFC822 addresses. If she changes her address to one that is equivalent but written differently, she may be able to use procmail or another filtering tool process them. In particular the case sensitivity (upper vs. lower) of the localpart (that which comes before the @ reading left to right) is at the option of the destination machine. So if her MTA is (most are) case insensitive for those addresses, she can change the case of her name and all other mailers _should_ preserve that capitalization change. Humans typing the name tend not to be. Many mailers will preserve any "comments" included in an email address. RFC822 defines a comment: comment = "(" *(ctext / quoted-pair / comment) ")" ctext = <any CHAR excluding "(", ")", "\" & CR, & including linear-white-space> quoted-pair = "\" CHAR ; may quote any char linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE ; CRLF => folding CHAR 7-bit character LWSP linear whitespace: TAB and SPACE CR carriage return, an ASCII control character LF line feed, an ASCII control character This is not very legible to the typical human. What it means is a comment may contain any character, but some -- "(" ")" "\" CR -- must be "backslash escaped". That just means put a backslash (it is "\" and not "/") in front of characters whose special meanings that need to be escaped. Mostly. There is also that bit that comments may contain other comments; this will preclude using regular expressions to match addresses. Basically this translates to mean that your parentheses must match in the normal manner or else should be backslash escaped. So some valid comments are (hi-ya @lice here) (This is //-\\lice) (Let's (recurse (and (again (and (again (and (I'm (bored (now)))))))))) (\) whee) And some invalid comments would be (\/\/\/\/\) ()ops) (Spiff() Now, if that were not ugly enough, RFC822 says that there can be whitespace or comments by any delimiter. The delimiters are ( ) < > @ , ; : \ " . [ ] So the following are all legal and equivalent addresses for me: < eli @ netusa . net > <eli(jah)@netusa.net> < eli(Elijah)@netusa(not associated with usa.net).net > (Elijah) <eli@(dougs-home)netusa.net> < eli @ (the raw IP for mail (and thus subject to change)) [204.141.0.25] > <eli (Pogonatus (latin for <the bearded>))@ (qz (pronounced (queasy) ) \ .little-neck (I did not want that, but RFC1480 required it) .ny (New \ F%@!: York) .us (USA) or ) netusa (Located on Long Island) . net> (Elijah) Alice will find that a lot of mailers are not RFC822 compliant by trying some of those out, especially that last one. Most mailers seem happy to accept and preserve addresses like the second one from the top, so that may be a good way for Alice to modify her address for filtering purposes. "Preserve" does not mean that the comment will be in the same place, just that it will be included. The URL (uniform resource locator) mailto: scheme employs an "RFC822 addr-spec" address in the scheme specific part. According to my reading of the relevant RFCs, this means you can use comments in mailto: addresses, but the "%", "+", and whitespace characters should be "percent escaped". This escaping works by having a % followed by the hexadecimal value of the character so % => %25 + => %2b <space> => %20 Note that the "<" and ">" address delimiters should not be used in a URL. The URL format itself precludes the need for them. Other people disagree with my reading of the RFCs on this issue. They think comments are not allowed at all in the mailto: scheme. And it is true that some of the more obscure web browsers incorrectly percent escape parentheses, thus destroying the address. I think all versions of Netscape, Explorer, Mosaic, and Lynx get it right, but use with caution. ___________________________________ Appendix __________ General format of a From: header Here are the three generally accepted formats for a From: line. These are actually just special cases of RFC 822 addresses appearing after the string "From: ". I would advise you to stick with one of these for maximum interoperability of software, however. I have tried other variations and seen weird things happen. From: alice+news@bobs-home.com (Alice) From: Alice <alice+news@bobs-home.com> From: alice+news@bobs-home.com localpart will be your username+box; the fully qualified domain name is the full name of a machine you receive mail at; the name field has whatever "full name" you want to use. See the [35]other suggestions question for more information on RFC 822 addresses. __________ Filtering Well, now that Alice has a means of marking addresses for different handling, it is entirely reasonable that she might want some advice on how to use the marks effectively. Nancy McGough's Filtering Mail FAQ referenced [36]earlier in this FAQ is a good place to start learning about filtering tools. I am going to provide some advice here for what to filter with. I have found it very effective to give addresses exposed to Usenet in the form of a From: or Reply-To: line the most stringent filtering. I use procmail to handle my filtering, and this is the exact recipe I have for it (my Usenet posts go out from <usenet-tag@qz.little-neck.ny.us>): :0: * ^TOusenet-tag@qz * !^Subject:(.Re:|(.*[[({ -](was|Re):)) IN.junk IN.junk is a mbox file I check occasionally for false positives. Maybe 1-3% of it is false positives, often very easily distinguishable from the other stuff by the subject line. For those unfamilar with regular expressions (REs), that recipe is probably not very clear. Unfortunately REs are quite complicated and beyond the scope of this document. Jeffrey Friedl has written a good book about them, _Mastering Regular Expressions_ published by [37]O'Reilly and Associates. Many other sources cover them in less detail. Check your documentation for grep or egrep in particular. Be aware that most egreps today are much more sophisticated than the one procmail claims to be compatible with. In English, here's what that does. All mail sent to an address containing the phrase "usenet-tag@qz" which gets delivered to me will be tested for compliance with the second rule. The second rule says any of that mail which does not have a subject which begins with "Re:" or have a subject which anywhere in it contains a "[", "(", "{", " " or "-" followed immediately by a "was:" or "Re:" is put into the junk pile. The first part of the subject rule matches regular replies to posts and so they do not get junked. The second part recognizes the standard Usenet convention for changing a subject line, which is to put the new subject in front and then leave the old one there (sometimes parenthetically) after the word "was:". The types of mail this messes up on are those where someone takes the time to note the address, and uses it to send new mail later. This happens very infrequently in my experience. Tim Pierce and others have advocated checking for headers left in by newsreaders when filtering mail for Usenet addresses. This is subject to the same problem as my technique, but is additionally dependent on people not replying from copies found in DejaNews or Altavista and on relying upon newsreaders to add headers not specified in any standards document. That second bit makes it much too unreliable, in my opinion. _A note about that recipe_: My username is not "usenet" and that is not a submailbox for me. With sendmail (at least how I had it configured, YMMV with legacy sendmail.cf files) sub-boxing works just the same. Other MTAs might not work that way: the box name may get canonicalized out of the header. Mailers are not supposed to rewrite these headers, but it happens all the time. In any case, Philip Guenther <guenther@gac.edu> wrote on the procmail mailing list (to join, send subscription requests to <procmail-request@Informatik.RWTH-Aachen.DE>): Michael Ghens <michael@spconnect.com> writes: >I missed it, how does the + addressing get passed in > >as in michael+pgp@spconnect.com It shows up as $1 in your procmail, which you can then test with something like: ARG = $1 :0 * ARG ?? ^^pgp^^ pgp-folder :0 * ARG ?? ^^cypher-punks^^ cypher-punks-folder You can't test $1 directly, thus the assignment to ARG. ^^ is a weird procmail-specific regexp anchor. ^ and $ work just as well for what we want. (Gory details: ^ and $ match zero width conditions near line ends, while ^^ matches zero width conditions near string ends, much like \A and \Z in perl.) The main advantage of that recipe is $1 is set to the correct subbox even for Bcc'ed stuff when procmail is used as the local delivery agent from sendmail. (For certain sendmail.cf configurations at least.) One can AND test together in a procmail recipe in a number of ways. Including a number of separate * tests is one way, but it does not allow if-then-else type structures easily. For those { ... } grouping can be used. Here is an example for a submailbox named "news" employing my subject rule. ARG=$1 # Rules to apply to Usenet responses. :0 * ARG ?? ^news$ { # Where to send stuff missing Re: or was: in the subject :0: * !^Subject:(.Re:|(.*[[({ -](was|Re):)) IN.junk # Where to send the rest of it. :0: IN.good } _____________________ A word on address types In the simple mail transport protocol (SMTP) there are two types of sender address and two types of recipient address. This can be used for all sorts of obfuscation, and often is. The types are, respectively, the envelope addresses and the header addresses. Within the protocol, the difference between the two is that envelope addresses are specified with protocol commands and header addresses are specified as part of the mail data. There need not be any correlation between a From: or To: in the headers and those from the envelope. Most mailer delivery agents add a Return-Path: header that has the envelope from address when delivering mail. Some delivery agents add the envelope to address to a Received: header, but they do not do it when there is more than one recipient at a site. If either of the header to or from addresses are missing they will be added as an Apparently-To: or Apparently-From: using the envelope addresses. Why the two different types? Well it turns out that this is really useful for forwarding mail, especially for mailing lists. Mail sent to a mailing list will be delivered with the envelope from set to the list, the envelope to set to each member of the list, the header from set to the sender of the message, and the header to set to the list. Note that this is a convention, not a requirement. It makes a lot of sense for a mailing list, if you think about it. Similar behavior is used for blind carbon copied (BCC) mail. There is the problem however that people wishing to send bulk email (legitimately or not) can just set up a mailing list and it all gets delivered to the recipient without them knowing what address was used. The implications of this on sub-box filtering should be obvious. Unless your mail delivery agent does your filtering, all mail to desired mailing lists must be pre-filtered out and then all other Bcc'ed mail must be considered suspect. Here is a sample procmailrc for Alice if she were subscribed to several lists I read: # Process mail not specifically addressed to alice@bobs-home :0 * !^TOalice@bobs-home { # Sent by or to the quickcam driver developer list, a generic list # example. Return-Path:, assuming your mailer adds it, is another # good generic header to filter on. :0: * ^(Sender|To):.*quickcam-drivers IN.quickcam-list # Mail from the lynx developer's list -or- a Bcc'ed personal reply # to mail from it. This is a filtering (dis)advantage of lists that # modify the subject. :0: * ^Subject:.*LYNX-DEV IN.lynx-list # From the procmail list. All smartlist mailing lists have a handy # X-Loop header to filter on. :0: * ^X-Loop: procmail@informatik.rwth-aachen.de IN.procmail-list # Remaining mail is either a Bcc or an unknown mailing list. :0: IN.bcc-suspect } With MMDF filtering or procmail as her local delivery agent and some sendmail.cf magic, Alice can filter on the envelope address. For procmail see the example [38]above on the usage of $1. For MMDF she can add to her .maildelivery file a line like: addr = | A "/path/to/procmail -m /path/to/procmailrc $(address)" This will enable procmail filtering on the envelope as [39]above with the caveat that she must either set the DEFAULT variable or never fall off the end of the procmailrc. I'd recommend setting DEFAULT. To do that find out where the system keeps mail, "echo $MAIL" will usually give up that location, and put a line at the very top of the procmailrc with "DEFAULT=/where/the/mail/is" on it. Read the man page for maildelivery(5) for more information on a MMDF .maildelivery file. _____________________ Comprehensive plan for a new account This is a plan of action Alice, mail id alice at bobs-home.com could use. Bobs-home has sendmail configured to use + addresses, but not to use procmail as a delivery agent. (So procmail cannot know the envelope address.) Here is what she is going to do: bounce all mail addressed to "alice@bobs-home", accept mail addressed to "alice+mail@bobs-home", and filter mail to "alice+news@bobs-home". Then set the reply to for all of her mail to "alice+mail@bobs-home.com" and send all of her posts from "alice+news@bobs-home.com". This is hard to do on an old account, because too many people know the regular address. With a new account she can prevent them from ever getting into the habit of using it. She starts off by creating this .forward file to invoke procmail on all of her mail. The quotes used are an important part of this. "|IFS=' '&&exec /usr/local/bin/procmail -f-||exit 75 #alice" Here is a procmailrc that should do the filtering part. As yet this is _UNTESTED_. The DEFAULT variable should be defined by procmail to her system mailbox, setting it herself won't hurt, assuming she gets it right. # The system mailboxes at bobs-home are in /var/spool/mail/. DEFAULT=/var/spool/mail/alice # Where non-DEFAULT mailboxes live; Mutt uses $HOME/Mail/ by default. # Destination files in recipes will be relative to this unless they # start with a '/'. $HOME is set already. MAILDIR=$HOME/Mail # Where to log. LOGFILE=$HOME/.procmaillog # Set the shell, just to make sure it's /bin/sh SHELL=/bin/sh # Three line summary log for each piece of mail. LOGABSTRACT=yes # Addtionally, log the To: header. formail comes with procmail. LOG=`formail -X To:`" " # Accept real mail :0: * ^TOalice\+mail@bobs-home $DEFAULT # Accept mailer daemon mail :0: * ^FROM_MAILER $DEFAULT # Filter news replies # (The plus character in the address is "magical" in REs # and needs to be protected with a backslash) :0 * ^TOalice\+news@bobs-home { # Bad subject: not in reply form :0: * !^Subject:(.Re:|(.*[[({ -](was|Re):)) IN.junk # Reply to an article :0: $DEFAULT } # Bounce remainder, saving a copy in junk, just in case. The EXITCODE is # the value procmail will return to sendmail on exit. 67 is a sendmail # specific value that will cause a bounce message to be sent. EXITCODE=67 :0: IN.junk Alice uses trn to read and post news, so she sets the NEWSHEADER and MAILHEADER environment variables. sh/ksh/bash commands that go into a .profile for this are: # This is the default value of NEWSHEADER in 3.6 with a from line prepended. NEWSHEADER='From: Alice <alice+news@bobs-home.com> %(%[followup-to]=^$?:%(%[followup-to]=^%n$?:X-ORIGINAL-NEWSGROUPS: %n ))Newsgroups: %(%F=^$?%C:%F) Subject: %(%S=^$?%"\n\nSubject: ":Re: %S) Summary: Expires: %(%R=^$?:References: %R )Sender: Followup-To: %(%{REPLYTO}=^$?:Reply-To: %{REPLYTO} )Distribution: %(%i=^$?%"Distribution: ":%D) Organization: %o Keywords: %[keywords] Cc: \n\n' # This is the default value of MAILHEADER in 3.6 with a from line prepended. MAILHEADER='From: Alice <alice+mail@bobs-home.com> To: %t Subject: %(%i=^$?:Re: %S %(%{REPLYTO}=^$?:Reply-To: %{REPLYTO} )Newsgroups: %n In-Reply-To: %i) %(%[references]=^$?:References: %[references] )Organization: %o Cc: Bcc: \n\n' export NEWSHEADER MAILHEADER This will cause the Originator: header to be set to "alice@bobs-home.com", but since she is bouncing that address it shouldn't matter too much. If she really wanted to clean that up, she could use a different inews and Pnews. (Stuff that is posted and mailed using the Cc: header on a post will appear to be from the "alice+news" address.) Alice uses mutt to read and reply to mail, so she creates a .muttrc with the following line it it: my_hdr From: Alice <alice+mail@bobs-home.com> When Alice wants to subscribe to mailing lists she will have to adjust her .procmailrc accordingly. She also can't get Bcc'ed mail as sent by most programs. As a last comment let me state that there is nothing inheritantly special about her using "+mail" and "+news" as the box names, it was just convient. _________________________________________________________________ Comments on this FAQ? [40]Send me mail. References 1. http://www.netusa.net/~eli/faqs/addressing.html#what 2. http://www.netusa.net/~eli/faqs/addressing.html#why 3. http://www.netusa.net/~eli/faqs/addressing.html#things 4. http://www.netusa.net/~eli/faqs/addressing.html#qmail 5. http://www.netusa.net/~eli/faqs/addressing.html#sendmail 6. http://www.netusa.net/~eli/faqs/addressing.html#mmdf 7. http://www.netusa.net/~eli/faqs/addressing.html#others 8. http://www.netusa.net/~eli/faqs/addressing.html#mutt 9. http://www.netusa.net/~eli/faqs/addressing.html#elm 10. http://www.netusa.net/~eli/faqs/addressing.html#trn 11. http://www.netusa.net/~eli/faqs/addressing.html#slrn 12. http://www.netusa.net/~eli/faqs/addressing.html#tin 13. http://www.netusa.net/~eli/faqs/addressing.html#nn 14. http://www.netusa.net/~eli/faqs/addressing.html#gnus 15. http://www.netusa.net/~eli/faqs/addressing.html#elsewhere 16. http://www.netusa.net/~eli/faqs/addressing.html#additional 17. http://www.netusa.net/~eli/faqs/addressing.html#appendix 18. http://www.netusa.net/~eli/faqs/addressing.html#from 19. http://www.netusa.net/~eli/faqs/addressing.html#filter 20. http://www.netusa.net/~eli/faqs/addressing.html#smtp 21. http://www.netusa.net/~eli/faqs/addressing.html#new-acc 22. http://www.netusa.net/~eli/faqs/addressing.html#appendix 23. http://www.ii.com/internet/faqs/launchers/mail/filtering-faq/ 24. http://www.best.com/~ii/faqs/archive/mail/filtering-faq/ 25. ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/filtering-faq 26. ftp://ftp.netusa.net/users/eli/mail.filtering-faq.txt 27. ftp://ftp.informatik.rwth-aachen.de/pub/pack