Hi Karolyi about py3-validate-email HOT 11 CLOSED

The code you get is 511, put together from the 5.1.1 in the text after the RCPT TO failed: . That is the exact message the module gets from the SMTP server. Basically, everything above 500 is an unrecoverable error message.

from py3-validate-email.

I don't think that 5.1.1 means Code 511. After getting code, message from an SMTP command, you might want to also include code in the error message, not just message.

from py3-validate-email.

Interesting. SMTP servers will normally use the same error code they emit in the message, only without the dotted notion. Except when they don't.

@reinhard-mueller, wanna make a PR?

from py3-validate-email.

I'll give it a try tomorrow.

from py3-validate-email.

BTW, this might be interesting regarding the xxx vs. x.x.x error codes.

from py3-validate-email.

While I am thinking about this issue, I get more and more insecure about what actually is the best way of handling error responses during EHLO or MAIL FROM. The purpose of the function is to check the existence of an email address. However, if we get a 5xx reply already on EHLO or MAIL FROM, this does not mean that the email address we want to check doesn't exist. It just means that the mail server refuses to talk to us.

My current impression is that the function should not return False in such a case, but rather None - we simply can't verify whether or not the address exists, just like if there was a connection error to the SMTP server.

What do you think?

from py3-validate-email.

Don't overengineer it. The protocol itself is messy, and we can't take responsibility for people being unable to read and/or understand what's already disclosed in the FAQ.

It makes sense to document these cases, but the code is assuming of a proper mail server setup, everything outside is not the scope of it.

from py3-validate-email.

Please have a look at #48. It should make sure that SMTP error status codes are always reported in the same format.

However, I am really not sure whether we shouldn't consider changing behaviour for errors on connect, EHLO or MAIL FROM. Getting blacklisted, for example, can really happen to anybody these days, and I think we should not just return false negatives for all checks in such a case. Maybe it sounds more complicated than it really is, if you want I can prepare another PR.

from py3-validate-email.

@reinhard-mueller as mentioned before, I don't think that functionality belongs to this module. This module assumes you have a working, non-blacklisted mailserver that can deliver emails. When in doubt, there is always the possibility to run the code in debug mode and figure out what went wrong from the conversation. Moreover, that information will be already provided in a shorter form, from the exceptions in the PR.

I also requested to fix a breaking change, and travis also bails out with the tests.

from py3-validate-email.

so is the change will be implemented in new version?

from py3-validate-email.

waiting for update

from py3-validate-email.