Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.kodak.com!news-nysernet-16.sprintlink.net!news-in-east1.sprintlink.net!news.sprintlink.net!nntp2.cerf.net!news.idt.net!howland.erols.net!panix!news.panix.com!panix5.panix.com!eli!not-for-mail
From: [email protected] (Eli Pogonatus)
Newsgroups: comp.mail.misc,news.admin.net-abuse.email,news.software.readers,comp.answers,news.answers
Subject: Email Addressing FAQ (How to use user+box@host addresses)
Supersedes: <[email protected]>
Followup-To: comp.mail.misc
Date: 4 Dec 1998 23:43:02 GMT
Organization: Some absurd concept
Lines: 1251
Approved: [email protected]
Expires: 29 Dec 1998 23:40:37 +0000
Message-ID: <[email protected]>
NNTP-Posting-Host: panix5.nfs100.access.net
Summary: How to add and use submailboxes to your email address.
Xref: senator-bedfellow.mit.edu comp.mail.misc:47219 news.admin.net-abuse.email:303664 news.software.readers:56092 comp.answers:34141 news.answers:145923

Archive-name: mail/addressing
Last-modified: (2 Jun 98 14:32:39)
URL: http://www.qz.to/~eli/faqs/addressing.html
Reason-for-last-modification: exim, qmail correction, trn4 update
Reason-for-previous-modification: MMDF updated, Pine updated

  If you can add information PLEASE DO. This is Unix centric because I
  have answers for Unix, not because I am trying to shun other
  platforms.

Questions covered
                                __________

   1. What?
   2. Why?
   3. Things to consider
   4. With qmail, how?
   5. With sendmail, how?
   6. With MMDF, how?
   7. With exim, how?
   8. With other MTAs, how?
   9. With mutt, how?
  10. With elm, how?
  11. Using them in trn, how?
  12. Using them in slrn, how?
  13. Using them in tin, how?
  14. Using them in nn, how?
  15. Using them in Gnus, how?
  16. Using them in knews, how?
  17. Using them in MH, how?
  18. Using them in pine, how?
  19. Using them elsewhere, how?
  20. Any other addressing suggestions?

    * Appendix
        1. General format of a From: header
        2. Filtering
        3. A word on address types
        4. Comprehensive plan for a new account
        5. Verifying Email Addresses

  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 "[email protected]" and
  "[email protected]" 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
      [email protected], [email protected],
      [email protected], 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 appendix of this FAQ.

       FAQ "launchers" for the Filtering Mail FAQ:

              o
                http://www.ii.com/internet/faqs/launchers/mail/filtering-
                faq/
              o http://www.best.com/~ii/faqs/archive/mail/filtering-faq/

       FTP sites for the Filtering Mail FAQ:

              o
                ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/filtering
                -faq (and at the rtfm mirror sites)
              o 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
      <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 <[email protected]> told me that with qmail all
      Alice has to do is "touch ~/.qmail-news" to indicate that she
      wants to receive mail at <[email protected]>. 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. She could put a single line consisting of "| exit
      100" there which will send a bland bounce message in the typical
      qmail fashion.

      This is a user level configuration; it creates boxes of the form
      <[email protected]>.

      (If your site already uses '-' in usernames, you may wish to chage
      the delimiter to another character. This is done at compile time.
      Version 1.00, change the value of USEREXT_BREAK in conf-unusual.h.
      Version 1.01, change the file "conf-break". Without this a user
      called "me-too" would mask some of the suffix space for a user
      called "me".)
                             ___________________

   5. With sendmail, how?

      Sendmail is an MTA.

      Phil Edwards <[email protected]> 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
      <[email protected]>. 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 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 whole address, including the "=string"
    part, appears in the $(address) variable for use in your
    .maildelivery file.

    An application note on how to use MMDF's "=" addressing feature to
    pre-sort incoming mail is available at this URL:

    http://www.irvine.com/~mmdf/auto-sort/index.html

    Note that MMDF doesn't preserve the "=string" information for use
    following delivery, so all handling of the $(address) information
    must take place at delivery time, using the .maildelivery file. So,
    in order to take advantage of MMDF's "=" addressing feature, you
    must use local delivery as opposed to POP delivery. (In other
    words, you need a login account on the same host that runs MMDF.)

    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 <[email protected]>.
                             ___________________

   7. With exim, how?

      Exim is a MTA.

      _Dom Mitchell <[email protected]> provides this method._

    First, you must find the directors section of the exim
    configuration file. In it, you will find a director like this:
    (it's from the default configuration file, most people should have
    it)


   userforward:
     no_verify,
     driver = forwardfile;
     check_ancestor,
     file = .forward,
   # filter

    You must then change it to look like this: (look in the exim manual
    for details)


   userforward:
     no_verify,
     suffix = "-*",
     suffix_optional,
     driver = forwardfile;
     check_ancestor,
     file = .forward,
     filter

    This will enable username-extension for any value of extension. But
    it will still get dropped into your default mailbox. To do more
    with this, you can use exim's built in filtering. You must create a
    ~/.forward file with the following first line:


   # Exim filter

    And you can then use rules like the following to save mail into
    different mailboxes:


   if $local_part_suffix is "-foo"
   then
     save $home/Mail/foo-folder
   elif $local_part_suffix is "-bar"
   then
     pipe "/usr/local/mh/lib/rcvstore +bar"
   endif
                             ___________________

   8. 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.
                             ___________________

   9. 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: [email protected] (Alice)

      To just change the Reply-to: header, she can use:


