rfc822 module problem

[Chuck Swiger]

Francois Pinard wrote:
[ ... ]
 > I do not know if RFC 822 allows ` +'.  You assert it does?

Yes. (*)  Please note that RFC-822 is being obsoleted by RFC-2822.

The plus sign is allowed and is commonly used to specify a mailbox or 
other information in the local-part of an email address.  For example, 
mail sent to <cswiger+python at mac.com> should be delivered to the IMAP 
mailbox on my Mac.com account named "python", rather than INBOX.

> P.S. - All this discussion is a bit academical, yet I would prefer if the
> `rfc822' module was clearly sitting on one side or the other.  Despite I
> would prefer it to be stricter, I confess I'm not in deep love with
> RFC 822.  For long, people quoted this RFC as an excuse for not building
> 8-bit clean mail transports.

I'm torn between agreeing with you and sighing.  :-)  People have used 
RFC-822 as an excuse for some awfully silly things.  RFC-2822 and the 
MIME spec tries to do better.

Yes, the world would be a better place if all connections were capable 
of handling unescaped 8-bit traffic without restrictions.  The world has 
not become a better place as a result of people writing code which 
_depends_ on SMTP being 8-bit clean.  In particular, see RFC-1652, SMTP 
Service Extension for 8bit-MIMEtransport:

    "...Note that this
    extension does NOT eliminate the possibility of an SMTP server
    limiting line length; servers are free to implement this extension
    but nevertheless set a line length limit no lower than 1000 octets.
    Given that this restriction still applies, this extension does NOT
    provide a means for transferring unencoded binary via SMTP."

> Another thing I never fully understood is
> the absence of significant pressure on POSIX to use international dates
> (ISO 8601), so we are now stuck with American dates all over the planet.

If ISO 8601 means dates like 2003/5/16, be aware that (at least some) 
Americans prefer that format, since it sorts numerically in a nice 
fashion.  I've been using it for DNS SOA serial #'s for quite some time.

--
-Chuck

(*): I'm not sure that people interested in Python are normal, by 
whatever definition one chooses to apply :-), but I am fairly sure that 
"normal" people would not be terribly interested in the detailed 
augmented BNF definitions from the RFC documents.  For pedants, however, 
here are the details.

ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt defines "+" to be a part 
of legitimate "atoms", or lexical items which occur within header fields 
such as email addresses.  (*)

atext           =       ALPHA / DIGIT / ; Any character except controls,
                         "!" / "#" /     ;  SP, and specials.
                         "$" / "%" /     ;  Used for atoms
                         "&" / "'" /
                         "*" / "+" /
                         "-" / "/" /
                         "=" / "?" /
                         "^" / "_" /
                         "`" / "{" /
                         "|" / "}" /
                         "~"

atom            =       [CFWS] 1*atext [CFWS]

dot-atom        =       [CFWS] dot-atom-text [CFWS]

dot-atom-text   =       1*atext *("." 1*atext)

[ ... ]

3.4. Address Specification

    Addresses occur in several message header fields to indicate senders
    and recipients of messages.  An address may either be an individual
    mailbox, or a group of mailboxes.

address         =       mailbox / group

mailbox         =       name-addr / addr-spec

name-addr       =       [display-name] angle-addr

angle-addr      =       [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
[ ... ]

3.4.1. Addr-spec specification

    An addr-spec is a specific Internet identifier that contains a
    locally interpreted string followed by the at-sign character ("@",
    ASCII value 64) followed by an Internet domain.  The locally
    interpreted string is either a quoted-string or a dot-atom.  If the
    string can be represented as a dot-atom (that is, it contains no
    characters other than atext characters or "." surrounded by atext
    characters), then the dot-atom form SHOULD be used and the
    quoted-string form SHOULD NOT be used. Comments and folding white
    space SHOULD NOT be used around the "@" in the addr-spec.

addr-spec       =       local-part "@" domain

local-part      =       dot-atom / quoted-string / obs-local-part

domain          =       dot-atom / domain-literal / obs-domain