eMail Verifier ignoring 550

[muppetry]

The following transaction seems quite unambiguous to me, but eMail Verifier tries again (twice) with the same result, and then returns a green tick and the message "Looks valid" against the address. Am I missing something here?

Also, is there any way to stop it sending HELO [127.0.0.1]? It should be able to figure out its own domain, or have some way to be told.

[01] 12/12 17:38:53 MX <[email protected]> -> [mailin-01.mx.aol.com,mailin-02.mx.aol.com,mailin-03.mx.aol.com,mailin-04.mx.aol.com]
[01] 12/12 17:38:53 > CONNECT TO: [mailin-01.mx.aol.com]
[01] 12/12 17:38:56 220-rly-yi03.mx.aol.com ESMTP mail_relay_in-yi3.8; Tue, 12 Dec 2006 19:39:07 -0500
220-America Online (AOL) and its affiliated companies do not
220- authorize the use of its proprietary computers and computer
220- networks to accept, transmit, or distribute unsolicited bulk
220- e-mail sent from the internet. Effective immediately: AOL
220- may no longer accept connections from IP addresses which
220 have no reverse-DNS (PTR record) assigned.
[01] 12/12 17:38:56 > HELO [127.0.0.1]
[01] 12/12 17:38:56 250 rly-yi03.mx.aol.com OK
[01] 12/12 17:38:56 > MAIL FROM:<[email protected]>
[01] 12/12 17:38:57 250 OK
[01] 12/12 17:38:57 > RCPT TO:<[email protected]>
[01] 12/12 17:38:57 550 We would love to have gotten this email to [email protected]. But, your recipient never logged onto their free AIM Mail account. Please contact them and let them know that they're missing out on all the super features offered by AIM Mail. And by the way, they're also missing out on your email. Thanks.
[01] 12/12 17:38:57 221 SERVICE CLOSING CHANNEL

 

[stanbusk]

I think 'Looks Valid' is appropriate here. AOL sends a 550 error that could lead eMail Verifier to interpret the result as a failure (Bad email) however it finds out that AOL recognizes the address actually exists. So, eMail Verifier does a good job. ( A 550 error usually means 'Bad address')

HELO [127.0.0.1] is correct here. The HELO command should be followed by the machine IP address between '[' and ']' or the name of the machine without the domain part. Using HELO with a full domain name is reserved to the communications between MTAs. The SMTP RFCs are very clear about that. Trying to use a full domain after the HELO command here would trigger an anti-spam rule known as fake or forged HELO command.

 

[muppetry]

Thanks for the reply.

On the issue of the 550 code, I understand your argument, but I disagree that it is a useful response to label it as "Looks valid". 550 is a permanent negative completion; the AOL MTA is not willing to accept a message for that address. There is no point keeping that address on my list because it will always generate a bounce. And why does it keep retrying after a 5xx response?

Regarding the HELO command, I do not understand your argument. All the RFCs that I know of relating to this specify that the HELO command should be followed by [machine IP] or FQDN. 127.0.0.1, like localhost, is neither of those, and in fact the remote MTA may close the connection on receiving HELO [127.0.0.1], despite RFC-1123 5.2.5. eMail Verifier is clearly posing as an MTA in these interactions, so why would it be a faked HELO if it used my machine IP or my domain name, which (correctly) point to each other in the DNS, and from which it is communicating? Please reference the RFCs that support that conclusion.

 

[stanbusk]

550 can generated by a spam filter, a block and dozens of other reasons. I have personally investigated 550 responses during 2 years from around 120.000 bounces and SMTP responses. Considering 550 response as 'Bad address' would be a big error. This is the reason why there are around 100 specific rules parsing the 550 text in order to make sure the address is really bad.

About HELO, what domain do you want to place in the HELO command, is your machine directly connected to the internet as a domain, reverse DNS and PTR entry? Usually only an ISP or a web hosting company have such machines.

 

[muppetry]

OK, I give up on the 550 issue, except to repeat my final question; why does it keep retrying after a 5xx error?

Yes, I am on the internet with appropriate and consistent A and PTR (rDNS) records. I have DNS management control of my domain to set the PTR, MX and SPF records, and my ISP set up the A record to correspond with my domain. Why would you do it any other way? These days it's tough to get major ISP MTAs even to talk to you without that in place. An MTA (or psuedo-MTA) connecting from any of my machines is entitled to send HELO myFQDN. I don't see anywhere in eMail Verifier to specify the domain though.

 

