I am fixing up the TMail mail library for Ruby. As part of this, I am
incorporating the patches the Ruby on Rails guys have done to the library
for their implementation. But I am checking each one :)
There is a test case for an unquoted @ char in the from line. Their
handling was to whack "@" into the ATOM_CHARS definition. Per RFC 2822
3.2.4 this is not a valid character for the ATOM set.
THat's a really terrible idea. Sooner or later anything that allows addresses
that are clearly syntactically invalid is going to run into trouble dealing
with some other agent that does enforce the rules.
The reason they put this in is to handle a bug in Apple Mail.app which was
not quoting the From field correctly if it contained a @ symbol. This has
been fixed in subsequent revisions of Mail.app.
Which was the right way to address the problem. Hacking everything else out
there in order to cater to one buggy applications is a sure path to madness.
The problem is, that
putting @ into ATOM_CHARS obviously breaks other test cases in the TMail
My question is 2 fold:
1) Removing @ is the obvious simple solution to return to the RFC2822 spec
as Apple have fixed Mail.app, but is this "bug" implemented elsewhere the
list members know of?
There used to be some LAN email system that used addresses of the form
(I'm sorry but I forget which one it was.) Occasionally one off these
addresses would leak out onto the Internet. But that's was quite some
time ago and I haven't seen anything comparable since.
I've also seen addresses of the form
used, but of course these are syntactically valid.
Should I spend the time to handle it in this edge
case in the library?
You have basically two viable choices: Treat it as the syntax error it is or
else add quotes to make it syntactically valid. Which one is appropriate is
impossible to say without knowing a lot more about the context in which this is
going to be used.
It looks like a bit of a hack to change the parser to
allow this and I don't want to go there if I don't _have_ to...
You definitely don't _have_ to.
2) Is @ actually allowed in the description area of the From field (ie:
From: mikel(_at_)me <mikel(_at_)me(_dot_)com> ) from a revision to the RFC
that I am
Not unless it is quoted. Stuff like
is unfortunately pretty common (unfortunate because it is udly and unnecessary
and tends to break simplistic parsers). But
is clearly bogus. And if you use it I predict the results are going to be wildy
variable - there are all sorts of ways to "resolve" such an error.