At 9:05 AM -0700 10/4/06, Mark Sapiro wrote:
> Now this may well be a coincidence, but it is also possible that
> att.net had a DNS reverse lookup error at the beginning and blocked
> the IP. Then each subsequent mail found a 'cached' block and was
> itself blocked and also updated the cache expiration. When I stopped
> sending for over a week, the cached entry finally expired. This is
> conjecture and may not be correct, but I think it is not necessarily a
> good idea to keep reenabling bounces like this.
There are plenty of places out there that run seriously screwed-up
nameservers, and cache data in direct violation of the TTLs specified
on the records, or do various other strange things.
It's also possible that you were running afoul of a firewall/network
abuse rule, and by continually re-enabling those users you kept
tripping that rule -- and resetting whatever auto-timeout they may
have put on it. By letting those users sit for a while, the rule
ended up getting dropped and then when you re-enabled them later, you
no longer had this problem. I've seen automated network intrusion
detection systems do this sort of thing.
One thing in common with both of these explanations is that the
larger the recipient site, the more likely they are to be doing
strange and bizarre things behind the scenes in order to deal with a
wide variety of problems that you will probably never even have heard
of, and when they do those kinds of things they are much more likely
to have strange and bizarre side-effects -- which they frequently
won't even know about themselves, and even if they do know about them
they will almost certainly never discuss them with any outside party.
Cisco PIX firewalls used to break the SMTP protocol by default, when
you enabled their SMTP proxy implementation. People would do this to
try to gain a measure of security-through-obscurity, but all that
would really do is tell the whole world that their clueless
mail/firewall administrators don't care about breaking SMTP e-mail to
the world, and that they're using piss-poor Cisco PIX firewall crap
to do it. But they would never admit anything about what they were
doing, and would violently refuse to accept any blame for any mail
breakage problems that they caused.
Strangely enough, once someone pointed them at the specific piece of
the Cisco documentation that showed precisely what they were doing
wrong with precisely which stupid piece of equipment and then how to
fix that damn configuration problem, things would mysteriously start
working again -- but again without any kind of acknowledgement as to
what idiot had broken the thing or why it had taken them so long to
fix the thing that we all knew that they had broken (and how they had
broken it).
Cisco PIX firewalls can still break SMTP e-mail in this way, but at
least they're not configured to do so by default, out-of-the-box.
And you still get plenty of idiots in this world that set things up
and then refuse to accept blame or even acknowledge that they could
possibly have caused any portion of the problem they are experiencing.
--
Brad Knowles, <[EMAIL PROTECTED]>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
Founding Individual Sponsor of LOPSA. See <http://www.lopsa.org/>.
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