[stanbusk]

It shouldn't retest after a 550 error, only the demo does sometimes actually.

About HELO, eMail Verifier is a desktop application that was designed for normal users, that is, users behind a DSL or a dial-up line. Those users have no domain, no reverse DNS nor PTR associated to their machine. If you want a way to specify a specific domain for the HELO command, no problem, open a support ticket and fill a feature request. I have no problem to add that. Actually it was like that before but due to the amount of servers not accepting such parameter for the HELO command we decided to work like a conventional mail reader. We get much better results, at least for our customers.

 

[muppetry]

I'm not running the demo. It's a registered copy of 3.0.2 running under 10.4.8 on a Mac Pro.

I'll follow your suggestion and open a ticket on the HELO issue.

Thanks.

 

[muppetry]

One other observation on your previous reply - I would expect eMail Verifier to be of somewhat limited value to a user of the kind you describe, since many ISP MTAs are set to refuse connections from IPs without valid rDNS entries, or, even more broadly, any IP that looks like it may be in a block of dynamic addresses, even if it is actually static. In that case all the program can do is validate the email domain name, not the address itself. Running email lists where you are forced to send everything through your ISP mail servers is very limiting, especially in bounce handling.

 

[muppetry]

And at the risk of becoming boring, one more thing, perhaps related to the retry issue.

If I put a valid email address into the "Single E-mail" field, and run the test, the program checks the DNS and opens a connection to the appropriate MX, followed by the usual transaction, ending in a "250 Recipient OK" and the "closing connection" or similar message. eMail Verifier puts a green tick and "Address is valid" tag next to the email address field, and "250 OK" in the "Details: Mail Server Response" box.

10 seconds or so later, it beeps, and the "Address is valid" tag changes to "Time out" and the "250 OK" disappears from the "Details: Mail Server Response" box. Nothing additional appears in the "Console" log.

Why does it do that?

 

[stanbusk]

No idea. What email address is that?

 

[muppetry]

No you misunderstand - it does that for ANY valid email address that I test in the Single Email field.

 

[muppetry]

To expand on this problem, when a valid email address is entered into the "Single email" field, eMail Verifier does the following (for no obviously good reason):

1. Contacts the appropriate MX, tests the address and reports it good (green tick plus "Address is valid").

2. Waits for the timeout period specified in the preferences.

3. Tests the address again and reports it good again.

4. Repeats 2 and 3 above until the number of retries specified in the preferences is reached.

5. After the final retest, waits for the specified timeout period and then beeps and changes the result to "Time out".

That's got to be a bug. Addresses loaded via a list file do not get unnecessarily retested in that way, and they do not lead to a final result of "Time out".

This also seems to be the reason I saw the retests after the 550 result - it was not related to the specific result.

 

[stanbusk]

It is strange, it doesn't happen to me. Here it simply tests the address, gives the result and stops. That's the reason why I asked you for that address. It doesn't happen to any of the addresses I have used so far nor to any other customer (at least I never heard about such issue so far). I am using very last version Universal 3.0.2 version right now. Is your version the Universal?

 

[muppetry]

Yes, universal 3.0.2, registered, not demo. Just to be sure I had the latest version I downloaded it again today. You want an address to try? How about [email protected]. See log below, retries set to 2, timeout to 15 seconds. And note the interval between the conclusion of the first transaction and the start of retry #2.