my_hdr Reply-To: [email protected] (Alice)
                             ___________________

  10. 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 from line.
                             ___________________

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

      At compile time it is possible to make the inews distributed with
      trn4 "lax". Just define "LAX_INEWS" in config.h and recompile.
      When the inews is "lax" it will check $USER and check $LOGNAME (in
      that order) first for username.
                             ___________________

  12. 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.
                             ___________________

  13. 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, bash, or zsh
               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.
                             ___________________

  14. 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 <[email protected]>

      She should be careful using semicolons (;) in it, unless escaped
      they separate lines. The appendix has sample formats acceptable
      for a 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 inews may
      work, but I have not tried.
                             ___________________

  15. 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 <[email protected]>\n")

  For news and mail she can change message-default-headers instead. The
      appendix describes the consideration for a 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.
                             ___________________

  16. Using them in knews, how?

      Knews is a newsreader.

      David Kennedy says that to use these, Alice needs to put a line in
      the Knews file like:


Knews.mailName:         alice+news

      He also offers the warning "knews = executable, Knews = config
      file." David was using version 0.9.8 when he offered the advice.
                             ___________________

  17. Using them in MH, how?

      Answer submitted by Philip Guenther. I had thought that MH was an
      MTA/MUA, but apparently it has a news section or I am confused.

      If you already have a components file for comp(1), then you just
      need to add a Reply-To: or From: line to it. Be aware that if you
      add a From: line then a Sender: line with your plain address will
      be added by post(8), so your plain address will appear somewhere
      in the message.

      If you don't already have a components file then create on in your
      MH mail directory (probably $HOME/Mail), that contains:


To:
Cc:
Subject:
--------

      then follow the previous directions. In order for replies and
      forwards to have the additional header you'll need to create or
      edit replcomp and forwcomp file, and then tell repl and forw to
      use them by editing your .mh_profile to include lines like:


repl: -form replcomp
forw: -from forwcomp

      For the default entries for those file check the repl and forw
      manpages.
                             ___________________

  18. Using them in pine, how?

      Pine is a MUA and newsreader.

      Pine tries to protect users from details and folly/ignorance, so
      it is not easy. It requires editing the source code and
      recompiling. If you feel up to it, here's how to do it.

      Edit the file pine/osdep/os-xxx.h of the source where xxx is the
      3-letter abbreviation for your platform. Uncomment out the section
      which applies to "ALLOW_CHANGING_FROM". Compile. Run it. Go to the
      pine configuration control/menu and add an entry in
      "customized-hdrs" for your new From: header. The appendix has
      sample formats acceptable for a from line.

      Nancy McGough has a good web page on this that goes into more
      detail. See it at either
      <URL:http://www.ii.com/internet/messaging/pine/changing_from/> or
      at
      <URL:http://www.best.com/~ii/internet/messaging/pine/changing_from
      />.
                             ___________________

  19. 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 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/zsh she would have this in her .profile:
           NEWSMAILBOX=+news
           export NEWSMAILBOX
                             ___________________

  20. 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 @ (a subtler variation on the above) [204.141.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: ". RFC 1036 specifies that only one of these
  variations should be used for news. I have tried other variations in
  mail and seen weird things happen when people with combined mail and
  news readers try to reply.


From: [email protected] (Alice)
From: Alice <[email protected]>
From: [email protected]

  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 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 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 a filtering resource page that gives information
  on the filters I use, including a link to an annotated version of my
  procmailrc. The page is at
  <URL:http://www.netusa.net/~eli/filtering.html>

  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
  <[email protected]>):


       :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 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
  <[email protected]> wrote on the procmail mailing list (to join, send
  subscription requests to
  <[email protected]>):


