On Sat, 12 Feb 2005, Matt Kettler wrote:
> At 11:13 AM 2/12/2005, Theodore Heise wrote:
> > > The XBL however, has the "notfirsthop" restriction. It won't match
> > > any messages that have no trusted relays. Based on the debug
> > > output, there were no trusted relays, thus XBL would not have
At 11:13 AM 2/12/2005, Theodore Heise wrote:
> The XBL however, has the "notfirsthop" restriction. It won't match
> any messages that have no trusted relays. Based on the debug
> output, there were no trusted relays, thus XBL would not have
> matched for this reason.
I think I follow this for why i
On Sat, 12 Feb 2005, Matt Kettler wrote:
> At 10:01 AM 2/12/2005, Theodore Heise wrote:
> >When the spam in question arrived, several rules did not appear to
> >fire; specifically the two RBLs RCVD_IN_BL_SPAMCOP_NET and
> >RCVD_IN_XBL, as well as URIBL_OB_SURBL.
>
> Well, The URIBL and Spamcop c
At 10:01 AM 2/12/2005, Theodore Heise wrote:
When the spam in question arrived, several rules did not appear to
fire; specifically the two RBLs RCVD_IN_BL_SPAMCOP_NET and
RCVD_IN_XBL, as well as URIBL_OB_SURBL.
Well, The URIBL and Spamcop changes are almost certainly due to time
difference. Those
Hi all,
I'm very puzzled by the attached spam that appeared in my inbox
last night. I'm running Slackware 9.1, with SpamAssassin-3.0.0,
sendmail-8.12.10, and procmail-3.15.2. I run spamassassin (not
spamd), and invoke it from procmail. I use pine4.58 as my client.
This all runs on a PIII box w
