On 20 Dec 2016, at 9:58, Arkadiusz Miśkiewicz wrote:
> but google refuses these claiming that it violates RFC-5321
> (which IMO isn't true as this is valid RFC5321 address)
Your opinion is in disagreement with the syntax on Page 41 of RFC5321.
Note that an "Atom" in that ABNF definition cannot c
On Tue, Dec 20, 2016 at 7:20 AM, Al Iverson
wrote:
>
> In your example - you have two periods in a row. This is widely
> understood to be disallowed.
>
> http://serverfault.com/questions/395766/are-two-
> periods-allowed-in-the-local-part-of-an-email-address
Or just quote the localpart and then
In article you write:
>I would bet Gmail is behaving correctly
Yup.
>As you can see then you can use dots to separate atoms which in turn are not
>allowed to include dots. There must be at least a
>single atom character after dot.
If you read the rest of that part of RFC 5321, you can put what
It looks like srs would need to use the 'URL and Filename safe'
alphabet from rfc 4648, with minus and underline for the 62nd and
63rd, to provide an encoded string which all MTAs and MUAs ought
to accept.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Periods aren't the issue. A single period works just fine.
$ telnet aspmx.l.google.com 25
[...]
mail from:
250 2.1.0 OK g8si23063144wje.166 - gsmtp
quit
221 2.0.0 closing connection g8si23063144wje.166 - gsmtp
Connection closed by foreign host.
In your example - you have two periods in a row. Thi
I would bet Gmail is behaving correctly
From RFC5321:
Mailbox = Local-part "@" ( Domain / address-literal )
Local-part = Dot-string / Quoted-string
Dot-string = Atom *("." Atom)
Atom= 1*atext
From RFC5322 (as atext is not defined in RFC5321):
atext = ALP
libsrs_alt library (used by exim to generate SRS addresses for example;
copy on https://github.com/LynxChaus/libsrs-alt) has an option:
"
--with-base64compat
This option alters the behaviour of the base64 encoder built
in to libsrs_alt to use the non-standard characters '_' and
'.' instead of '+
