On 3/5/2014 9:40 AM, Neil Schwartzman wrote:
>
> Yeah. An abused, and abusive redirector. They only deal with abuse
> Monday-Friday, 9:00-17:00.* They never break links, but put an
> interstitial in between the victim and the payload. Gee thanks.
>
They do at least deal with it.
We reported a
--On Friday, March 14, 2014 2:28 PM +1300 Jason Haar
wrote:
No - I don't use amavis. That's why I said "spamc" :-)
Well... The docs say time_limit defaults to 300 seconds (5 minutes). The
inconsistent scoring I'm seeing is all occuring under 5 seconds, so I don't
think it's related.
--Q
No - I don't use amavis. That's why I said "spamc" :-)
On 14/03/14 10:50, John Hardin wrote:
> On Fri, 14 Mar 2014, Jason Haar wrote:
>
>> Just yesterday I manually pushed a piece of spam through spamc and
>> spamassassin and got a different score too. It ended up being caused by
>> "time_limit".
--On Thursday, March 13, 2014 6:25 PM -0700 Quanah Gibson-Mount
wrote:
And here is another email, from the *same* user to the *same* user that
does not have RCVD_IN_DNSWL_HI!!!
Mar 13 19:21:07 edge02 amavis[3918]: (03918-12) spam-tag,
-> , No, score=-0.148 tagged_above=-10
required=3 tests=[
--On Thursday, March 13, 2014 4:27 PM -0700 Quanah Gibson-Mount
wrote:
This is missing RCVD_IN_DNSWL_HI. This email originated on our MTAs, and
was delivered going through them.
This did too, and correclty has that rule applied:
Mar 13 17:00:08 edge02 amavis[39369]: (39369-17-3) spam-tag,
--On Thursday, March 13, 2014 3:50 PM -0700 John Hardin
wrote:
On Fri, 14 Mar 2014, Jason Haar wrote:
Just yesterday I manually pushed a piece of spam through spamc and
spamassassin and got a different score too. It ended up being caused by
"time_limit". "spamassassin" didn't listen to it wh
On Fri, 14 Mar 2014, Jason Haar wrote:
Just yesterday I manually pushed a piece of spam through spamc and
spamassassin and got a different score too. It ended up being caused by
"time_limit". "spamassassin" didn't listen to it whereas spamc/spamd did
and the email took a lng time to process
Just yesterday I manually pushed a piece of spam through spamc and
spamassassin and got a different score too. It ended up being caused by
"time_limit". "spamassassin" didn't listen to it whereas spamc/spamd did
and the email took a lng time to process - triggering the scores to
be different
I
--On Thursday, March 13, 2014 3:15 PM -0700 John Hardin
wrote:
> FWIW they're running amavisd-new, and we're trying to figure out why the
scores on MTA-processed messages are so much lower than when the same
message is passed through command-line SA in debug mode.
Hi John,
Interesting -- I'
On Thu, 13 Mar 2014, Quanah Gibson-Mount wrote:
--On Thursday, March 13, 2014 1:48 PM -0700 John Hardin
wrote:
On Thu, 13 Mar 2014, Quanah Gibson-Mount wrote:
> In looking at why some spam is still making it through, it appears that
> Pyzor errors block URIBL lookups:
I'm working with
--On Thursday, March 13, 2014 1:48 PM -0700 John Hardin
wrote:
On Thu, 13 Mar 2014, Quanah Gibson-Mount wrote:
In looking at why some spam is still making it through, it appears that
Pyzor errors block URIBL lookups:
I'm working with someone who seems to be having the same problem in 3.3.
On Thu, 13 Mar 2014, Quanah Gibson-Mount wrote:
In looking at why some spam is still making it through, it appears that Pyzor
errors block URIBL lookups:
I'm working with someone who seems to be having the same problem in 3.3.1
- thanks for noting this, I will take a closer look.
--
John H
In looking at why some spam is still making it through, it appears that
Pyzor errors block URIBL lookups:
Mar 13 13:15:23.849 [28433] dbg: uridnsbl: complete_dnsbl_lookup
URIBL_SBL_A DNSBL:1.193.124.98:sbl.spamhaus.org
Mar 13 13:15:23.849 [28433] dbg: uridnsbl: complete_dnsbl_lookup URIBL_SBL
13 matches
Mail list logo
