You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Alex <my...@gmail.com> on 2016/05/12 14:37:16 UTC

Received header and matching

Hi,

I'm trying to match some Apple/iTunes fraud and would like to use the
lack of the email having been passed through anything relating to
Apple (contains apple.com, etc), and having some difficulty with this
header:

Received: from 56.119.233.220.static.exetel.com.au ([220.233.119.56]
helo=smtp.vic.exemail.com.au)
        by pecan.exetel.com.au with esmtps (TLSv1:DHE-RSA-AES256-SHA:256)
        (Exim 4.84)
        (envelope-from <ID...@ssl.apple.com>)
        id 1b0RAr-0003bC-72
        for milgrp@example.com; Wed, 11 May 2016 20:15:43 +1000

This rule apparently matches due to the envelope-from line above.

header  __LOC_APPLE_RCVD        Received =~ /apple\.com/

How can I get it to only match on the server name in that line?

Perhaps someone has a more effective rule for spam such as this one?
I'm using pypolicyd-spf and it's detected that there is an SPF
permerror, but apparently not a SA rule detected the SPF fail. It
would be good to add a few points for that somehow...

http://pastebin.com/SYq3Rysr

Thanks,
Alex

Re: Received header and matching

Posted by John Hardin <jh...@impsec.org>.
On Thu, 12 May 2016, Alex wrote:

> I'm trying to match some Apple/iTunes fraud and would like to use the
> lack of the email having been passed through anything relating to
> Apple (contains apple.com, etc), and having some difficulty with this
> header:
>
> Received: from 56.119.233.220.static.exetel.com.au ([220.233.119.56]
> helo=smtp.vic.exemail.com.au)
>        by pecan.exetel.com.au with esmtps (TLSv1:DHE-RSA-AES256-SHA:256)
>        (Exim 4.84)
>        (envelope-from <ID...@ssl.apple.com>)
>        id 1b0RAr-0003bC-72
>        for milgrp@example.com; Wed, 11 May 2016 20:15:43 +1000
>
> This rule apparently matches due to the envelope-from line above.
>
> header  __LOC_APPLE_RCVD        Received =~ /apple\.com/
>
> How can I get it to only match on the server name in that line?

Try matching on the external relays pseudo-header where that all gets 
normalized.

-- 
  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
-----------------------------------------------------------------------
  142 days since the first successful real return to launch site (SpaceX)

Re: Received header and matching

Posted by David Jones <dj...@ena.com>.
>From: Alex <my...@gmail.com>
>Sent: Thursday, May 12, 2016 9:37 AM
>To: SA Mailing list
>Subject: Received header and matching

>Hi,

>I'm trying to match some Apple/iTunes fraud and would like to use the
>lack of the email having been passed through anything relating to
>Apple (contains apple.com, etc), and having some difficulty with this
>header:

>Received: from 56.119.233.220.static.exetel.com.au ([220.233.119.56]
>helo=smtp.vic.exemail.com.au)
>        by pecan.exetel.com.au with esmtps (TLSv1:DHE-RSA-AES256-SHA:256)
>        (Exim 4.84)
>        (envelope-from <ID...@ssl.apple.com>)
>        id 1b0RAr-0003bC-72
>        for milgrp@example.com; Wed, 11 May 2016 20:15:43 +1000

>This rule apparently matches due to the envelope-from line above.

>header  __LOC_APPLE_RCVD        Received =~ /apple\.com/

>How can I get it to only match on the server name in that line?

>Perhaps someone has a more effective rule for spam such as this one?
>I'm using pypolicyd-spf and it's detected that there is an SPF
>permerror, but apparently not a SA rule detected the SPF fail. It
>would be good to add a few points for that somehow...

>http://pastebin.com/SYq3Rysr

whitelist_auth *@apple.com
whitelist_auth *@*.apple.com
whitelist_auth *@*.icloud.com
whitelist_auth *@itunes.com
whitelist_auth *@*.itunes.com

Then increase your scores a little for BAYES_*, SPF_FAIL,
T_DMARC_TESTS_FAIL, etc.

Over time, you can build up the whitelist_auth list of trusted
senders that are not human accounts that can be compromised
then the major domains that are commonly spoofed will be
covered properly to let them through.  Then you train your bayes
with the bad ones to get those BAYES_* hits up closer to BAYES_99
which will help scoring overall.

>Thanks,
>Alex