Re: Block email based on reply field

[li...@lazygranch.com]

On Wed, 18 Dec 2019 13:10:50 -0500
Viktor Dukhovni  wrote:

> [ I'm on the list, there's no need to Cc: me directly]
> 
> On Wed, Dec 18, 2019 at 01:36:17AM -0800, li...@lazygranch.com wrote:
> 
> > Viktor Dukhovni  wrote:
> > 
> > >   header-checks.pcre:
> > > if /^Reply-To:/
> > > # Adjust to exactly match the observed header
> > > # Includes rule id in reject message
> > > /[:\s<]spammer@example\.net[>\s]/ REJECT 5.7.1 Access
> > > denied R0001 /^/  DUNNO no
> > > more Reply-To rules endif
> 
> Note the "Adjust to exactly match ..."
> 
> > 1) I don't understand this line:
> > pcre = pcre:${config_directory}/
> 
> This is just defines a convenient shorthand.  You can then use
> ${pcre} instead of "pcre:${config_directory}/" each time you specify
> a PCRE table.
> 
> > header_checks = pcre:/etc/postfix/header_checks.pcre
> 
> This uses the expansion rather than the shorthand.
> 
> > 4) Here is the entry to reject the reply-to:
> > 
> > if /^Reply-To:/
> > /[:\s<]damnspammer\.org[>\s]/ REJECT
> > endif
> 
> This has no localpart, so won't match the Reply-To:
> 
> > That was a shortened version from Viktor's suggestion. Howver I had
> > also used:
> > 
> > if /^Reply-To:/
> > # Adjust to exactly match the observed header
> > # Includes rule id in reject message
> > /[:\s<]reply@mysecuritycamera\.org[>\s]/   REJECT 5.7.1 Access
> > denied R0001 /^/DUNNO no more
> > Reply-To rules endif
> 
> See below.
> 
> > Received: from trump.damnspammer.org (ec.compute.amazonaws.com
> > [1.2.3.4]) by www.mydomain.com (Postfix) with ESMTP id 5C82C6F591
> >  for ; Tue, 17 Dec 2019 22:35:52 + (UTC)
> > Subject: "oxygen flow" fruits for better garden performance
> > Reply-To: re...@damnspammer.org
> > To: m...@mydomain.com
> 
> In the above "Reply-To" the address has no surrounding "<>" and is
> not followed by anything.  Therefore, the PCRE match needs to be made
> a bit more flexible, allowing for the domain part to not have
> anything after it at all:
> 
> if /^Reply-To:/
> /[:\s<]reply@mysecuritycamera\.org([>\s]|$)/REJECT 5.7.1
> Access denied R0001 /^/
> DUNNO no more Reply-To rules endif
> 
> To test (this uses the "bash" <(...) inline file syntax):
> 
> $ postmap -q 'Reply-To: re...@mysecuritycamera.org' pcre:<(
>   printf 'if /^Reply-To:/\n%s %s\n/^/ %s\n%s\n' \
> '/[:\s<]reply@mysecuritycamera\.org([>\s]|$)/' \
> 'REJECT 5.7.1 Access denied R0001' \
> 'DUNNO no more Reply-To rules' \
> 'endif'
> )
> 

Well that was weird. Having a lot of faith in your code, I assumed the
cut and paste from email was putting in an invisible character. I kept
getting complaints about an unknow option. I just ended up typing the 4
lines myself. Seems to me you search for the ":" twice, so I need to
study PCRE some more. I got the white space search and end of line
check.

Given the invisible character issue via cut and paste, I
wrote a very small script and just fed the test string right to postfix.
(postmap -q "string" file)

I think is should just discard rather than reject, though reject is
more polite.

Thanks again. Now to wait for the spammer to er um offer me
pills to supercharge my begonia. It won't be a long wait.

Re: Rejecting email based upon MAIL FROM:, RCPT TO: and From: values

[Bill Cole]

On 18 Dec 2019, at 18:55, Konstantin Boyandin wrote:


