GMX says: e-mail addresses are against standards

Discussion re sg development. You don't have to be a developer.

GMX says: e-mail addresses are against standards

Postby Skeeve » Thu Aug 19, 2004 1:30 pm

I wanted to reply to a mail I received throug spamgourmet. The reply address was +XXXXXXX+skeeve+2d8fad51d6.XXXXXXX#yaho ... ourmet.com

Sending was refused and when I asked support they told me that the address is "against all standards". They didn't tell me the standards yet.
Skeeve
 
Posts: 38
Joined: Tue Jun 01, 2004 9:46 pm

Postby josh » Thu Aug 19, 2004 2:29 pm

what can I say? -- it's not :)
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Postby Skeeve » Thu Aug 19, 2004 4:07 pm

josh wrote:what can I say? -- it's not :)
It's easy: Please tell me what to show them to proove your statement.
Skeeve
 
Posts: 38
Joined: Tue Jun 01, 2004 9:46 pm

Postby SysKoll » Thu Aug 19, 2004 7:18 pm

Easy. Email address format obeys conventions fixed by documents called RFCs. The relevant RFC is RFC821 (see http://www.rfc.net/rfc821.html). Part 4.1.2 of RFC821 specifies the acceptable char set for email addresses. To quote the relevant parts:

Code: Select all
<mailbox> ::= <local-part> "@" <domain>
<local-part> ::= <dot-string> | <quoted-string>
<dot-string> ::= <string> | <string> "." <dot-string>
<string> ::= <char> | <char> <string>
<char> ::= <c> | "\" <x>
<c> ::= any one of the 128 ASCII characters, but not any
                      <special> or <SP>
 <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
                      | "," | ";" | ":" | "@"  """ | the control
                      characters (ASCII codes 0 through 31 inclusive and
                      127)



Since the + and # signs are not special chars, they are acceptable characters in the local part (before the @) of an email address. So there.

Tell GMX that lame excuses are not substitute for fixing their bugs.
Last edited by SysKoll on Fri Aug 20, 2004 5:33 pm, edited 1 time in total.
-- SysKoll
SysKoll
 
Posts: 889
Joined: Thu Aug 28, 2003 9:24 pm

Postby Skeeve » Thu Aug 19, 2004 8:46 pm

SysKoll wrote:Easy. Email address format obeys conventions fixed by documents called RFCs. The relevant RFC is RFC821

You mean RFC 2821. What I found is RFC 822 telling me this (just the relevant parts):
Code: Select all
address     =  mailbox                      ; one addressee
                 /  group                        ; named list
mailbox     =  addr-spec                    ; simple address
                 /  phrase route-addr            ; name & addr-spec
addr-spec   =  local-part "@" domain        ; global address
local-part  =  word *("." word)             ; uninterpreted
                                                 ; case-preserved
word        =  atom / quoted-string
atom        =  1*<any CHAR except specials, SPACE and CTLs>
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                                 ;   quoted chars.

Now guess what! GMX seems to accept "spamgourmet-address-local-part"@spamgourmet.com but spamgourmet seems not to like those :-(

Now tell me who is wrong? GMX or you?

P.S. I think unfortunately you are partly wrong as RFC 2821 is for SMTP and we are dealing here not with the SMTP part but with the text message itself, which RFC822 deals with. Correct me if I'm wrong.
Skeeve
 
Posts: 38
Joined: Tue Jun 01, 2004 9:46 pm

Postby josh » Fri Aug 20, 2004 12:37 am

Thanks, guys, for looking all that up.

Skeeve, you're saying that an address like +XXXXXXX+skeeve+2d8fad51d6.XXXXXXX#yaho ... ourmet.com is making through GMX but not spamgourmet?
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Postby Skeeve » Fri Aug 20, 2004 6:04 am

josh wrote:Thanks, guys, for looking all that up.

Skeeve, you're saying that an address like +XXXXXXX+skeeve+2d8fad51d6.XXXXXXX#yaho ... ourmet.com is making through GMX but not spamgourmet?


+XXXXXXX+skeeve+2d8fad51d6.XXXXXXX#yaho ... ourmet.com
is rejected by GMX
but accepted by spamgourmet

"+XXXXXXX+skeeve+2d8fad51d6.XXXXXXX#yahoo.com"@spamgourmet.com
is accepted by GMX
but fails to be forwarded by spamgourmet

I tried both addresses with another account of mine. The first one went through flawlessly. The later one, the quoted version, is still lost in action ;-)

If I understand RFC 822 correct, the quoted one is a correct address that should be recognized by spamgourmet.
Skeeve
 
Posts: 38
Joined: Tue Jun 01, 2004 9:46 pm

Postby SysKoll » Fri Aug 20, 2004 5:34 pm

I am sorry for the confusion, I mean RCF821, which is the one I quoted. I fixed the message above.

sg obeys RFC 821, not sure about 822.
-- SysKoll
SysKoll
 
Posts: 889
Joined: Thu Aug 28, 2003 9:24 pm

Postby josh » Fri Aug 20, 2004 6:52 pm

"+XXXXXXX+skeeve+2d8fad51d6.XXXXXXX#yahoo.com"@spamgourmet.com
is accepted by GMX
but fails to be forwarded by spamgourmet


But we accepted it, didn't we -- what happens after that isn't specified by an RFC is it? :)

Seriously, the format (without the quotes) is what our code uses to distinguish a user sent message from a user-bound message. If it offends an RFC, please say how.
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Postby Skeeve » Fri Aug 20, 2004 9:18 pm

josh wrote:
"+XXXXXXX+skeeve+2d8fad51d6.XXXXXXX#yahoo.com"@spamgourmet.com
is accepted by GMX
but fails to be forwarded by spamgourmet


But we accepted it, didn't we -- what happens after that isn't specified by an RFC is it? :)

Don't ask me. If I'm not mistaken, the real local part is that between the quotes.

josh wrote:Seriously, the format (without the quotes) is what our code uses to distinguish a user sent message from a user-bound message. If it offends an RFC, please say how.

It offends RFC 822. "local-part"@do.main is the same as local-part@do.main if I'm not completely mistaken. See this example, taken from RFC822:
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
Last edited by Skeeve on Fri Aug 20, 2004 9:36 pm, edited 1 time in total.
Skeeve
 
Posts: 38
Joined: Tue Jun 01, 2004 9:46 pm

Postby Skeeve » Fri Aug 20, 2004 9:19 pm

SysKoll wrote:I am sorry for the confusion, I mean RCF821, which is the one I quoted. I fixed the message above.

sg obeys RFC 821, not sure about 822.

But RFC821 is for SMTP. GMX should obey RFC822.
Skeeve
 
Posts: 38
Joined: Tue Jun 01, 2004 9:46 pm

Postby SysKoll » Fri Aug 20, 2004 9:42 pm

Skeeve,

GMX is still wrong. RFC2822 (http://www.faqs.org/rfcs/rfc2822.html) defines an atext as:

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


Note the presence of the + and # among the chars. So sg uses a set of atext chars (and only atext chars) in its addresses. Now, let's continue. The same RFC says:


Code: Select all
mailbox         =       name-addr / addr-spec
name-addr       =       [display-name] angle-addr
angle-addr      =       [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
addr-spec       =       local-part "@" domain
local-part      =       dot-atom / quoted-string / obs-local-part


Ah, it says the part of an address before the "@" can be a quoted string, eh? So does that mean "whatever"@spamgourmet.com should be unquoted by sg and treated the same as whatever@spamgourmet.com?

Nope. Au contraire. Let's see part 3.4.1 of RFC2822:

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.


The last sentence is quite clear: if you don't absolutely need the quotes, you should not use them.

Since we can legally write our addresses with atext chars, we don't need the quotes, and we do not (and should not) use them. By requiring them, GMX breaks the RFC.

Please feel free to send this email to them.
-- SysKoll
SysKoll
 
Posts: 889
Joined: Thu Aug 28, 2003 9:24 pm

Postby Skeeve » Sat Aug 21, 2004 12:22 am

SysKoll wrote:Skeeve,

GMX is still wrong. RFC2822 (http://www.faqs.org/rfcs/rfc2822.html) defines an atext as:
[...]
Ah, it says the part of an address before the "@" can be a quoted string, eh? So does that mean "whatever"@spamgourmet.com should be unquoted by sg and treated the same as whatever@spamgourmet.com?

Nope. Au contraire. Let's see part 3.4.1 of RFC2822:

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.


The last sentence is quite clear: if you don't absolutely need the quotes, you should not use them.


I aggree with you, that GMX breaks that RFC and I really do hope they will fix it, but I fear they won't.

OTOH I disaggree with you about the quote vs. unquote part. RFC says the quoted form should not be used. It didn't say the quoted form must not be used. I'm not native english but I think "should not" means that you may use it if you like to.

The only advantage would be: It will work with buggy GMX and maybe other programs that pretend to be clever...
Skeeve
 
Posts: 38
Joined: Tue Jun 01, 2004 9:46 pm

Postby SysKoll » Sat Aug 21, 2004 5:48 pm

Skeeve,

The English language has nothing to do with it. When an RFC uses the terms SHOULD, MIST, etc., these terms are defined very strictly as per RFC2119. The term SHOULD NOT is rather strong as per this definition:

SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
-- SysKoll
SysKoll
 
Posts: 889
Joined: Thu Aug 28, 2003 9:24 pm

Postby Skeeve » Sat Aug 21, 2004 8:32 pm

Okay. So let's see whether RFC2119 gives us a hint what to do in order to work arounf GMX...

SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful
, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.


It will be very useful to implement the quote-acceptance ;-)
Skeeve
 
Posts: 38
Joined: Tue Jun 01, 2004 9:46 pm

Next

Return to Developers

Who is online

Users browsing this forum: No registered users and 1 guest