At 10:15 AM -0500 12/01/2003, Bill Cole modified the matrix with:At 6:16 AM -0800 12/1/03, Paul Didzerekis imposed structure on a stream of electrons, yielding:It seems that Verizon has setup a new system where they require that all incoming messages to their servers be authenticated by the sending SMTP server with User Authentication. This means that the Verizon servers send back a response when SIMS tries to send a message and that response requires that SIMS verify that the sender of the message is an authorized user on the SIMS server. Since SIMS does not support this all of our email sent to anyone on Verizon's email servers gets rejected.
I called Verizon when we noticed that all messages to them were getting rejected and had to keep asking for supervisors until I finally got to one that knew what the problem was. They said that it was a new policy that their engineers had implemented and that they were having a lot of complaints from other ISPs but that they were not going to change their policy. I had them escalate my complaint to the engineering department asking to be called back.
Has anyone else noticed this yet and what are we to do, can we hack SIMS using ResEdit so it sends the correct response? Can we please get Stalker to modify SIMS so it response correctly?
I am aware of this deeply stupid policy decision by the imbeciles at Verizon, but I am not clear on how SIMS is causing trouble in conjunction with it. Do you have a detailed log snippet showing what Verizon is doing to 'authenticate' the sender and how SIMS is responding badly?
You asked for it, here is a log snippet showing four messages all sent to the same person at a gte.net (same as verizon.net) email address. The three messages were generated differently.
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.
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 last 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.
This would be consistent: addresses you host get the 450 response (implying that the Verizon machine had some sort of response it didn't like but didn't feel comfortable with calling a hrd failure) while addresses hosted elsewhere worked.
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.
--
Bill Cole [EMAIL PROTECTED]
############################################################# 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]>