Hello,

I need to possibly reject mail, in case the below is all true

- domain part of From: header and RCPT TO: addresses is the same
- domain part of MAIL FROM: differs from domain part of From: header

Looks like I need to use filtering via check_policy_service;


I don't believe so. I see nothing in the policy protocol documents that 
provides access to message headers or body.


This could be done with a Milter such as milter-regex or MIMEDefang.

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

Re: Rewriting e-mail headers (recipients) in Postfix (not header_checks) depending on complex logic

[Bill Cole]

On 18 Dec 2019, at 14:22, voroni...@soft-masters.ru wrote:

I have a mail system on Postfix+dovecot+amavisd+spamassassin+clamav. 
Now
there is a task, an easy one, actually, but I still cannot find a 
solution.
I need to change headers in emails according to several rules. For 
example,


IF ( CONTAINS 'ALIAS_1' AND  CONTAINS 'SOMEONE FROM ALIAS_1')
OR (IF ='ALIAS_1' AND  CONTAINS 'SOMEONE FROM ALIAS_1')
THEN (DELETE 'THIS SOMEONE FROM ALIAS_1' FROM  AND DELIVER TO 
OTHERS)


or

IF =ANYBODY_FROM_ALIAS_1 AND =ALIAS_1
THEN DELETE 'ONE_EMAIL_ADDRESS_FROM_ALIAS_1' FROM  AND DELIVER TO
OTHERS.

or if such requirements could not be met at least some tool would be 
nice

that can add another TO_header or remove some for some conditions.


MIMEDefang (www.mimedefang.org) is a Milter which can do anything to a 
message that you can implement as a Perl snippet. In addition to 
manipulating messages and their routing, it also has hooks for 
SpamAssassin and a wide range of AV tools, which are its most common 
uses.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

Re: Rejecting email based upon MAIL FROM:, RCPT TO: and From: values

[Wietse Venema]

Konstantin Boyandin:
> Hello,
> 
> I need to possibly reject mail, in case the below is all true
> 
> - domain part of From: header and RCPT TO: addresses is the same
> - domain part of MAIL FROM: differs from domain part of From: header
> 
> Looks like I need to use filtering via check_policy_service; question 
> is, into which Postfix restriction directives shall I add such a 
> condition?

http://www.postfwd.org/
http://www.postfix.org/SMTPD_POLICY_README.html

Wietse

Rejecting email based upon MAIL FROM:, RCPT TO: and From: values

[Konstantin Boyandin]

Hello,

I need to possibly reject mail, in case the below is all true

- domain part of From: header and RCPT TO: addresses is the same
- domain part of MAIL FROM: differs from domain part of From: header

Looks like I need to use filtering via check_policy_service; question 
is, into which Postfix restriction directives shall I add such a 
condition?


Thank you.

Sincerely,
Konstantin

Re: Rewriting e-mail headers (recipients) in Postfix (not header_checks) depending on complex logic

[Noel Jones]

On 12/18/2019 1:22 PM, voroni...@soft-masters.ru wrote:
I have a mail system on Postfix+dovecot+amavisd+spamassassin+clamav. 
Now there is a task, an easy one, actually, but I still cannot find 
a solution. I need to change headers in emails according to several 
rules. For example,


|IF ( CONTAINS 'ALIAS_1' AND  CONTAINS 'SOMEONE FROM ALIAS_1')|

|OR (IF ='ALIAS_1' AND  CONTAINS 'SOMEONE FROM ALIAS_1')|

|THEN (DELETE 'THIS SOMEONE FROM ALIAS_1' FROM  AND DELIVER TO 
OTHERS) |


or

|IF =ANYBODY_FROM_ALIAS_1 AND =ALIAS_1|

|THEN DELETE 'ONE_EMAIL_ADDRESS_FROM_ALIAS_1' FROM  AND DELIVER 
TO OTHERS.|


or if such requirements could not be met at least some tool would be 
nice that can add another TO_header or remove some for some conditions.


