I reported the false positive (being a good netizin) to MXRATE
(Alligate) and their automated reply included the following:
"Generally, the most common reason an IP address is falsely listed in the MXRate database is when one of your users forwards all their mail to an account on a server protected by Alligate. Unfortunately, this usually includes all the spam and viruses they receive, and your server may be identified as the sending server."
Matt
Matt wrote:
Just a little follow up about this.
The first E-mail appears to be sent from your server in some sort of
automated fashion (denoted by the GSC extension on the Q file). These
are either postmaster messages, or some message created by calling
imail1.exe directly (probably some bulk-mail script in this case, maybe
even the listserv). It comes from the address [EMAIL PROTECTED]
and
was sent to a long list of addresses (too long for IMail not to throw
an error). It was whitelisted on the way out.
Then, one of the addresses on attglobal.net that it is sent to is
apparently forwarding back to [EMAIL PROTECTED]. It is
natural that
it gets scanned coming back in, creating a second set of headers and a
different spool file name. Your logs show the connecting hop as
32.97.166.48 which is in8.prserv.net and is used by AT&T for
sending/forwarding E-mail.
The E-mail was being blocked because of a combination of primarily two
things. First, your DNS setup was initially not allowing your server
to resolve your own MX records causing a failure in the MAILFROM test
when this came in from the other server with a Mail From domain of
ute-sei.org. Secondly, you are using MXRATE-BLOCK which has issues
with tagging legitimate servers with high volume that allow forwarding
(and some that are just simply high volume). To this blacklist, when
spam is received by an AT&T hosted account that is then forwarded
to an account on a different provider's machine that is sourced for
data to generate MXRATE-BLOCK, it ends up tagging the forwarding server
instead of the actual source. I stopped using MXRATE because of their
issues with such things, in addition to them tagging a lot of
legitimate bulk-mail that many blacklists have issues with and I didn't
want to compound such issues further on my system. I don't know what
you score MXRATE-BLOCK at, but you might consider dropping the score a
bit if you weight it heavily
Matt
Matt wrote:
Susan Duncan wrote:
That still
doesn’t explain why
someone who is whitelisted still has some of their email caught.
That's not the issue, they aren't actually both happening at the same
time. It's being double scanned, and it is only being whitelisted when
it is being sent, but not when it is received (over one minute later
according to your logs). The full headers should have showed the
complete path that the E-mail took and it would be easier to diagnose
if they were shared (the Received lines). I'm thinking that maybe this
E-mail was sent from your server to an address on another server that
was actually forwarded back to her address on your server. That's the
only way that I can think of that would generate two different spool
file names, and cause it to be scanned twice by Declude in this way;
adding headers each time.
Matt
--
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================
--
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================
--
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================
|
- Re: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not Matt
-