Sorry about the delay, I spent last week at the SANS conference and am
just getting around to "details" I needed to follow up on, this being
one of them.
Tom Emerson wrote:
>
> recently the ratio of "e-mails that work" vs. "e-mails that fail" has
> worsened considerably. So much so that now I'm resorting to posting via
> the newsgroup :)
Well, that certainly works, and posting through the web interface would
work as well.
> Ordinarilly I wouldn't care, but the "problem" only seems to exist for this
> one list, so just because it is anomolous, it is really starting to "bug
> me" -- I'm curious if it is something to do with the recent list changes
> [to reduce "spam"] or a strange misconfiguration of either my computer or
> various computer(s) at pacbell [which I've heard have been unreliable as of
> late...]
It is pacbell, though it is arguable that blocking their MTA would
result in a lot of collateral damage. I have tried not to be so
invasive of major ISP's MTAs lately, but I'm starting to find some
false positive blocks.
> When messages fail, I get the following [about three or four days later, so
> I've completely forgotten what I've posted and/or why...]:
>
> This report relates to a message you sent with the following header fields:
> Return-path: <[log in to unmask]>
> Received: from mta5.snfc21.pbi.net by mta5.snfc21.pbi.net
> (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002))
> id <[log in to unmask]>; Mon, 13 Jan 2003 00:47:32 -0800
> Your message is being returned; it has been enqueued and undeliverable for
> 3 days to the following recipients:
This is how our blocks work. We turn away SMTP completely. The real
advantage is we don't waste bandwidth or resources to receive it and
bounce it with a meaningful message. Granted, your mileage may vary,
as it has in this case.
> Since there is a "received..." line that gives a pacbell machine such as
> mta5.snfc21.pacbell.net or mta6..., and showing that it "came from" bigbro,
> I have to presume "it left the building here" OK and the "failed to
> connect/connection timed out" messages are being generated on or by the
> "mta..." computers.
Precisely in this case. mta5 is 206.13.28.241. mta6 is 206.13.28.240.
> So, now I'm very curious: are any other "pacbell" subscribers having
> difficulty posting "via e-mail"? If so, are you using "dial up" or do you
> have a DSL or better connection? [do we even HAVE any other pacbell
> subscribers?]
mta5 is listed by:
http://dsbl.org/listing.php?206.13.28.241
http://relays.osirusoft.com/cgi-bin/rbcheck.cgi?addr=206.13.28.241
http://www.croco.net/~drbl/cgi-bin/drbl-find.cgi?&Submit=Submit&.cgifields=zone&addr=206.13.28.241
http://www.samspade.org/t/rbl?a=206.13.28.241&r=on
mta6 is listed by:
http://dsbl.org/listing.php?206.13.28.240
http://www.croco.net/~drbl/cgi-bin/drbl-find.cgi?&Submit=Submit&.cgifields=zone&addr=206.13.28.240
http://www.samspade.org/t/rbl?a=206.13.28.240&r=on
They are clear with other providers, and both were on my "local" block
list (which probably got there because of multiple DNSBL listings as
confirmed above). We do NOT use any of the above resources automatically,
we only use SPEWS level 1 list (www.spews.org) plus the local additions
that were "confirmed" by me (comparing against numerous DNSBL lists).
I will pull the two pacbell listings for now, and if more spam comes
through it, I'll be sure to forward you a copy :-) The blocks should
be gone by the next update cycle.
Hopefully the above explanation serves to illustrate what/why we reject
spam sources and the "symptoms" you will see if your provider gets
listed.
Jeff
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