For example in EXIM MTA it can be done with exim.filter, smth like:

|if FROM contains A then deliver to B,C,D|

and so on.

I have lurked through http://www.postfix.org/addon.html

but could not find anything useful there.

Header_checks internal feature of Postfix has limitations that make 
it useless in my case, IMHO.


Any help would be most appreciated!




Try milter-regex.

Rewriting e-mail headers (recipients) in Postfix (not header_checks) depending on complex logic

[voronin_k]

I have a mail system on Postfix+dovecot+amavisd+spamassassin+clamav. Now
there is a task, an easy one, actually, but I still cannot find a solution.
I need to change headers in emails according to several rules. For example,

IF ( CONTAINS 'ALIAS_1' AND  CONTAINS 'SOMEONE FROM ALIAS_1')
OR (IF ='ALIAS_1' AND  CONTAINS 'SOMEONE FROM ALIAS_1')
THEN (DELETE 'THIS SOMEONE FROM ALIAS_1' FROM  AND DELIVER TO OTHERS)  

or

IF =ANYBODY_FROM_ALIAS_1 AND =ALIAS_1
THEN DELETE 'ONE_EMAIL_ADDRESS_FROM_ALIAS_1' FROM  AND DELIVER TO
OTHERS.

or if such requirements could not be met at least some tool would be nice
that can add another TO_header or remove some for some conditions.

For example in EXIM MTA it can be done with exim.filter, smth like:

if FROM contains A then deliver to B,C,D

and so on.

I have lurked through  
http://www.postfix.org/addon.html

but could not find anything useful there.

Header_checks internal feature of Postfix has limitations that make it
useless in my case, IMHO.

Any help would be most appreciated!

 

Re: Block email based on reply field

[Viktor Dukhovni]

[ I'm on the list, there's no need to Cc: me directly]

On Wed, Dec 18, 2019 at 01:36:17AM -0800, li...@lazygranch.com wrote:

> Viktor Dukhovni  wrote:
> 
> >   header-checks.pcre:
> > if /^Reply-To:/
> > # Adjust to exactly match the observed header
> > # Includes rule id in reject message
> > /[:\s<]spammer@example\.net[>\s]/   REJECT 5.7.1 Access denied R0001
> > /^/ DUNNO no more Reply-To rules
> > endif

Note the "Adjust to exactly match ..."

> 1) I don't understand this line:
> pcre = pcre:${config_directory}/

This is just defines a convenient shorthand.  You can then use ${pcre} instead
of "pcre:${config_directory}/" each time you specify a PCRE table.

> header_checks = pcre:/etc/postfix/header_checks.pcre

This uses the expansion rather than the shorthand.

> 4) Here is the entry to reject the reply-to:
> 
> if /^Reply-To:/
> /[:\s<]damnspammer\.org[>\s]/ REJECT
> endif

This has no localpart, so won't match the Reply-To:

> That was a shortened version from Viktor's suggestion. Howver I had
> also used:
> 
> if /^Reply-To:/
> # Adjust to exactly match the observed header
> # Includes rule id in reject message
> /[:\s<]reply@mysecuritycamera\.org[>\s]/   REJECT 5.7.1 Access denied 
> R0001
> /^/DUNNO no more Reply-To rules
> endif

See below.

> Received: from trump.damnspammer.org (ec.compute.amazonaws.com [1.2.3.4])
>  by www.mydomain.com (Postfix) with ESMTP id 5C82C6F591
>  for ; Tue, 17 Dec 2019 22:35:52 + (UTC)
> Subject: "oxygen flow" fruits for better garden performance
> Reply-To: re...@damnspammer.org
> To: m...@mydomain.com

In the above "Reply-To" the address has no surrounding "<>" and is not followed
by anything.  Therefore, the PCRE match needs to be made a bit more flexible,
allowing for the domain part to not have anything after it at all:

if /^Reply-To:/
/[:\s<]reply@mysecuritycamera\.org([>\s]|$)/REJECT 5.7.1 Access denied 
R0001
/^/ DUNNO no more Reply-To rules
endif