[01] 12/14 10:23:38 MX <[email protected]> -> [smtp.easydns.com]
[01] 12/14 10:23:38 > CONNECT TO: [smtp.easydns.com]
[01] 12/14 10:23:49 220 carnage.easydns.com ESMTP spoken here.
[01] 12/14 10:23:49 > HELO [127.0.0.1]
[01] 12/14 10:23:49 250 carnage.easydns.com
[01] 12/14 10:23:49 > MAIL FROM:<[email protected]>
[01] 12/14 10:23:49 250 Ok
[01] 12/14 10:23:49 > RCPT TO:<[email protected]>
[01] 12/14 10:23:49 250 Ok
[01] 12/14 10:23:49 221 Bye
[01] 12/14 10:24:04 > CONNECT TO: [smtp.easydns.com] (Retry #2)
[01] 12/14 10:24:22 220 maryjane.easydns.com ESMTP spoken here.
[01] 12/14 10:24:22 > HELO [127.0.0.1]
[01] 12/14 10:24:22 250 maryjane.easydns.com
[01] 12/14 10:24:22 > MAIL FROM:<[email protected]>
[01] 12/14 10:24:22 250 Ok
[01] 12/14 10:24:22 > RCPT TO:<[email protected]>
[01] 12/14 10:24:22 250 Ok
[01] 12/14 10:24:22 221 Bye


Or [email protected]:

[01] 12/14 10:28:56 MX <[email protected]> -> [eg-mail-in2.apple.com,mail-in1.apple.com,mail-in2.apple.com,mail-in3.apple.com,mail-in6.apple.com,smtpin69.apple.com,smtpin70.apple.com,smtpin71.apple.com,smtpin72.apple.com,tahuti.apple.com]
[01] 12/14 10:28:56 > CONNECT TO: [eg-mail-in2.apple.com]
[01] 12/14 10:28:56 220 eg-mail-in2.apple.com ESMTP Apple Secure Mail Relay
[01] 12/14 10:28:56 > HELO [127.0.0.1]
[01] 12/14 10:28:56 250 eg-mail-in2.apple.com
[01] 12/14 10:28:56 > MAIL FROM:<[email protected]>
[01] 12/14 10:28:56 250 Ok
[01] 12/14 10:28:56 > RCPT TO:<[email protected]>
[01] 12/14 10:28:56 250 Ok
[01] 12/14 10:28:56 221 Bye
[01] 12/14 10:29:11 > CONNECT TO: [eg-mail-in2.apple.com] (Retry #2)
[01] 12/14 10:29:12 220 eg-mail-in2.apple.com ESMTP Apple Secure Mail Relay
[01] 12/14 10:29:13 > HELO [127.0.0.1]
[01] 12/14 10:29:14 250 eg-mail-in2.apple.com
[01] 12/14 10:29:15 > MAIL FROM:<[email protected]>
[01] 12/14 10:29:15 250 Ok
[01] 12/14 10:29:16 > RCPT TO:<[email protected]>
[01] 12/14 10:29:17 250 Ok
[01] 12/14 10:29:17 221 Bye


Both these sequences end with the result being a green tick and a red "Time out".

 

[stanbusk]

I can't reproduce here. I just get:

[01] 12/14 19:10:07 MX <[email protected]> -> [smtp.easydns.com]
[01] 12/14 19:10:07 > CONNECT TO: [smtp.easydns.com]
[01] 12/14 19:10:25 220 storm.easydns.com ESMTP spoken here.
[01] 12/14 19:10:25 > HELO [127.0.0.1]
[01] 12/14 19:10:25 250 storm.easydns.com
[01] 12/14 19:10:25 > MAIL FROM:<[email protected]>
[01] 12/14 19:10:25 250 Ok
[01] 12/14 19:10:25 > RCPT TO:<[email protected]>
[01] 12/14 19:10:25 250 Ok
[01] 12/14 19:10:26 221 Bye

After waiting 15 minutes, nothing else. I have inspected the source code of eMail Verifier. I can't see anything wrong. Do you get that as soon you launch the app and insert an address and press 'Run Test'? Have you tried to Run eMail Verifier from a different account on your system?

 

[muppetry]

Yes - I tried it from another account and it behaved exactly the same. Are you running on Intel or G4/5? I'll try it on another Intel machine, a G4 and a G5 for completeness.

 

[stanbusk]

I have tried on a MacPro 3Ghz, an iMac Intel 2 Ghz and a G5 2 Ghz. Same results here. It is important I can reproduce first.

 

[muppetry]

OK - you are testing on basically the same machine - the Mac Pro. I'm running 10.4.8. I'll get back to you when I've figured out if this problem is specific to this machine.

 

[muppetry]

I've now tested this on a G4 Powerbook and a G5 PowerMac as well as the Mac Pro, all running 10.4.8. Its behavior is the same on all three. Are you running 10.4.8?

I've tried using different nameservers, restoring factory settings, changing retry and timeout settings, and throwing away the preference file. Same result in all cases. I don't know why you are not seeing it, but this is a bug.

 

[stanbusk]

We use 10.4.8 and Windows XP SP2 here. I can't reproduce the problem. The code is correct, the timeout timer is destroyed right after the test is done. On your case it looks like that timer is never destroyed and continues to run. The code is clear, we stop, close and destroyed that timer. Do you have something installed on your computers that could change threads or timers behaviors? Also note that I have never received other reports with such problem so far. If it were a bug it wouldn't be in the application but elsewhere.

Anyway, I can add more security to the code to avoid the problem to appear. Please open a support ticket so I can give you a link to a new compile.