11/10 Is it possible for CSUA to automaticall forward all emails sent to
<username>.* to username? So like joe.amazon@csua would go to
username@csua.
\_ no, that would require work
\_ Dumbass
\_ you already have user+detail
\_ How's that again? Does that mean joe+*@csua will go to joe?
\_ joe+<SMTPALLOWEDSTRING>@CSUA goes to joe@CSUA
\_ Do RFCs allow a plus in the user portion of address?
\_ Yes.
\_ Which one?
\_ RFC 822, Sec. 3.3
The localpart is word *(.word) (their notation),
according to sec. 6.1 of the same. 3.1 gives
word as atom or quoted-string. Atoms are
strings of chars except spaces, controls, and
special chars. None of these three categories
includes "+", so "+" is kept as part of the
atom token. The modern mail RFC, 2822, gives
a similar setup in its sec. 3.2.4, where atom
is explicitly 1*atext, with atext defined to
include valid chars, which are (quote):
ALPHA / DIGIT / ; Any character except controls,
"!" / "#" / ; SP, and specials.
"$" / "%" / ; Used for atoms
"&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" /
"_" / "`" / "{" / "|" / "}" / "~"
...And in all cases, it is left up to the
system to interpret localpart any way it likes.
Note that a lot of MTA's _will_ break on some of
those characters even though the RFC doesn't make
them illegal.
\_ more flexible is something like virtual
hosting username.domain.tld and forwarding
all mail to that smtp virtualhost to
username@domain.tld, letting you having
spamtag@username.domain.tld.
\_ qmail does this better. arbitrary hierarchies and easy
processing. and hyphen looks nicer than plus. --aaron |
http://csua.com/feed/