To test (this uses the "bash" <(...) inline file syntax):

$ postmap -q 'Reply-To: re...@mysecuritycamera.org' pcre:<(
  printf 'if /^Reply-To:/\n%s %s\n/^/ %s\n%s\n' \
'/[:\s<]reply@mysecuritycamera\.org([>\s]|$)/' \
'REJECT 5.7.1 Access denied R0001' \
'DUNNO no more Reply-To rules' \
'endif'
)

-- 
Viktor.

Re: configuration postscreen

[Claus R. Wickinghoff]

Hi Wietse,


So for me it still makes sense to combine postscreen with postgrey, as
postscreen works mainly on ip addresses (their reputation in fact) while
postgrey also takes care on sender's and recipient's e-mail addresses.


By design, postscreen does not know the sender or recipient.


In particular, when postscreen allows a remote SMTP client to talk
to a Postfix SMTP server process, it must make that decision before
the remote SMTP client has sent any commands.


Sure.

My point was that a combination of both seem to make sense. And I 
brought an example to show it, similar to the situation that I asked a 
couple of days ago.


I had another similar situation today, when the other server passed 
postscreen and got greylisted in the beginning and then rejected by 
postscreen due to blacklist entries. So the dns lifetime in the cache 
works, too.


I'm still impressed how much spam you can get rid off just on smtp level.

Groetjes
   Claus

Re: configuration postscreen

[Wietse Venema]

Wietse Venema:
> Claus R. Wickinghoff:
> > So for me it still makes sense to combine postscreen with postgrey, as 
> > postscreen works mainly on ip addresses (their reputation in fact) while 
> > postgrey also takes care on sender's and recipient's e-mail addresses.
> 
> By design, postscreen does not know the sender or recipient.

In particular, when postscreen allows a remote SMTP client to talk
to a Postfix SMTP server process, it must make that decision before
the remote SMTP client has sent any commands.

Wietse

Re: DMARC usage opinion

[Roberto Carna]

Perfect!!!

Now I understand and I'll to start DMARC implementation with p=none to see
what happen.

Regards !!!

El mié., 18 dic. 2019 a las 7:22, Gregory Heytings () escribió:

>
> Hi,
>
> I'd second Viktor Dukhovni's opinion.  For the vast majority of mail
> servers, a minimalistic DMARC policy suffices, just add the following
> record in the domain's DNS root zone:
>
> _dmarc 10800 IN TXT "v=DMARC1; p=none;"
>
> If you want to go a step further, you can just monitor how DMARC is
> applied by receiving mail servers to mails that (pretend to) come from
> your domain.  Just add a "rua" ("reporting aggregate reports") entry:
>
> _dmarc 10800 IN TXT "v=DMARC1; p=none; rua=mailto:
> postmas...@yourdomain.com"
>
> You'll then start receiving a daily report from the mail servers that
> implement DMARC reporting *and* that received at least one mail coming
> from (or pretending to come from) your domain.  In most cases you'll only
> receive reports from Google and Yahoo.  These reports are XML files, which
> are difficult to read, so you should find a tool that helps you to make
> sense of them.
>
> The possible next steps are to use "p=quarantine", which basically means
> "deliver the mail but flag it as spam", and "p=reject", which means what
> it means: do not accept the email.  But as Viktor said these policies are
> not recommended for a domain which does not handle sensitive information
> (bank, government, hospital, ...).
>
> Gregory
>

Re: configuration postscreen

[Wietse Venema]

Claus R. Wickinghoff:
> So for me it still makes sense to combine postscreen with postgrey, as 
> postscreen works mainly on ip addresses (their reputation in fact) while 
> postgrey also takes care on sender's and recipient's e-mail addresses.

By design, postscreen does not know the sender or recipient.

Wietse

Re: DMARC usage opinion

[Gregory Heytings]

Hi,

