You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ruleqa@spamassassin.apache.org by Axb <ax...@gmail.com> on 2014/09/13 17:05:13 UTC

RPATH_NULL_CTCQ

John

your rule RPATH_NULL_CTCQ _NULL also hits on very large part of my 
corpus because a bunch of my spam feeds send with an empty envelope 
sender to prevent possible bounces


see

http://ruleqa.spamassassin.org/20140913-r1624715-n/RPATH_NULL_CTCQ/detail

imo this rule should removed..

Alex

Re: RPATH_NULL_CTCQ

Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 9/13/2014 11:05 AM, Axb wrote:
>
> John
>
> your rule RPATH_NULL_CTCQ _NULL also hits on very large part of my 
> corpus because a bunch of my spam feeds send with an empty envelope 
> sender to prevent possible bounces
>
>
> see
>
> http://ruleqa.spamassassin.org/20140913-r1624715-n/RPATH_NULL_CTCQ/detail
>
> imo this rule should removed..
>
> Alex
Alex, your system is breaking the RFC I think:

https://www.ietf.org/rfc/rfc2821.txt

 From 4.5.5:

    All other types of messages (i.e., any message which is not required
    by a standards-track RFC to have a null reverse-path) SHOULD be sent
    with with a valid, non-null reverse-path.

    Implementors of automated email processors should be careful to make
    sure that the various kinds of messages with null reverse-path are
    handled correctly, in particular such systems SHOULD NOT reply to
    messages with null reverse-path.

My worry is that John's rule is accurate in a real-world anti-spam scenario and yours is an edge case.

regards,
KAM



Re: RPATH_NULL_CTCQ

Posted by John Hardin <jh...@impsec.org>.
On Sat, 13 Sep 2014, Axb wrote:

> John
>
> your rule RPATH_NULL_CTCQ _NULL also hits on very large part of my corpus 
> because a bunch of my spam feeds send with an empty envelope sender to 
> prevent possible bounces
>
> see
>
> http://ruleqa.spamassassin.org/20140913-r1624715-n/RPATH_NULL_CTCQ/detail
>
> imo this rule should removed..

I will suppress the scored _RPATH_NULL meta rules as your feeds are 
distorting the corpus.

I would note that this practice also destroys the usefulness of the 
ENV_AND_HDR_FROM_MATCH and ENV_AND_HDR_SPF_MATCH rules, and possibly some 
bounce-related rules as well.

Again, I would ask that you try to have your feeds use an envelope sender 
that you can capture and ignore bounces to, rather than performing a major 
modification of the raw spam by permanently *discarding* the 
original envelope sender.

Ideally the trap would save the envelope sender (perhaps in a custom 
header) and your collection system would restore that as the original 
envelope sender after receipt for corpus analysis so that your internal 
trap policies don't affect the quality and accuracy of your corpora.


-- 
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@impsec.org    FALaholic #11174     pgpk -a jhardin@impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   The fetters imposed on liberty at home have ever been forged out
   of the weapons provided for defense against real, pretended, or
   imaginary dangers from abroad.               -- James Madison, 1799
-----------------------------------------------------------------------
  4 days until the 227th anniversary of the signing of the U.S. Constitution