PHP / Ruby on Rails SMTP Email Validation or check mail delivered or not_问答_开发者

PS: I am not a spammer and neither my application is.

I have a list of some thousands of email addresses, which I want to test weather its a valid email address or not using SMTP.

I got some code http://code.google.com/p/php-smtp-email-validation/ but i am doubtful this will block/blaklist my IP/Server.

I already checked a long list of related ques开发者_JS百科tions on stackoverflow. But none is providing proper solution for this. As there are lot of companies which provide these kind of services. How they are managing the stuff?

I am open of other platforms like python etc.

EDIT

I can understand there is not exact way to detect mail is delievered or not. But with some 50-90% probability is there any way to check mail has been delivered in ruby on rails.

As part of an SMTP transaction, the sending SMTP server will issue a RCPT command to indicate to which email address a message should be delivered.

An SMTP server may respond with a 550 code at that point if the specified recipient is known not to be a deliverable address. This will only work for receiving SMTP servers that deal with a finite known list of possible recipients.

If a 'catch all' address has been set up for a given domain, such that *@example.com will be accepted regardless of there being an email account for a given address, you can never verify that a given address is actually valid.

Therefore there is no way of consistently verifying the validity of email addresses using SMTP. You may be able to verify that some email addresses are invalid; you can never assume a lack of invalidity implies validity.

It is not possible. There is absolutely now way in this universe to be able to know that a message has been delivered or not.

Some protocols such as X400 try hard to give delivery notices, unfortunately there are always cases when they fails.

For this reason, internet protocols such as SMTP don't even try. They do their best to make it work, but offer no guarantee, and foremost, they don't guarantee any feedback.

When sending a message, there are a lot of entities involved. You, your UA, your MTA, possibly some intermediary MTA, the recipient MTA, the recipient UA, the recipient. Well, no not exactly anymore. There are chances that your recipient has several mail boxes, and that he uses a web service to collect emails from his several boxes to gather them into a single UA, so it may be like: You, your UA, your MTA, possibly some intermediary MTA, the recipient MTA, the collector UA, the collector MTA, the actual recipient MTA, the actual recipient UA, the recipient. Between each of these entitites, there may be some level of positive or negative acknowledgement. But that's all. Entity N will know that the message has been received by entity N+1 in the chain, but then communication is closed, and it won't know what happens, and when, between entities N+1 and N+2. If there is a problem with some luck a MTA may send back an error message to the sender, but this is not necessarily done much anymore because of SPAM and viruses.

Well, eventually, your message may arrive at the final recipient's UA. There, something may be done to be informed that it has been received, or possibly even displayed, with means of some unstandardized header in the message. Some UA can be configured easily to insert these headers, and to honor them or not. Privacy and SPAM/viruses savy users won't activate this feature (it allows addresses collectors to validate easily an email address for resale to spammers), so the probability that you would get an actual answer will be very low (unless you are sending emails to dumbasses).

But even with this feature activated and working well, the fact that you receive a message sent by the UA of the recipient telling you that your email has been displayed doesn't prove anything. Notably, it doesn't prove that your message has been viewed by the recipient, much less that he has read it, and even less that he has understood it!

In conclusion, you can technically determine that your message has been sent to the first entity in the chain. That's all. From there on, play it will be received, read and understood.

If you want to be sure that the mail is delivered or not, you have to use a higher level protocol. For example, if you ask a question in your email expecting an answer A1 or an answer A2, you have four possibilities:

you get an answer A1. You can assume the mail is delivered, and read. But was it understood? Was really A1 the answer the recipient meant to send?
you get an answer A2. You can assume the mail is delivered, and read. But was it understood? Was really A2 the answer the recipient meant to send?
you get an answer A3. You can assume the mail is delivered, and read, and not understood.
you don't get an answer in some delay. You cannot assume anything. Try to send another email eliciting an answer. If you still don't get any confirmation of an actual communication try to phone the recipient. Or to meet in person. Or to hit him in the face. If you still don't get any answer, you can consider your recipient in a coma or dead, and assume the message doesn't pass thru. (some persons believe it's worthwhile to communicate with somebody in a coma, but I believe that it's only good to stimulate their brain, you can't expect answers, they won't start to answer to your backlog discussions when they awake).