I'd second Viktor Dukhovni's opinion.  For the vast majority of mail 
servers, a minimalistic DMARC policy suffices, just add the following 
record in the domain's DNS root zone:


_dmarc 10800 IN TXT "v=DMARC1; p=none;"

If you want to go a step further, you can just monitor how DMARC is 
applied by receiving mail servers to mails that (pretend to) come from 
your domain.  Just add a "rua" ("reporting aggregate reports") entry:


_dmarc 10800 IN TXT "v=DMARC1; p=none; rua=mailto:postmas...@yourdomain.com;

You'll then start receiving a daily report from the mail servers that 
implement DMARC reporting *and* that received at least one mail coming 
from (or pretending to come from) your domain.  In most cases you'll only 
receive reports from Google and Yahoo.  These reports are XML files, which 
are difficult to read, so you should find a tool that helps you to make 
sense of them.


The possible next steps are to use "p=quarantine", which basically means 
"deliver the mail but flag it as spam", and "p=reject", which means what 
it means: do not accept the email.  But as Viktor said these policies are 
not recommended for a domain which does not handle sensitive information 
(bank, government, hospital, ...).


Gregory

Re: Block email based on reply field

[li...@lazygranch.com]

On Wed, 11 Dec 2019 21:56:48 -0500
Viktor Dukhovni  wrote:

> > On Dec 11, 2019, at 9:38 PM, li...@lazygranch.com wrote:
> > 
> > I have a spammer who uses all sorts of "from" addresses but the same
> > "reply" address. Any way to block this spammer in Postfix.  
> 
>   main.cf:
>   pcre = pcre:${config_directory}/
>   header_checks = ${pcre}header-checks.pcre
>   # Set empty, or keep existing non-default value
>   nested_header_checks =
>   mime_header_checks =
> 
>   header-checks.pcre:
> if /^Reply-To:/
> # Adjust to exactly match the observed header
> # Includes rule id in reject message
> /[:\s<]spammer@example\.net[>\s]/ REJECT 5.7.1 Access
> denied R0001 /^/  DUNNO no more
> Reply-To rules endif
> 

Well I tried this with no luck. Here are my comments:
1) I don't understand this line:
pcre = pcre:${config_directory}/
Doing a search I can't find this line used. However I think my pcre is
working anyway. Within my main.cf, I have the line:

header_checks = pcre:/etc/postfix/header_checks.pcre


2) I RTFM postfix section on header_checks and did a few tests to see
if they are working. The first one I did was put a long sequence of
letters and numbers similar to a password to be detected in the
subject line. Inside header_checks.pcre, I added this line:
/^Subject: moDjbQje7duHkYI0TNc/ REJECT

Sending an email with that sequence to my server did bounce the
message. Incidentally I am doing these tests from a yahoo email account
rather than my own domain.

3) I found no way to spoof the reply-to field from yahoo email. But as
a test, I decided to block my yahoo email from my own email server.
Here is the line in header_checks.pcre:

if /^From:/
/[:\s<]me@yahoo\.com[>\s]/ REJECT 1.1.1
endif

This did bounce the message.

4) Here is the entry to reject the reply-to:

if /^Reply-To:/
/[:\s<]damnspammer\.org[>\s]/ REJECT
endif

That was a shortened version from Viktor's suggestion. Howver I had
also used:

if /^Reply-To:/
# Adjust to exactly match the observed header
# Includes rule id in reject message
/[:\s<]reply@mysecuritycamera\.org[>\s]/   REJECT 5.7.1 Access
denied R0001
/^/DUNNO no more Reply-To rules
endif

Excuse the word wrap due to the Claws. Note that every time I changed
the header_checks.pcre file I did a 
systemctl reload postfix
systemctl restart postfix

Having no way to send the spoofed Reply-To line, I waited for spam to
arrive. And of course I wasn't disappointed. 

I will supply the sanitized versions of the maillog and the received
email header from Claws. (Sanitized due to google. No use having my
real domain in the message.)

From Claws email header:

