John & Sandy,
I wasn't suggesting in any way that Katie was having the same exact
issue; only that a component of the same Verizon system was causing
issues elsewhere and that the component was poorly designed.
I can't be 100% sure that the issue was that they were attempting to
connect directly to his sending server's IP despite the fact that it is
in no MX records, but one way or another, this technique causes issues.
Here's an example scenario. Verizon receives 10,000 messages with
forged addresses on mailpure.com, i.e. [EMAIL PROTECTED],
[EMAIL PROTECTED], etc. For every one of these messages they get,
they go to my gateway (if that is what they do), and they attempt to
validate the address which my server will reject. After they do this on
5 different connection in 5 minutes, their IP gets automatically blocked
by my gateway for clear abuse, and then I might end up blocking all of
the E-mail that might come from this particular IP.
Now for the other way that they might do it. If they are trying to
avoid such systems because this technology makes them look like a
dictionary attacker themselves, they might try connecting back to the
same IP that was connecting to them. Now of course some IP's are
configured to send E-mail only, and will not listen or accept
non-authenticated E-mail, in which case they fail to confirm the address
and they end up blocking these messages.
One way or another, this is a bad practice.
Matt
John T (Lists) wrote:
Sorry Matt, please go back and reread the information.
Verizon was receiving email with forged from addresses, those being of
a domain on Katie's server. Verizon's servers were then attempting to
verify those forged addresses, which Katie's server was properly
saying user does not exist. Katie thought all those checks were some
type of DOS attack, so she blocked them. After doing so, legit email
from her server to a Verizon server would fail since the Verizon
server would then attempt to validate the from address but could not
since the Verizon server was blocked from talking to Katie's server.
Additionally, in Marc's case, (if what you have said is true,) it is
IMHO a best practice that if you are going to configure your email
server to not accept email from the Internet, only from your gateway
servers or directly from authenticated users, such as how mine are set
up, then that email server should be sending all outgoing through one
of those gateway servers.
Doing that would eliminate all direct communication between the email
server and the general Internet and keeps things clean and neat.
**John T**
**eServices For You**
** **
*"Life is a succession of lessons which must be lived to be understood."*
*Ralph Waldo Emerson (1802-1882)*
* *
-----Original Message-----
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Matt
*Sent:* Tuesday, January 09, 2007 9:50 PM
*To:* [email protected]
*Subject:* Re: [IMail Forum] Verizon 450 action not taken
Katie, et. al,
What Verizon is doing here is a bad practice. Marc's server had
issues because his server is set up to only accept authenticated
connections on the SMTP port, so when Verizon calls back, they were
ignoring his MX records and going straight to his server which rejects
the connection due to the fact that it is purposefully set to block
non-local access.
I can't imagine that Verizon will continue this practice for very
long. It was just last year when they settled a lawsuit for their
spam blocking practices that blacklisted huge swaths of European IP
space from connecting to their servers. Seems that they haven't yet
learned.
Matt
Katie LaSalle-Lowery wrote:
I am happy to report resolution!!!
Just as a shot in the dark I asked Linda at Declude (with whom I was
communicating about a backlog in the Declude proc folder we had
yesterday) if she had seen the issue before. She said that she had
seen similar and shared some contact info for an email specialist and
an email supervisor at Verizon. I called and left voicemail for both
and received a return call from a Brian this afternoon.
Brian explained the sender verification call back that the Verizon
servers do to eliminate receiving email from spoofed addresses that
don't exist. If, for example, their servers receive a mail from
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> they will do an MX lookup
then connect to the sending server and see if it will accept mail from
the sending address. So, if mail.centric.net says that
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> is not a valid
recipient the Verizon server concludes that the mail is spoofed and
rejects it.
Brian then told me the IP addresses of the servers that perform the
sender verification call back. I recognized them immediately. About
3-4 weeks ago we suffered a massive dictionary attack from those
addresses that almost overwhelmed us and added them to the Control
Access List. Brian said that if they got hit with a huge amount of
spam with spoofed addresses on the centric.net domain and were failing
a bunch of sender verification callbacks it would look exactly like a
dictionary attack from this side.
So, I removed the IP's from the Control Access List and Brian said to
keep his contact info.
Problem solved and I "made contact" with the impossible folks to make
contact with.
Thanks,
Katie
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
[mailto:[EMAIL PROTECTED] *On Behalf Of *Marc Catuogno
*Sent:* Tuesday, January 09, 2007 12:36 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* RE: [IMail Forum] Verizon 450 action not taken
I had the same exact problem with them. The problem eventually
resolved itself, but you need to have some type of Verizon account to
get anywhere with them. Do you or any of your customers have a
Verizon account?
Marc
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
[mailto:[EMAIL PROTECTED] *On Behalf Of *Katie
LaSalle-Lowery
*Sent:* Tuesday, January 09, 2007 2:29 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* [IMail Forum] Verizon 450 action not taken
Hello,
When I Google my problem I see thousands of reports of the same but
nothing specific to our setup (Imail 8.05, Declude, Simple DNS Plus).
Any insight would be appreciated.
My problem is this (which is a copy & paste of part of an email I sent
to [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>):
For about two weeks the verizon.net mail servers have been refusing
relays from our mail server.
Here is an example log snippet:
01:03 20:47 SMTP-(3EFC3D80) Trying verizon.net (0)
01:03 20:47 SMTP-(3EFC3D80) Connect verizon.net [206.46.232.11:25] (1)
01:03 20:47 SMTP-(3EFC3D80) 220 sv18pub.verizon.net MailPass SMTP
server v1.2.0 - 112105154401JY+PrW ready Wed, 3 Jan 2007 21:47:56 -0600
01:03 20:47 SMTP-(3EFC3D80) >EHLO mail.mtwi.net
01:03 20:47 SMTP-(3EFC3D80) 250-sv18pub.verizon.net
01:03 20:47 SMTP-(3EFC3D80) 250-8BITMIME
01:03 20:47 SMTP-(3EFC3D80) 250 SIZE 20971520
01:03 20:47 SMTP-(3EFC3D80) >MAIL FROM:<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
01:03 20:47 SMTP-(3EFC3D80) 450 Requested mail action not taken-Try
later:sv18pub.verizon.net
01:03 20:47 SMTP-(3EFC3D80) SMTP_DELIV_FAILED
01:03 20:47 SMTP-(3EFC3D80) >QUIT
I have attempted to create a trouble report through online chat. The
support staff there referred me to your whitelist form -- a step I had
already taken. I have submitted the whitelist form entering both of
the IP addresses assigned to our mail server (69.51.66.5 & 69.51.66.6)
and multiple domain names hosted on that server (eg centric.net and
mtwi.net). I have made four or more submissions and received, in
every case, a response saying that our IP is not blocked. I advised
the online chat support staff of that and they then said they were not
able to help me further. I requested that the the problem report be
escalated to staff that could assist and was informed that the online
support staff have no means by which to do so. All of your phone
support contacts do not allow a caller to proceed without an account
number.
Thank you,
Katie LaSalle-Lowery
Centric Internet Services
1410 Reserve St.
Missoula, MT 59801
Local Phone 549-3337 ext. 21
Toll Free (888)593-2776 ext. 21
Fax (406)721-3438
