Re: [exim] Denying spam with forged from

Pàgina inicial
Delete this message
Reply to this message
Autor: W B Hacker
Data:  
A: exim users
Assumpte: Re: [exim] Denying spam with forged from
Patryk wrote:
> Hello,
>
> I've been running exim 4.96 + spamassassin very successfully over the
> last year, however recently a big amount of spam is received - because
> it forges the from field to my own hostname, which is of course in the
> whitelist of spamd (it has to be, a lot of traffic looks like spam but
> isn't).
>
> In this case I reviewed a sample header of a spam message, they look
> like this:
>
> Return-path: <przemysl@???>
> Envelope-to: przemyslaw.zak@???
> Delivery-date: Thu, 27 Nov 2008 15:58:06 +0100
> Received: from [212.62.52.156] (helo=BMARINKOVIC)
>     by ostc-pl.com with smtp (Exim 4.69)
>     (envelope-from <przemysl@???>)
>     id 1L5iJh-00020E-NU
>     for przemyslaw.zak@???; Thu, 27 Nov 2008 15:58:06 +0100
> X-Originating-IP: [61.706.92.425]
> X-Originating-Email: [przemyslaw.zak@???]
> X-Sender: przemyslaw.zak@???
> To: <przemyslaw.zak@???>
> Subject: RE:ci.Doctor Katy
> From: <przemyslaw.zak@???>
> MIME-Version: 1.0
> Importance: High
> Content-Type: text/html

>
> with the local_part being a valid username on my server, and ostc-pl.com
> being my hostname, this message was unfortunately delivered. So to block
> it I've added an acl check that would compare return-path field and the
> from field. If they are different, it most probably is spam.
>
> begin acl
> acl_check_rcpt:
> # first accept local mail traffic
>   accept  hosts = :
> # drop forged spam
>   deny    condition     = ${if !match{$header_from:}{$header_return-path:}}
>               message      = return path is not equal to from field, so
> I suspect spam, sir
> (...)

>
> Despite this, such mail is still being delivered. Could anyone please
> explain why is it letting it through? Thanks in advance!
>


Why are you accepting it *at all*??

Neither 61.706.92.425 nor 212.62.52.156 have PTR RR

As 212.62.52.156 has no DNS entry, it *cannot* match the HELO of
'BMARINKOVIC'

'BMARINKOVIC' is not a FQDN in any case.

deny/drop/defer before enterign acl_smtp_rcpt.

No need for recipient verification, saving router-verification traversal.

No need for you to take the headers and body onboard, saving storage.

No need to scan header formats, mime parts, or scan for malware.

No need to content-scan at all.

.... the above are reliable.

'From:" and 'Return path:' OTOH, may or may not be in agreement.

Bill