-
Return-Path: 
X-Original-To: m...@mydomain.com
Delivered-To: m...@mydomain.com
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; 
client-ip=1.2.3.4; helo=trump.damnspammer.org; 
envelope-from=bou...@trump.damnspammer.org; receiver=m...@mydomain.com 
DMARC-Filter: OpenDMARC Filter v1.3.2 www.mydomain.com 5C82C6F591
Authentication-Results: mydomain.com; dmarc=none (p=none dis=none) 
header.from=dog.cat.jp
Authentication-Results: mydomain.com; spf=pass 
smtp.mailfrom=bou...@trump.damnspammer.org
DKIM-Filter: OpenDKIM Filter v2.11.0 www.mydomain.com 5C82C6F591
Received: from trump.damnspammer.org (ec.compute.amazonaws.com [1.2.3.4])
 by www.mydomain.com (Postfix) with ESMTP id 5C82C6F591
 for ; Tue, 17 Dec 2019 22:35:52 + (UTC)
MIME-Version: 1.0
From: "oxygen flow" to your begonia  !
Subject: "oxygen flow" fruits for better garden performance
Reply-To: re...@damnspammer.org
To: m...@mydomain.com
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="UTF-8"


From /var/log/maillog:

--
Dec 17 22:35:51 mydomain postfix/smtpd[28909]: connect from 
ec.compute.amazonaws.com[1.2.3.4]
Dec 17 22:35:53 mydomain policyd-spf[28914]: spfcheck: pyspf result: "['Pass', 
'sender SPF authorized', 'helo']"
Dec 17 22:35:53 mydomain policyd-spf[28914]: Pass; identity=helo; 
client-ip=1.2.3.4; helo=trump.damnspammer.org; 
envelope-from=bou...@trump.damnspammer.org; receiver=m...@mydomain.com
Dec 17 22:35:53 mydomain policyd-spf[28914]: spfcheck: pyspf result: "['Pass', 
'sender SPF authorized', 'mailfrom']"
Dec 17 22:35:53 mydomain policyd-spf[28914]: Pass; identity=mailfrom; 
client-ip=1.2.3.4; helo=trump.damnspammer.org; 
envelope-from=bou...@trump.damnspammer.org; receiver=m...@mydomain.com
Dec 17 22:35:53 mydomain postfix/smtpd[28909]: 5C82C6F591: 
client=ec.compute.amazonaws.com[1.2.3.4]
Dec 17 22:35:53 mydomain postfix/cleanup[28915]: 5C82C6F591: message-id=<>
Dec 17 22:35:53 mydomain opendkim[1272]: 5C82C6F591: ec.compute.amazonaws.com 
[1.2.3.4] not internal
Dec 17 22:35:53 mydomain opendkim[1272]: 5C82C6F591: not authenticated
Dec 17 22:35:53 mydomain opendkim[1272]: 5C82C6F591: no signature data
Dec 17 22:35:53 mydomain opendmarc[1262]: 

Re: Advice: NFS, hardware, SATA vs SAS etc

[Matus UHLAR - fantomas]

> > > Yes. Do any Postfix administrators with busy systems rely on NFS?
> > > That seems like a really bad idea, honestly.



> So NFS is a poor, outdated choice for mail storage in 2020 for a small/medium
> enterprise?



On any large number of users some kind of hash is used to distribute email
storage across multiple nodes.


On 17.12.19 22:32, venbian wrote:

Oh that's the obvious answer I didn't think of (but everyone else was
thinking, right?).  Let IMAP proxy LDA and IMAP traffic to a few file
servers.  Then those servers won't need expensive SAN as long as they have
respectable SATA/RAID.


Just FYI, proxy won't help you whe one of the storage hosts fails.
We have used NFS cluster because of that. 


Mails were processed locally, only delivered to the NFS storage.

Having queue on NFS would not be very efficient but would be safe against
outage of host with postfix. 


However, this is off-topic in this queue. hopefully proposed solutions will
be enough for you, good luck.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)