Michael Ghens <[email protected]> writes:
>I missed it, how does the + addressing get passed in
>
>as in [email protected]


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. Some mailing lists are run by
 # a special list user and so all lists from that machine will have
 # the same Return-Path:. This will break things in some situations.
 :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: [email protected]
 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 above on the usage of $1. For MMDF she can
  add to her .maildelivery file a line like:


addr = | A "/path/to/procmail -a $(address) -d alice"

  This will enable procmail filtering on the envelope as above. 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 "[email protected]" and send all of her
  posts from "[email protected]". 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/zsh 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 <[email protected]>
%(%[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 <[email protected]>
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
  "[email protected]", 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 <[email protected]>

  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
  inherently special about her using "+mail" and "+news" as the box
  names, it was just convient.
                          _____________________

  Verifying Email Addresses

  An often asked question in many newsgroups is "How can I verify an
  email address?" Sometimes people mean that they want to verify
  deliverability, sometimes they wish to verify valid syntax. The
  reasons for doing this vary from not wanting to accept invalid
  addresses in databases to wanting to discard all mail from invalid
  addresses. Neither verification variant is probably worth the effort.
  A sanity check might be worthwhile for catching obvious problems, but
  that is about it.

  Some of the techniques and pitfalls of the deliverability variant
  include:

    * Technique: "Verify that the destination machine name is real"

      Pitfalls: Between mailer exchange (MX records) redirections and
      wildcarded mailer exchanges for whole domains, a real address
      might be incorrectly flagged as bad. Combine that with temporary
      domain name service (DNS) and other transient problems that crop
      up and the complexity becomes apparent. Then you have to worry
      about routed addresses which have multiple hostnames to worry
      about, at least one of them probably not Internet accessible. UUCP
      bang ("!") paths are probably the best known variety of these.

    * Technique: "Use the SMTP VRFY command"

      Pitfalls: The most common pitfall with this is that most modern
      MTAs can be configured to not give out useful information in
      response to this or to the related EXPN command. Gateways,
      remailers, and various transient problems will further frustrate
      the would-be VRFYer.

    * Technique: "Attempt to mail to the address and check for a bounce"
      This sometimes includes actually sending mail, and sometimes just
      presenting a mail envelope to the mail server.

      Pitfalls: Some addresses never bounce mail even if it is an
      invalid address. Some addresses send faked bounces to some mail
      while still saving it for a recipient to read. Sometimes MTAs send
      informational transient error bounce messages to indicate the mail
      is spooled and delivery will be reattempted. These do not provide
      any information about validity of the address.

    * Technique: "Send mail to the address asking for a reply"

      Pitfalls: Getting a reply from this is the only way to be sure
      that an address was valid at the time you sent the mail. Since
      then, of course, the address could have become invalid. Not
      getting a reply doesn't help too much. Getting a bounce may help.

  The "check for bounce" tests are probably the best sanity check for
  address deliverability. Most addresses that bounce are invalid, most
  that don't are valid.

  The other variant, checking for valid syntax in an address, is doable,
  even when isolated from a network. It is not done easily however. Look
  at some of the valid address examples I gave earlier in this FAQ. The
  most pathological of the lot are probably these two:


< eli @ [ 204 . 141 . 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)

  The first one uses a domain literal, hence the [brackets]. Many people
  seem to think that it is fine to just use raw IP addresses in the
  route specification portion of an address. This is not true. Some
  mailers may accept it, but the proper notation uses brackets. Even
  when people do know that, they don't often know that in dot quad
  notation the third quad or both the second and third quads may be
  dropped if they are zeros. So "[127.1]" is equivalent to "[127.0.0.1]"
  and "[204.141.25]" is equivalent to "[204.141.0.25]".

  The second example is designed to break all regexps I have seen to
  check for a valid RFC 822 address. Jeffrey Friedl designed the most
  comprehensive one I have seen as an example for his book Mastering
  Regular Expressions. But because regular expressions may not match
  arbitrary paired nestings, e.g. properly matched parentheses, his
  effort was only designed to match two deep nesting. For other efforts
  to recognize addresses, that example includes six characters special
  in email addresses ( < > % @ ! : ) inside of comments in it. Not to
  mention all that whitespace, since it's allowed and improves
  readibility so much. :^)

  The two practical options are to write a full RFC 822 address parser
  or to "destructively" test a copy of the address. The first is not too
  difficult, but there are about three pages of BNF in RFC822 so it
  would probably take at least an afternoon's time to write. The second
  involves making a temporary copy of the address and then iteratively
  removing comments and other trouble- some things with say a regexp,
  and then feeding it to Friedl's verifier. Here's some perl code that
  should work for such a destructive preprocessor:


$copy = $address_to_test;

       $copy =~ s:\\.:a:g          ;    # replace \quoted stuff
       $copy =~ s:\\\n::gs         ;    # unfold lines
       $copy =~ s:"[^"]*":b:g      ;    # replace "quoted" stuff
