josh wrote:The term that grabs my attention from all this is "locally interpreted" -- where does it say that a quoted value must be interpreted the same as it's unquoted equivalent?
I see that from this example of RFC 822:
- Code: Select all
Note: In particular, quoting is NOT permitted within atoms.
For example when the local-part of an addr-spec must
contain a special character, a quoted string must be
used. Therefore, a specification such as:
Full\ Name@Domain
is not legal and must be specified as:
"Full Name"@Domain
My interpretation was that "locally interpreted" means just that -- the destination host does what it wants with that part -- quotes could mean one thing and no-quotes could mean another. Is that wrong?
It's my interpretation of RFC's example, that your interpretation is wrong. BTW: I couldn't find the term "locally interpreted" in 822 or 821.
Normally, I'd just go try and strip the quotes and be done with it -- the problem is that we'll have to re-think our header parsing because we use quotes to identify the "display name" and separate it from the account name -- eg, if the to: is:
"Bob Example" <bob@example.com>
we're zooming in on the quotes to get the Bob Example part for display.
I think you'll have to rethink it already because ther is no need for double quotes!
- Code: Select all
mailbox = addr-spec ; simple address
/ phrase route-addr ; name & addr-spec
route-addr = "<" [route] addr-spec ">"
phrase = 1*word ; Sequence of words
word = atom / quoted-string
So both of these are legal:
- Code: Select all
"Mikey-the-Mouse" <mikey@duck.village>
Mikey-the-Mouse <mikey@duck.village>
You'll have to focus on the "<" ... ">" part!
Rethinking our code in order to conform to an RFC is something we're happy to do (but, let's face it -- not required to do -- spamgourmet doesn't claim to be an SMTP compliant mail server) -- rethinking it because somebody else's supposedly SMTP compliant server doesn't conform is kind of a pain...
I totally agree with you. I don't want to force you to do anything about it. My first intent was to verify that spamgourmet's addresses are legal and to show GMX that they are wrong. Then I found out about the double quotes, allowing me to work around GMX' bug. Unfortunately this led me to find out about spamgourmet's non-RFC compliancy (at least I think so). Do whatever you like with that information and let me tell you that I will be more than happy to help wherever I can. I'm a quite experienced perl programmer (You can find me on perlmonks.org too), so if you need my time or knowledge, then tell me.