At 14:31 2006-03-22 -0800, Bart Schaefer wrote:
There is exactly one questionable anti-spam tactic that I *know*
Verizon employs.
When you connect to a Verizon MX on port 25 and issue MAIL
FROM:<foo(_at_)bar(_dot_)com>, Verizon doesn't answer until it first connects
back to the MX for bar.com, issues RCPT TO:<foo(_at_)bar(_dot_)com>, and gets
250
back. If either it can't connect to the bar.com MX or the response is
5xx, Verizon's response to the MAIL FROM: is 451.
I don't know if there's any possibility that this is affecting your
Norwegian site.
Nope, but we were aware of that in NOV/DEC 2004 or so when they started
doing it. It was aggravating, and we (and no doubt many others) saw a
number of problems with their approach (not the least of which is the
presumption that a host SENDING mail is the same as the host RECEIVING mail
- one's inbound server might not be up and running when an outbound relay
is - obviously it SHOULD be, but there's no guarantee that it is - yea,
deferring the mail isn't rejecting it, so when the inbound SMTP is up
again, the messages would be sendable), but that didn't apply to us - we
saw the influx of callbacks to us, and they were all being replied to
appropriately. I even set up sendmail in it's
verbose-log-every-bit-of-data diagnostic mode to watch the
connections. Which is a painful thing to do when you have a lot of email
traffic.
An irony is that their approach does NOTHING to address forgeries - they
merely verify that the supposed sender address is legit. Since far too
many people have hosted websites with wildcard email configs (ANY address
at their domain will deliver to their one mailbox), this approach is almost
as retarded as the IT people at Verizon. One might be tempted to think it
is as or more retarded, but that is simply not possible - I'm quite certain
that Verizon has an inbreeding project going on and has selected the
inferior genes for propagation.
Besides - if the callback were really the cause of the problem, then
SMARTRELAYING it through a US host wouldn't change a thing - the envelope
sender is still the norway-hosted site. They continue to receive sender
verification callbacks from Verizon, but because the messages are relaying
through a US host, Verizon is accepting them. If they send via the EU
host, Verizon defers them indefinitely.
hostname and email address changed to protect the innocent:
Mar 23 00:22:46 mailhost sm-mta[56636]: NOQUEUE: connect from
sv24pub.verizon.net [206.46.252.160]
Mar 23 00:22:46 mailhost sm-mta[56636]: AUTH: available mech=DIGEST-MD5
CRAM-MD5, allowed mech=PLAIN LOGIN DIGEST-MD5 CRAM-MD5
Mar 23 00:22:46 mailhost sm-mta[56636]: k2MNMkJV056636: Milter: no active
filter
Mar 23 00:22:47 mailhost sm-mta[56636]: k2MNMkJV056636:
to=<some-address(_at_)ourdomain(_dot_)tld>, delay=00:00:00, pri=0, stat=aborted
by sender
Mar 23 00:22:47 mailhost sm-mta[56636]: k2MNMkJV056636: from=<>, size=0,
class=0, nrcpts=1, proto=SMTP, daemon=MTA, relay=sv24pub.verizon.net
[206.46.252.160]
Note the "aborted by sender" - this is because the cheezewads at verizon
just _DROP_ the SMTP connection after getting the information they
need. They do not close it appropriately with a QUIT.
The above transaction results when a message is relayed from the US
server. They ARE accepting the message from the US host, just not from the
EU one. It's been like this since they stuck their heads in a dark place,
and they've obviously not pulled it back out.
I expect that if we end up having to take action with AOL users (should AOL
start bouncing mail again for no good reason), we'll drop the Verizon users
at that time as well. Nobody should have to jump through loops to deliver
mail that people have requested - we're operating a listservice with code
confirmation, so forged s*bscriptions just isn't part of the picture.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail