Not exactly the log pieces I was hoping for, but at least I understand the SIMS flaw involved now: SIMS does not see the 450 it gets from Verizon as a temporary failure, and bounces the message instead of requeueing it for later.
Bill, these are the only log lines connected with that SMTP session. Actually SIMS is treating the 450 as a temp but Verizon keeps sending the 450 forever.
I thought the issue was with Verizon's 'validation' process, which according to my source at Verizon (who refused a month ago to listen to reason) should be trying everything short of a DATA command in response to your mail, seeing if the address in your MAIL FROM (i.e. the Return-Path) is valid. This is what is necessary to validate anything more than the domain part of the Return-Path, and there are grave issues with the technique.
The first message I sent to a mailing list that we host and that the intended recipient is subscribed to. This was rejected by the gte server.
The second was sent from my main email address directly through this SIMS server and was rejected by gte server.
The third was sent from the same machine through the same SIMS server as the first but using the return address of an offsite email account I have through another ISP. This message was accepted by gte server. Why, I haven't a clue. Maybe someone can tell me why and the others are all rejected?
They really are not being rejected, just deferred. The fact that SIMS treats the 450 response code as a hard bounce is an old bug and one of the few definitive bugs in the last SIMS that demands fixing if it is going to remain useful. A growing number of anti-spam techniques include deferral of suspect mail rather than a hard bounce, and SIMS is simply behaving badly by treating any 4xx response code as cause to give up on a message.
What should explain the different behavior based on MAIL FROM argument is different mail servers dealing with Verizon's 'validation' run against the address. Any machine that is sensitive to address harvesting might end up treating the Verizon tester as a harvester. Any machine that shuns the null sender (BAD IDEA!!!) will cause it persistent problems.
The fact that the Verizon server accepted the message that was sent using a domain not hosted by us makes me think that Verizon is maybe doing some sort of checking with regards to the DNS for the domain name in the return address. Can someone take a look at our DNS and see if there is something obvious that could be causing Verizon to reject email from our domain 3-rivers.com and/or our primary server mail.3-rivers.com (63.95.200.5) but it will accept from the bentonrea.com domain.
I have changed the email addresses to helpfully protect them, but here is the log (logging set to ALL INFO in the SMTP settings) from the SMTP session with the GTE server:
[SNIP]
You need to do the same thing but looking for the 'callback' from the GTE machine shortly after you give it the MAIL FROM. If there is no callback session, that would explain the problem: they can't do the validation for some reason.
There is no call back from the Verizon server other than the responses I already included in the log I send.
On another thought, could the blacklists we utilize be causing any problem with the Verizon servers accepting email?
thanks, Paul Didzerekis
############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
