recent Verizon issues

[clbrack1]

It seems that Verizon is doing some kind of funky 'callout' or 'sender verify' spam control that is causing the following error:

Temporary error returned by SMTP partner.
smtp;450 Requested mail action not taken-Try later:sv11pub.verizon.net

Searching the net (or the forums) hasn't produced any real results...some web hosts are just blocking verizon traffic but I don't see that as an option as I don't want to lose customers.

Does anyone have a solution? I figure that a couple of lines in my Exim ACL will resolve this.

thanks,

Chris

[clbrack1]

personally I would like to see Verizon dragged into court and made to pay dearly

I do have a working lawsuit against the morons for a cell phone issue and I may bring suit because of this issue.

However, that doesn't help me get my mail on verizon servers....verizon cannot tell me what is wrong (at least AOL gives you exact instructions in their rejection) and I cannot find out how to fix on this forum.

I would pay to have it fixed if anyone has any ideas

Chris

[clbrack1]

$50 if you can provide the fix for:

SMTP<< 450 Requested mail action not taken-Try later:sv11pub.verizon.net
SMTP>> QUIT
LOG: MAIN
== n.belair@verizon.net R=lookuphost T=remote_smtp defer (-45): SMTP error from remote mail server after MAIL FROM: SIZE=6543: host relay.verizon.net [206.46.232.11]: 450 Requested mail action not taken-Try later:sv11pub.verizon.net

will send via paypal...we run 30 servers, I'm not gonna stiff anyone over $50 for a good solution!

Chris

[sparek-3]

The issue is with Verizon. You would ultimately just have to contact Verizon and they should be able to explain why you are seeing this error. I suspect that you have e-mail forwarders that are forwarding spam to various @verizon.net addresses, which has resulted in a block on your mail server due to spam complaints. This is just what I would take to be the first suspect. However, only Verizon would know the answer for sure.

[sierrablue]

It seems that Verizon is doing some kind of funky 'callout' or 'sender verify' spam control that is causing the following error:

Temporary error returned by SMTP partner.
smtp;450 Requested mail action not taken-Try later:sv11pub.verizon.net

Searching the net (or the forums) hasn't produced any real results...some web hosts are just blocking verizon traffic but I don't see that as an option as I don't want to lose customers.

Does anyone have a solution? I figure that a couple of lines in my Exim ACL will resolve this.

thanks,

Chris

They do sender_verify callbacks with 15 seconds timeout IIRC.

If your server takes longer than that to respond you'll get 450. (this happens if you check too many RBLs, etc)

[sierrablue]

Correction; it is 30 seconds

1.) Please ensure that your server is accepting mail from
206.46.252.0/24.

2.) Please ensure that your server accepts a Null Mail From: command
e.g. Mail From:<>.

3.) Please ensure your mail server responds to the SMTP commands within
30 seconds.

4.) Please ensure the from address used is a valid email address that is
accepted by the MX server for that domain.

[jugo]

Well.. here's my babble...

Don't ask me why this works but it does;

I added SPF records for each of the domains on my box.

I also added this line to the DNS Zone Templates:

%domain%. IN TXT "v=spf1 ip4:%ip% a mx a:mail.%domain% a:%domain%"

my PayPal is "jugo (DOT) gf (AT) gmail (DOT) com"

[clbrack1]

Sorry Guys (gals?)

Just getting back to this after taking off for the weekend.

Give me a bit to test and first correct answer gets the $50

thanks,

Chris

[clbrack1]

OK,

adding the spf record did not work.

I can see that the verizon mail server quits trying at about 30 seconds....and I do check several RBL's.

If I have to trim down my RBL list which one would you recommend?

Chris

[manokiss]

We have the same problem in all our servers, someone did find a solution for this?

We wrote verizon and they keep replying the following, but we also tested in a server without an rbl system and the error is the same, so im not sure if this is something we could fix or not:



----
Thank you for contacting Verizon Online Abuse. After investigation,
Verizon Online Abuse has determined that the request you submitted is
not being blocked.

Also please note: If the error message you or the person trying to
contact you receives is not a 550 error that has a link to http://www.verizon.net/whitelist
then you have another issue. Please address the following tips before
resubmitting a request for investigation.

A few tips:

1.) Please ensure that your server is accepting mail from
206.46.252.0/24.

2.) Please ensure that your server accepts a Null Mail From: command
e.g. Mail From:<>.

3.) Please ensure your mail server responds to the SMTP commands within
30 seconds.

4.) Please ensure the from address used is a valid email address that is
accepted by the MX server for that domain.

5.) Please ensure you have a proper MX record.

If you are still having issues please double check the IP address you
submitted and if an error is found you can resubmit the request via the
web form at http://www.verizon.net/whitelist or
whitelist@verizononline.net email address for further investigation.


We were able to determine that the issue is that your MX server is
taking longer than 30 seconds to respond to our sender verification
callback. Verizon does a call back to the MX server of the sending
domain to ensure it will accept email for the sending email address. In
this instance your server is taking longer than 30 seconds to respond to
the Rcpt To: command of the SMTP session. Typically this is due to
anti-spam software being under heavy load or a blacklist that is being
queried is timing out. Once you have resolved this latency the issue
sending to Verizon customers will be resolved.

Sincerely,

Verizon Online Abuse
http://www2.verizon.net/policies
http://www.verizon.net/security
Abuse@verizon.net
-----

[manokiss]

jfy: relays.ordb.org is not resolving anymore, so if you are using this one, remove it from your rbl list.

[clbrack1]

thanks to sierrablue for identifying the 30 second timeout issue.

per sierrablue's suggestion we looked at our RBL list and disabled every RBL check as well as added verizon.net to the rblbypass file in /etc and restarted Exim

Still receiving the same error message from verizon, though.

However, when I attempt a manual delivery from the queue I can count off 30 seconds and sure enough, the message delivery comes back with the 450 error.

So my question is, what elese (besides rbl checks) could be causing my server to take more than 30 seconds to respond? (FYI...I have added the verizon ip's (entire class c) to the firewall allow list)

Anyone?

Thanks,

Chris

[manokiss]

just fyi guys, just removig relays.ordb.org from our list did the trick for us, restart exim.

[sierrablue]

So my question is, what elese (besides rbl checks) could be causing my server to take more than 30 seconds to respond?

Could be many things, like reverse host lookups, antivirus, etc. Check your exim.conf for all the checkups, make a list, then turn them off one by one til you hit the bugger which wastes the most time.

just fyi guys, just removig relays.ordb.org from our list did the trick for us, restart exim.

Yeppers, relays.ordb.org caused lots of trouble for lots of people.

[clbrack1]

thanks again sierrablue as I commented items out of my exim config until I hit on the one that was taking up the time. FYI it was the demime list of 'banned' file attachment extentions. I had about 15-20 extentions banned and it was the straw that took me over 30.

Also thanks to manokiss for the Verizon list. I only wish that they had provided me with such a list in my 2 dozen contacts with them about this issue. Say what you will about AOL but every email rejected by them contains a URL where you can find out why it was rejected and how to fix it. If Verizon would follow suit there would be fewer issues such as these.

FYI...I sued Verizon in small claims court about a cell phone issue and their attorney called this morning asking what he could do to make this issue go away

Back to the current issue:

My server is not returning the requested: Mail From:<>
when qeuried by Verizon's server.

Instead my server(s) return someting like: Mail From: <> Size 3248

I am currently searching the forum but have not yet run accross a solution.

Anyone have an idea about this?

thanks,

Chris