More about "Allow only mu servers to send mail from my domain"

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

More about "Allow only mu servers to send mail from my domain"

decosvaldo
Hi Everybody,

I was trying to use check_sender_access as sugested here in the forum  
to avoid this type of SPAMs. But it is not working.
check_sender_access works more like a blacklist and the spammers are  
ready for that.

Check this message bellow:

First the maillog:
Aug  7 17:40:19 hubble cbpolicyd[20640]: module=Greylisting,  
action=pass, host=81.45.22.109,  
helo=109.Red-81-45-22.staticIP.rima-tde.net,  
from=[hidden email],  
to=[hidden email], reason=authenticated
Aug  7 17:40:19 hubble postfix/smtpd[21446]: 7319F143C27:  
client=109.Red-81-45-22.staticIP.rima-tde.net[81.45.22.109]
Aug  7 17:40:19 hubble postfix/cleanup[21233]: 7319F143C27:  
message-id=<[hidden email]>
Aug  7 17:40:19 hubble postfix/qmgr[21657]: 7319F143C27:  
from=<[hidden email]>, size=2838,  
nrcpt=1 (queue active)
Aug  7 17:40:19 hubble postfix/smtpd[21446]: disconnect from  
109.Red-81-45-22.staticIP.rima-tde.net[81.45.22.109]
Aug  7 17:40:19 hubble postfix/smtpd[20751]: connect from localhost[127.0.0.1]
Aug  7 17:40:19 hubble postfix/smtpd[20751]: EB443143C3C:  
client=localhost[127.0.0.1]
Aug  7 17:40:20 hubble postfix/cleanup[21534]: EB443143C3C:  
message-id=<[hidden email]>
Aug  7 17:40:20 hubble postfix/qmgr[21657]: EB443143C3C:  
from=<[hidden email]>, size=3315,  
nrcpt=1 (queue active)
Aug  7 17:40:20 hubble amavis[21479]: (21479-01) loaded policy bank "MYNETS"
Aug  7 17:40:20 hubble amavis[21479]: (21479-01) ESMTP::10024  
/var/spool/amavisd/tmp/amavis-20140807T174020-21479-yVTh_Crs:  
<[hidden email]> ->  
<[hidden email]> SIZE=3315 Received: from  
mail.iqm.unicamp.br ([127.0.0.1]) by localhost (hubble.iqm.unicamp.br  
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP for  
<[hidden email]>; Thu,  7 Aug 2014 17:40:20 -0300 (BRT)
Aug  7 17:40:20 hubble postfix/smtpd[20751]: disconnect from  
localhost[127.0.0.1]
Aug  7 17:40:20 hubble postfix/lmtp[20103]: 7319F143C27:  
to=<[hidden email]>,  
relay=mail.iqm.unicamp.br[/var/run/dspam/dspam.sock], delay=1.3,  
delays=0.97/0/0/0.31, dsn=2.6.0, status=sent (250 2.6.0  
<[hidden email]> Message accepted for delivery)
Aug  7 17:40:20 hubble postfix/qmgr[21657]: 7319F143C27: removed


Notice that the message was sent from  
from=[hidden email]  
to=[hidden email]


When I received the message the header inside the e-mail message contains:

Return-Path: <[hidden email]>
Delivered-To: <[hidden email]>
Received: from mail.iqm.unicamp.br ([143.106.51.19])
        by kepler.iqm.unicamp.br (Dovecot) with LMTP id QB7kFa6P41PyTwAAV0VrhQ
        for <[hidden email]>; Thu, 07 Aug 2014 17:40:24 -0300
Received: from localhost (localhost [127.0.0.1])
        by mail.iqm.unicamp.br (Postfix) with ESMTP id 501F51449AD
        for <[hidden email]>; Thu,  7 Aug 2014 17:40:24 -0300 (BRT)
Received: from mail.iqm.unicamp.br ([127.0.0.1])
        by localhost (hubble.iqm.unicamp.br [127.0.0.1]) (amavisd-new, port 10024)
        with ESMTP id fmX2GScyk8hw for <[hidden email]>;
        Thu,  7 Aug 2014 17:40:20 -0300 (BRT)
Received: from localhost (localhost [127.0.0.1])
        by mail.iqm.unicamp.br (Postfix) with SMTP id EB443143C3C
        for <[hidden email]>; Thu,  7 Aug 2014 17:40:19 -0300 (BRT)
Received: from 109.Red-81-45-22.staticIP.rima-tde.net  
(109.Red-81-45-22.staticIP.rima-tde.net [81.45.22.109])
        by mail.iqm.unicamp.br (Postfix) with ESMTP id 7319F143C27
        for <[hidden email]>; Thu,  7 Aug 2014 17:40:18 -0300 (BRT)
Received: by 109.Red-81-45-22.staticIP.rima-tde.net (Postfix, from userid 33)
        id B31032836; Thu,  7 Aug 2014 20:26:03 +0000 (UTC)
To: [hidden email]
Subject:   CRUZ ALTA LTDA
X-PHP-Originating-Script: 0:mag.php
MIME-Version: 1.0
Content-type: text/html; charset=iso-8859-1
X-Mailer: Microsoft Office Outlook, Build 17.551210
From: [hidden email]
Message-Id: <[hidden email]>
Date: Thu,  7 Aug 2014 20:26:03 +0000 (UTC)

Inside the message, the FROM contains webmaster@mydomain...
Is there a way to create rules like check_sender_access but based on  
the header inside the mail message instead of the server connection?
I cannot block messages with SPF, because here we have a lot of false  
positives.

Thanks

Reply | Threaded
Open this post in threaded view
|

Re: More about "Allow only mu servers to send mail from my domain"

DTNX Postmaster
On 08 Aug 2014, at 14:53, Andre Luiz Paiz <[hidden email]> wrote:

> I was trying to use check_sender_access as sugested here in the forum to avoid this type of SPAMs. But it is not working.
> check_sender_access works more like a blacklist and the spammers are ready for that.

It is not working because you are confusing the envelope from with the 'From:' header. The 'check_sender_access' restriction works for the envelope only, not on the headers, and the headers are basically untrustworthy and easily forged.

> Notice that the message was sent from from=[hidden email] to=[hidden email]

[snip]

> Inside the message, the FROM contains webmaster@mydomain...
> Is there a way to create rules like check_sender_access but based on the header inside the mail message instead of the server connection?
> I cannot block messages with SPF, because here we have a lot of false positives.

SPF does not work because, like 'check_sender_access', it does only work on the envelope, not the headers. For basic header checks, you can use 'header_checks';

http://www.postfix.org/header_checks.5.html

I suspect that what you really need is better blacklisting, though. There's generally no need to accept anything from generic hostnames such as '109.red-81-45-22.staticip.rima-tde.net', for example.

Are you running postscreen? Using blacklists?

Mvg,
Joni

Reply | Threaded
Open this post in threaded view
|

Re: More about "Allow only mu servers to send mail from my domain"

decosvaldo
Quoting DTNX Postmaster <[hidden email]>:

> On 08 Aug 2014, at 14:53, Andre Luiz Paiz <[hidden email]> wrote:
>
>> I was trying to use check_sender_access as sugested here in the  
>> forum to avoid this type of SPAMs. But it is not working.
>> check_sender_access works more like a blacklist and the spammers  
>> are ready for that.
>
> It is not working because you are confusing the envelope from with  
> the 'From:' header. The 'check_sender_access' restriction works for  
> the envelope only, not on the headers, and the headers are basically  
> untrustworthy and easily forged.

On my check_sender_access I registered [hidden email] as  
REJECT. So in my case this from it is the envelop, correct? You are  
saying that I should register the  
[hidden email] on check_sender_access?

>
>> Notice that the message was sent from  
>> from=[hidden email]  
>> to=[hidden email]
>
> [snip]
>
>> Inside the message, the FROM contains webmaster@mydomain...
>> Is there a way to create rules like check_sender_access but based  
>> on the header inside the mail message instead of the server  
>> connection?
>> I cannot block messages with SPF, because here we have a lot of  
>> false positives.
>
> SPF does not work because, like 'check_sender_access', it does only  
> work on the envelope, not the headers. For basic header checks, you  
> can use 'header_checks';
>
> http://www.postfix.org/header_checks.5.html
>
> I suspect that what you really need is better blacklisting, though.  
> There's generally no need to accept anything from generic hostnames  
> such as '109.red-81-45-22.staticip.rima-tde.net', for example.
>
> Are you running postscreen? Using blacklists?

I use Spamassassin and PolicyD (Cluebringer). The access control in  
PolicyD checks the header or envelope?
Don´t know about postscreen, Can you please give an example of how it  
should work?


>
> Mvg,
> Joni
>
>
> Scanned and tagged with DSPAM 3.10.2 by Instituto de Quimica - Unicamp
>
> !DSPAM:9303,53e4dca823581248319621!

Thanks
Andre

Reply | Threaded
Open this post in threaded view
|

Re: More about "Allow only mu servers to send mail from my domain"

DTNX Postmaster
On 08 Aug 2014, at 16:45, Andre Luiz Paiz <[hidden email]> wrote:

> Quoting DTNX Postmaster <[hidden email]>:
>
>> On 08 Aug 2014, at 14:53, Andre Luiz Paiz <[hidden email]> wrote:
>>
>>> I was trying to use check_sender_access as sugested here in the forum to avoid this type of SPAMs. But it is not working.
>>> check_sender_access works more like a blacklist and the spammers are ready for that.
>>
>> It is not working because you are confusing the envelope from with the 'From:' header. The 'check_sender_access' restriction works for the envelope only, not on the headers, and the headers are basically untrustworthy and easily forged.
>
> On my check_sender_access I registered [hidden email] as REJECT. So in my case this from it is the envelop, correct? You are saying that I should register the [hidden email] on check_sender_access?

That would work, but only for that specific sender. So it's generally not a very effective way to block spam, as it only covers one address on a single host. It can be decent as a temporary measure, though.

>> SPF does not work because, like 'check_sender_access', it does only work on the envelope, not the headers. For basic header checks, you can use 'header_checks';
>>
>> http://www.postfix.org/header_checks.5.html
>>
>> I suspect that what you really need is better blacklisting, though. There's generally no need to accept anything from generic hostnames such as '109.red-81-45-22.staticip.rima-tde.net', for example.
>>
>> Are you running postscreen? Using blacklists?
>
> I use Spamassassin and PolicyD (Cluebringer). The access control in PolicyD checks the header or envelope?
> Don´t know about postscreen, Can you please give an example of how it should work?

Did you read the 'header_checks' documentation? Have you used the Postfix documentation in general? Like, for example, if you search for 'postscreen' here;

http://www.postfix.org/documentation.html

It will lead you to;

http://www.postfix.org/POSTSCREEN_README.html

As for SpamAssassin and PolicyD, they are not part of Postfix; refer to their respective documentation for their specific features.

Mvg,
Joni