search

trancos30 / subethasmtp

Automatically exported from code.google.com/p/subethasmtp
Other
1 stars 0 forks source link

Email Address Validation not happening? #52

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
The Message Handler Interface claims that the provided Addresses are "already 
validated by the server".
In my tests this does not seem to be the case.

Either the Validation is not working properly or the JavaDoc String claims 
something untrue.

I dont really have time right now to investigate further, but I dont think this 
is hard to fix.

Thanks for this great library, the API is indeed very comfortable!

* 
http://code.google.com/p/subethasmtp/source/search?q=validat&origq=validat&btnG=
Search+Trunk

Original issue reported on code.google.com by army.of....@gmail.com on 14 Sep 2012 at 3:08

GoogleCodeExporter commented 9 years ago 
The address validation is done in EmailUtils.isValidEmailAddress, which in turn 
delegates the validation to javax.mail.internet.InternetAddress.parse, with the 
"strict" option. According to its javadoc:
"If strict is true, many (but not all) of the RFC822 syntax rules are enforced."

I wrote a mail address parser* in Mireka, which exactly follow the RFC. 
Actually that is the only fully RFC 5321 compliant parser in Java I know about. 
It handles many special cases which I have never met in real life. For example 
mail addresses which contain spaces. Yes, mail addresses with spaces are valid, 
there is syntax for them which uses quotes. This, by the way, breaks the SMTP 
command parsing in Mireka. Of course the parser in Mireka can be added to 
SubEthaSMTP, and extended to parse SMTP commands too. But I also consider that 
we are talking about such exotic cases, that may never actually occur in real 
life. At this moment I think that adding a significant code base to SubEthaSMTP 
to correct hypothetic problems would do more harm than benefit. I also do not 
see a clear way to do this, without duplicating code in Mireka and SubEthaSMTP, 
and without adding a new dependency to SubEthaSMTP. 

Maybe you have a different experience, so if you (or somebody else) could write 
some specific real life examples which is not handled by the current 
SubEthaSMTP parsing, then we may reconsider adding a fully compliant parser.

Moreover, if we implement more SMTP extensions in the future, then a real 
command parser will be needed in SubEthaSMTP, which implicitly adds perfect 
address parsing too.

Original comment by hontvari@flyordie.com on 28 Nov 2012 at 1:49

GoogleCodeExporter commented 9 years ago 
Thank you for the detailed reply. I'm sorry I did not reply earlier.

I understand the hurdle with email address parsing, I went down that rabbit 
hole for a few hours.
I also dont think including another project is necessarily wise.

But maybe one or both of the following suggestions could be implemented:

1. Warn about the lax email validation in the JavaDoc, replacing the claim that 
the addresses are validated.
    (Not claiming to pass on valid emails shifts the responsibility and restores comment/code relation)

2. Define an Interface  for email address validation (~1 method). Provide a way 
to optionally pass an instance of an Implementation/a factory in the 
appropriate classes.

Happy Holidays and best wishes for the coming year!

You guys enabled me to build something which otherwise would have taken a 
prohibitive amount of work.
Thank you!

Original comment by army.of....@gmail.com on 25 Dec 2012 at 2:14

GoogleCodeExporter commented 9 years ago 
I would like the validation interface, but only if it could return the parsed 
mail address in some form (Abstract Syntax Tree?). Otherwise I do not see its 
benefit, as the application can validate the mail address in its 
MessageHandler.from implementation easier. So the comment change seems to be 
the better option.

Original comment by hontvari@flyordie.com on 7 Jan 2013 at 6:05

GoogleCodeExporter commented 9 years ago 
I have updated the Javadoc to clearly state that many, but not all syntax rules 
are enforced.

Original comment by hontvari@flyordie.com on 12 Mar 2013 at 12:38