On Thursday 23 March 2006 17:22, Professional Software Engineering
wrote:
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.
With an attitude like that, how is the poor vz customer, and I'm a vz
customer because they have a monopoly here, supposed to deal with it?
And yes, I've personally told them they are being terminally stupid. 2
or 4 times... The closest they will come is to accept an alternate
alias that will bypass all this used bovine food. See my sig. But
when I do subscribe using that address, then the mailing list server,
generally speaking, will not accept it because the sending server marks
it as coming from the normal address. So I'm screwed either way,
without even a hint of a foreplay kiss. Sucks is the word that comes
to mind. :(
---
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
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
____________________________________________________________
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