while ( $copy =~ s:\([^()]*\)::g ) {;}   # (remove ((all) comments))

  The while loop removes nested comments one layer at a time. Friedl's
  code to check the address is available from his web pages:
  <URL:http://enterprise.ic.gc.ca/~jfriedl/regex/code.html>. It is about
  5k. If the copy is a syntactically valid address, then the original
  was as well.

  For a reasonable sanity check after my destructive rewriting, try
  this.


       $copy =~ s:\s+::g ;      # suppress whitespace

$lft = ($copy =~ y:<:<: ); # count <s
$rgt = ($copy =~ y:>:>: ); # count >s

  if (( $rgt != $lft ) || ( $lft < 0 ) || ( $lft > 1 )) {
               print "Address has invalid encapsulation\n";
}
else {
       # extract from encapsulation, if any
       $copy =~ s:.*<([^>]*)>.*:$1: ;

  if ( $copy =~ m:\@\.|\.\.|\.$: ) {
               print "Address has invalid dot placement\n";
}
elsif ( $copy =~ m:\@.*\@|^\@|\@$: ) {
               # There are legal addresses this will reject, but they
               # are mind-numbingly rare in practice. The most common
               # form is illustrated in this routed address for me:
               # <@alpha.netusa.net:[email protected]>
               print "Address has dubious \@ usage\n";
}
elsif(!($copy =~ y:@:@:)) {
               print "Address does not have an at sign\n";
}
elsif(!($copy =~ y:.:.:)) {
               print "Address does not have a dot\n";
}
else {          print "Address is probably good.\n";  }

}

  People often try to make other tests, many of them ill-advised. One
  common one is testing for a known top level domain (TLD). There are a
  lot of these, so doing it right involves a lot of tests or a very
  large and probably slow regexp. And that ignores the fact that new
  ones get added every now and then. As I write this there is the case
  of Zaire. Until recently it was ".zr", but now that Laurent Kabila has
  forced Mobutu Sese Seko out, the country has been renamed the
  Democratic Republic of Congo. It is not unreasonable to expect that a
  new TLD might be added for it.

  Another common but unreliable test is checking for spaces. Besides the
  case I have often illustrated of whitespace being allowed around the
  delimiting characters, it is legitimate to have spaces in the local
  part of an address. Try sending mail to my
  "echo request"@qz.little-neck.ny.us address. Don't worry about the
  subject, but put just the word "ping" in the body. This toy will reply
  from the address it receives your mail from. Thus you can see if your
  mailer is breaking things, such as sending the mail to "request@qz"
  instead.
    _________________________________________________________________

  Comments on this FAQ? Send me mail.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.