>-----Message d'origine-----
>De : [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] la part de Davide Libenzi
>Envoy=E9 : mercredi 22 octobre 2008 02:57
>=C0 : XMail mailing list
>Objet : [xmail] Re: email address validation (RFC2822...)
>
>
>On Tue, 21 Oct 2008, [EMAIL PROTECTED] wrote:
>
>> Hello Francis
>>=20
>> It's about out going mail, or relaying mail.
>> Not for local receiving.
>>=20
>> Major cell-phone company in japan (@docomo.ne.jp) has many illegal=20
>> address.
>> like this,
>>   [EMAIL PROTECTED]
>>=20
>> And we could not send to   "aaa....bbb...."@docomo.ne.jp
>> via xmail.
>>=20
>> We modify the source below when new version of xmail released.=20
>>=20
>>=20
>> SMailUtils.cpp
>>=20
>> static char const *USmlDotAtom(char const *pszStr, char=20
>const *pszTop)
>> {
>>=20
>>         for (;;) {
>>                 char const *pszAtom =3D pszStr;
>>=20
>>                 for (; pszStr < pszTop && RFC822_ATEXT(*pszStr);=20
>> pszStr++);
>>                 //if (pszAtom =3D=3D pszStr)
>>                 //      return NULL;
>>                 if (pszStr =3D=3D pszTop || *pszStr !=3D '.')
>>                         break;
>>                 pszStr++;
>>         }
>>=20
>>         return pszStr;
>> }
>
>I'm sorry but after a careful examination, I decided to not implement=20
>quote strings in the local-part of the address. That would require a=20
>clusterfsck of changes via escpaing/unescaping, due to the fact that=20
>characters like '"' and '\t' can screw up the TAB files=20
>format, and other=20
>file system special characters could now appear in the name.
>The changes above is a "sunny day" change, that waits for hell=20
>to break=20
>lose.
>
>
>
>- Davide
>

Ok with you on localy handled domains at this time (i'm not really
concerned), but what about just don't check the 'local-part' when it =
appears
in MAIL FROM or RCPT TO when the domain is not handled localy by the =
xmail
server, to be full rfc 2821 compliant ?
I think it does not breaks anythink localy in tab files or system files
names for foreign domains, no ?
The conterpart would be that xmail could no find any match in tab files =
like
spam-address as it will not be possible to put them in such files (and =
xmail
and filters will have to only take care to remove surrounding quotes =
adding
by xmail itself when reading spool files).
And this could be a start for xmail to begin support the next future
internationalized email system (handle multiple charsets in emails =
addresses
to support no ascii/us chars)

Could be in next version 2 or 3 of xmail ?

Francis
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]

Reply via email to