Re: Continuous quick connects / disconnects from some servers

[Matus UHLAR - fantomas]

On 04.03.22 09:18, Nikolaos Milas wrote:
I sometimes find abnormal continuous connects/disconnects which delay 
normal mail deliveries.


Here is an example:

Mar  3 10:06:42 vmail2 postfix/smtpd[22733]: connect from unknown[45.148.10.243]
Mar  3 10:06:43 vmail2 postfix/smtpd[22733]: lost connection after AUTH from 
unknown[45.148.10.243]
Mar  3 10:06:43 vmail2 postfix/smtpd[22733]: disconnect from 
unknown[45.148.10.243] ehlo=1 auth=0/1 commands=1/2
Mar  3 10:06:43 vmail2 postfix/smtpd[22730]: warning: hostname 
edc45.app-autht.com does not resolve to address 45.148.10.243: Name or service 
not known
Mar  3 10:06:43 vmail2 postfix/smtpd[22730]: connect from unknown[45.148.10.243]
Mar  3 10:06:43 vmail2 postfix/smtpd[22730]: lost connection after AUTH from 
unknown[45.148.10.243]



Mar  3 10:06:43 vmail2 postfix/smtpd[22730]: disconnect from 
unknown[45.148.10.243] ehlo=1 auth=0/1 commands=1/2
Mar  3 10:06:44 vmail2 postfix/smtpd[22852]: warning: hostname 
edc45.app-autht.com does not resolve to address 45.148.10.243: Name or service 
not known
Mar  3 10:06:44 vmail2 postfix/smtpd[22852]: connect from unknown[45.148.10.243]
Mar  3 10:06:44 vmail2 postfix/smtpd[22852]: lost connection after AUTH from 
unknown[45.148.10.243]
Mar  3 10:06:44 vmail2 postfix/smtpd[22852]: disconnect from 
unknown[45.148.10.243] ehlo=1 auth=0/1 commands=1/2


[...]


Would it be legitimate to ban such servers using fail2ban based on:

  lost connection after AUTH

i.e. when there are multiple such entries within few seconds or 
minutes associated with particular servers?


legitimate, I do that on many servers.


Any other suggestions for dealing with the problem?

Note: This is an internal server (with user mailboxes, also used as 
our SMTP server for outgoing mail), not accepting incoming mail 
directly but from two mail gateway servers - also running postfix - so 
we are not running postscreen on it. Would you suggest running 
postscreen too?


in such case postscreen should not be needed, BUT, it seems that connection 
from the outside are allowed in which case postscreen makes sense.


Other solution would of course be disabling SMTP connections from the world.

Would postscreen help in a situation like the above, 
if the remote server is in some RBL?


yes.

--
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.
I don't have lysdexia. The Dog wouldn't allow that.

Re: Continuous quick connects / disconnects from some servers

[Nikolaos Milas]

On 4/3/2022 10:22 π.μ., Matus UHLAR - fantomas wrote:

...
Other solution would of course be disabling SMTP connections from the 
world.

...


Thank you Matus for all your advice.

Regarding blocking port 25 from the world, couldn't it cause issues when 
communicating to other SMTP servers since this is our SMTP server (for 
outgoing mail)?


Of course, users connect to port 587 to send mail, but aren't there any 
scenarios when the server needs to be contacted directly by other SMTP 
servers around the world? For example, if a remote server wants to send 
a non-deliverable notification for a mail it received from our server 
(vmail2.noa.gr) will it *always* check our zone MX records to reply 
using the mail gateway servers rather than replying directly to the source?


If it's operationally safe, I'd rather block port 25 from outside on 
this server (using iptables).


Please advise!

Thanks again,
Nick

postfix 3.7.0 port 25 listening stops at some point (after max a few days), no error messages

[Gerben Wierda]

I have upgraded my postfix 3.6 to postfix 3.7.0 as well as having upgraded my 
macOS on which postfix runs from 10.4 (Mojave) to 12 (Monterey)

I have the following problem. postfix is running as expected, but at some point 
it becomes inoperable on port 25 listening for incoming connections. Using a 
telnet connection to port 25 just gives no reply and times out. There are no 
error messages that I see. The last entry in postfix.log is:

Mar 03 21:56:23 mail postfix/postscreen[56506]: CONNECT from 
[112.152.206.91]:21680 to [192.168.2.66]:25
Mar 03 21:56:23 mail postfix/dnsblog[56507]: addr 112.152.206.91 listed by 
domain zen.spamhaus.org as 127.255.255.254
Mar 03 21:56:29 mail postfix/postscreen[56506]: PASS NEW [112.152.206.91]:21680
Mar 03 21:56:30 mail smtp/smtpd[56511]: connect from unknown[112.152.206.91]
Mar 03 21:56:30 mail smtp/smtpd[56511]: NOQUEUE: reject: RCPT from 
unknown[112.152.206.91]: 450 4.7.1 Client host rejected: cannot find your 
reverse hostname, [112.152.206.91]; from= 
to= proto=ESMTP helo=<[112.152.206.91]>
Mar 03 21:56:31 mail smtp/smtpd[56511]: lost connection after DATA from 
unknown[112.152.206.91]
Mar 03 21:56:31 mail smtp/smtpd[56511]: disconnect from unknown[112.152.206.91] 
ehlo=1 mail=1 rcpt=0/1 data=0/1 commands=2/4
Mar 03 21:59:51 mail postfix/anvil[56513]: statistics: max connection rate 
1/60s for (smtpd:141.98.10.58) at Mar  3 21:56:09
Mar 03 21:59:51 mail postfix/anvil[56513]: statistics: max connection count 1 
for (smtpd:141.98.10.58) at Mar  3 21:56:09
Mar 03 21:59:51 mail postfix/anvil[56513]: statistics: max cache size 2 at Mar  
3 21:56:30

After that, nothing until I stop and start postfix again.

Mar 04 11:05:18 mail postfix[72387]: Postfix is using backwards-compatible 
default settings
Mar 04 11:05:18 mail postfix[72387]: See 
http://www.postfix.org/COMPATIBILITY_README.html for details
Mar 04 11:05:18 mail postfix[72387]: To disable backwards compatibility use 
"postconf compatibility_level=3.6" and "postfix reload"
Mar 04 11:05:18 mail /postfix-script[72394]: stopping the Postfix mail system
Mar 04 11:05:19 mail postfix[72401]: Postfix is using backwards-compatible 
default settings
Mar 04 11:05:19 mail postfix[72401]: See 
http://www.postfix.org/COMPATIBILITY_README.html for details
Mar 04 11:05:19 mail postfix[72401]: To disable backwards compatibility use 
"postconf compatibility_level=3.6" and "postfix reload"
Mar 04 11:05:20 mail postfix/postsuper[72443]: warning: bogus file name: 
maildrop/.turd_postfix
Mar 04 11:05:20 mail /postfix-script[72458]: warning: not owned by _postfix: 
/opt/local/var/lib/postfix/./.turd_postfix
Mar 04 11:05:20 mail /postfix-script[72464]: warning: not owned by _postfix: 
/opt/local/var/spool/postfix/public/.turd_postfix
Mar 04 11:05:20 mail /postfix-script[72473]: warning: 
/opt/local/var/spool/postfix/etc/services and /etc/services differ
Mar 04 11:05:20 mail /postfix-script[72475]: starting the Postfix mail system
Mar 04 11:05:20 mail postfix/master[72477]: daemon started -- version 3.7.0, 
configuration /opt/local/etc/postfix

There was a comparable hole in the log and a not working postfix before when 
also mail waas not being received (that was the first time I noticed, so it is 
now twice and not some sort of hiccup but a real problem):

Mar 03 08:18:56 mail smtp/smtpd[29550]: connect from 
mail.rspamd.net[135.181.136.158]
Mar 03 08:18:56 mail smtp/smtpd[29550]: F357AB40B241: 
client=mail.rspamd.net[135.181.136.158]
Mar 03 08:18:57 mail postfix/cleanup[29552]: F357AB40B241: 
message-id=<1478821c-5453-25c9-e8a8-acf0339e3945@mez
onplus.ru>
Mar 03 08:18:58 mail smtp/smtpd[29550]: disconnect from 
mail.rspamd.net[135.181.136.158] ehlo=2 starttls=1 mail
=1 rcpt=1 data=1 quit=1 commands=7
Mar 03 08:18:58 mail postfix/qmgr[35300]: F357AB40B241: 
from=, size=6024, nrcpt
=1 (queue active)
Mar 03 08:18:58 mail postfix/local[29555]: F357AB40B241: passing 
 to transport=lmtp
Mar 03 08:18:58 mail postfix/lmtp[29556]: F357AB40B241: 
to=, orig_to=, relay=mail.rna.nl[private/dovecot-lmtp], delay=1.4, delays=1.4/0/0/0.01, 
>dsn=2.0.0, status=sent (250 2.0.0 <
ger...@albus.rna.nl> +AhSFuJrIGJ1cwAAnjsRrA Saved)
Mar 03 08:18:58 mail postfix/qmgr[35300]: F357AB40B241: removed
Mar 03 08:22:18 mail postfix/anvil[29427]: statistics: max connection rate 
1/60s for (smtpd:69.72.43.246) at Ma
r  3 08:12:47
Mar 03 08:22:18 mail postfix/anvil[29427]: statistics: max connection count 1 
for (smtpd:69.72.43.246) at Mar  
3 08:12:47
Mar 03 08:22:18 mail postfix/anvil[29427]: statistics: max cache size 3 at Mar  
3 08:14:50
Mar 03 11:43:30 mail submission/smtpd[34023]: warning: hostname 
hosted-by.rootlayer.net does not resolve to add
ress 185.222.58.109
Mar 03 11:43:30 mail submission/smtpd[34023]: connect from 
unknown[185.222.58.109]
Mar 03 11:43:30 mail submission/smtpd[34023]: lost connection after EHLO from 
unknown[185.222.58.109]
Mar 03 11:43:30 mail submission/smtpd[34023]: disconnect from 
unknown[185.222.58.109] ehlo=1 auth=0/1 comman

Re: postfix 3.7.0 port 25 listening stops at some point (after max a few days), no error messages

[Wietse Venema]

Gerben Wierda:
> I have the following problem. postfix is running as expected, but
> at some point it becomes inoperable on port 25 listening for
> incoming connections. Using a telnet connection to port 25 just
> gives no reply and times out.

Possibilities:

- Something is blocking the TCP/IP handshake, perhaps a dynamic
firewalling rule that expires. New connection requests time out.

- The Postfix master daemon no longer receives notification that a
connection is established, and not-yet-accepted connections accumulate
inside the kernel. After a while the kernel queue for such connections
is full, and new connections requests will time out.

I recall that MacOS for the longest time had a broken kqueue(2) 
implementation before Darwin 12.

The relevant section in the makedefs script:

# kqueue works in Mac OS X 10.8 (Darwin 12).
case $RELEASE in
?.*|1[0-1].*) CCARGS="$CCARGS -DNO_KQUEUE";;
esac

Which means that your old Postfix was built with kqueue support
disabled, and your new Postfix tries to use kqueue().

kqueue() is a more scalable alternative to poll() and select().
It was introduced into the BSD family ~20 years ago.

Try building with 

make makefiles CCARGS="-DNO_KQUEUE ..."

If that solves the problem then I'll update makedefs again.

Wietse

Trying to understand this DNSBL blocking issue

[Gerben Wierda]

From main.cf:

postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11]
postscreen_dnsbl_action = drop

I am trying to understand the behaviour from the log. The first is this one:

Feb 27 06:02:19 mail postfix/postscreen[46928]: CONNECT from 
[113.197.35.193]:49976 to [192.168.2.66]:25
Feb 27 06:02:19 mail postfix/dnsblog[46930]: addr 113.197.35.193 listed by 
domain zen.spamhaus.org as 127.255.255.254
Feb 27 06:02:25 mail postfix/postscreen[46928]: PASS OLD [113.197.35.193]:49976
Feb 27 06:02:27 mail smtp/smtpd[46943]: connect from 
hb3479.ds.ns01.net[113.197.35.193]
Feb 27 06:02:29 mail smtp/smtpd[46943]: NOQUEUE: reject: RCPT from 
hb3479.ds.ns01.net[113.197.35.193]: 550 5.1.1 : Recipient 
address rejected: User unknown;
 from= to= proto=ESMTP 
helo=

The 254 response means: the query comes form an open resolver so we’re not 
going to reply properly. The mail is a spam messages and could be in a DNSBL, 
but I get a ’no reply for you’.

Mar 04 18:44:25 mail postfix/postscreen[88228]: CONNECT from 
[189.51.96.252]:38442 to [192.168.2.66]:25
Mar 04 18:44:25 mail postfix/dnsblog[88230]: addr 189.51.96.252 listed by 
domain zen.spamhaus.org as 127.0.0.4
Mar 04 18:44:25 mail postfix/dnsblog[88230]: addr 189.51.96.252 listed by 
domain zen.spamhaus.org as 127.0.0.11
Mar 04 18:44:25 mail postfix/dnsblog[88230]: addr 189.51.96.252 listed by 
domain zen.spamhaus.org as 127.0.0.3
Mar 04 18:44:26 mail postfix/postscreen[88228]: PREGREET 14 after 0.61 from 
[189.51.96.252]:38442: EHLO mega.nz\r\n
Mar 04 18:44:26 mail postfix/postscreen[88228]: DISCONNECT [189.51.96.252]:38442

These responses mean the DNSBL works ok,

How do I fix the former one?

Gerben Wierda (LinkedIn )
R&A IT Strategy  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

Re: Trying to understand this DNSBL blocking issue

[Bastian Blank]

On Fri, Mar 04, 2022 at 06:58:33PM +0100, Gerben Wierda wrote:
> Feb 27 06:02:19 mail postfix/dnsblog[46930]: addr 113.197.35.193 listed by 
> domain zen.spamhaus.org as 127.255.255.254
> The 254 response means: the query comes form an open resolver so we’re not 
> going to reply properly. The mail is a spam messages and could be in a DNSBL, 
> but I get a ’no reply for you’.
> How do I fix the former one?

Don't use a public resolver.  A MTA using public DNSBL need to run their
own recursive resolver.  This is a Spamhaus issue, they tell you to go
away.

Bastian

-- 
Extreme feminine beauty is always disturbing.
-- Spock, "The Cloud Minders", stardate 5818.4

Re: Continuous quick connects / disconnects from some servers

[Bill Cole]

On 2022-03-04 at 03:55:54 UTC-0500 (Fri, 4 Mar 2022 10:55:54 +0200)
Nikolaos Milas 
is rumored to have said:

> On 4/3/2022 10:22 π.μ., Matus UHLAR - fantomas wrote:
>> ...
>> Other solution would of course be disabling SMTP connections from the world.
>> ...
>
> Thank you Matus for all your advice.
>
> Regarding blocking port 25 from the world, couldn't it cause issues when 
> communicating to other SMTP servers since this is our SMTP server (for 
> outgoing mail)?

No. Port 25 is only used for incoming SMTP cconnections. When your server sends 
mail, it uses an ephemeral high port number for the local end and connects to 
port 25 on the receiving server. If you do not accept mail directly from the 
world at large, you do not need to accept connections from the world on port 25.

> Of course, users connect to port 587 to send mail, but aren't there any 
> scenarios when the server needs to be contacted directly by other SMTP 
> servers around the world? For example, if a remote server wants to send a 
> non-deliverable notification for a mail it received from our server 
> (vmail2.noa.gr) will it *always* check our zone MX records to reply using the 
> mail gateway servers rather than replying directly to the source?

Right now, vmail2.noa.gr has no MX record and the IPv4 address for it (which is 
what would be used without any MX) is not accepting connections on port 25, so 
I'm not 100% sure how that relates to this, i.e. it looks like you're already 
dropping port 25 traffic inbound. So, I'm not sure that I understand the 
question correctly...

NDNs are sent to the envelope sender ("Return-Path") of the original message. 
For one-to-one mail that is almost always the same as the From header of a 
message. In some cases (mailing lists and mail forwarded by servers that do SRS 
to protect messages from SPF rejection) the envelope sender may use the domain 
name of the mail server doing the forwarding, in which case the best practice 
is to have a MX record for that name. With Postfix, the name that the server 
uses for mail generated locally is $myorigin, which can be any valid name that 
works and defaults to $myhostname, which defaults to whatever the system call 
gethostname() returns, qualified with ".$mydomain" if necessary. NDNs generated 
by Postfix (or any MTA) use a null envelope sender, so they are not a problem.

IN SHORT: Unless you are doing something which rewrites the envelope sender of 
mail with the hostname of the server, that server does not need to accept mail 
on port 25 from the world at large.


> If it's operationally safe, I'd rather block port 25 from outside on this 
> server (using iptables).

It looks like you are doing that now. It is almost certainly safe for a system 
where inbound mail is coming through a gateway to which your MX records point. 
It is also safe, and considered a best practice, to disable authentication on 
port 25 because authenticated mail should be coming in on port 587 or 465.


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

Re: Trying to understand this DNSBL blocking issue

[Noel Jones]

On 3/4/2022 11:58 AM, Gerben Wierda wrote:

Feb 27 06:02:19 mail postfix/dnsblog[46930]: addr 113.197.35.193 
listed by domain zen.spamhaus.org  as 
*127.255.255.254*


This query was made on 27 Feb via a public DNS nameserver that is 
blocked by spamhaus.



Mar 04 18:44:25 mail postfix/dnsblog[88230]: addr 189.51.96.252 
listed by domain zen.spamhaus.org  as 
*127.0.0.4*


This query on 04 Mar was made via a different DNS nameserver that 
was not blocked by spamhaus.


If you're using a public DNS service, it's possible some of their 
back-end servers are blocked and some aren't, which will give you 
unpredictable results.


To fix, insure you either use a local DNS nameserver installed on 
your computer, such as unbound, or sign up for the free (for low 
volume) Spamhaus Data Query Service




  -- Noel Jones

Re: postfix 3.7.0 port 25 listening stops at some point (after max a few days), no error messages

[Bill Cole]

On 2022-03-04 at 06:20:27 UTC-0500 (Fri, 4 Mar 2022 12:20:27 +0100)
Gerben Wierda 
is rumored to have said:

> I have upgraded my postfix 3.6 to postfix 3.7.0 as well as having upgraded my 
> macOS on which postfix runs from 10.4 (Mojave) to 12 (Monterey)

Mojave is/was 10.14, not 10.4 (Tiger.)

That relates to Wietse's mention of kqueue (which is NOT relevant to 10.14)

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

Re: Setting Up Header Checks

[Austin Witmer]

For some reason I can’t make Milter-regex install on ubuntu? The “make” command 
gives me an error when I try to run it. Does it have to run on a BSD based 
server?

> On Feb 26, 2022, at 3:37 PM, Wietse Venema  wrote:
> 
> nt to make tests indpendent of

Re: Continuous quick connects / disconnects from some servers

[Nikolaos Milas]

On 4/3/2022 8:55 μ.μ., Bill Cole wrote:

...
Right now, vmail2.noa.gr has no MX record and the IPv4 address for it (which is 
what would be used without any MX) is not accepting connections on port 25, so 
I'm not 100% sure how that relates to this, i.e. it looks like you're already 
dropping port 25 traffic inbound. So, I'm not sure that I understand the 
question correctly...
...
It is also safe, and considered a best practice, to disable authentication on 
port 25 because authenticated mail should be coming in on port 587 or 465.
...


Hi Bill,

Thank you for the analysis. I do appreciate your time.

I decided to drop world connections to port 25 today after Matus' 
feedback (and my poor analysis of the situation), so most probably you 
checked shortly after I did the change.


With regard to disabling AUTH on port 25 only - we need to let AUTH 
available on submission port (587) - what exactly should I do? Would it 
be enough to remove "permit_sasl_authenticated" from 
"smtpd_client_restrictions" in main.cf?


Thanks again to you and to everyone who responded.

Nick

Re: Continuous quick connects / disconnects from some servers

[Bill Cole]

On 2022-03-04 at 15:02:28 UTC-0500 (Fri, 4 Mar 2022 22:02:28 +0200)
Nikolaos Milas 
is rumored to have said:

> With regard to disabling AUTH on port 25 only - we need to let AUTH available 
> on submission port (587) - what exactly should I do? Would it be enough to 
> remove "permit_sasl_authenticated" from "smtpd_client_restrictions" in 
> main.cf?

No, that isn't enough, it just makes authentication pointless.

ALSO remove "smtpd_sasl_auth_enable = yes" from main.cf and add '-o 
smtpd_sasl_auth_enable = yes" to your submission and smtps services in 
master.cf, i.e. something like this:

submission inet  n   -   n   -   -   smtpd
-o syslog_name=postfix/submit
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
smtps  inet  n   -   n   -   -   smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING-TLS



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

Re: Continuous quick connects / disconnects from some servers

[postfix]

> With regard to disabling AUTH on port 25 only - we need to let AUTH available 
> on submission port (587)
> what exactly should I do? Would it be enough to remove
> "permit_sasl_authenticated" from "smtpd_client_restrictions" in main.cf?


main.cf:
   smtpd_sasl_auth_enable = no


master.cf:
   submissioninetn   -   n   -   -   smtpd
  -o smtpd_sasl_auth_enable=yes

Re: Setting Up Header Checks

[Wietse Venema]

Austin Witmer:
> For some reason I can't make Milter-regex install on ubuntu? The
> "make" command gives me an error when I try to run it. Does it
> have to run on a BSD based server?

Did you try apt-get? 

Wietse

Re: Setting Up Header Checks

[Jaroslaw Rafa]

Dnia  4.03.2022 o godz. 16:46:53 Wietse Venema pisze:
> Austin Witmer:
> > For some reason I can't make Milter-regex install on ubuntu? The
> > "make" command gives me an error when I try to run it. Does it
> > have to run on a BSD based server?
> 
> Did you try apt-get? 

milter-regex is not in the Ubuntu repositories (at least for 20.04).
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Setting Up Header Checks

[PGNet Dev]

On 3/4/22 4:46 PM, Wietse Venema wrote:

Austin Witmer:

For some reason I can't make Milter-regex install on ubuntu? The
"make" command gives me an error when I try to run it. Does it
have to run on a BSD based server?


Did you try apt-get?

Wietse


sigh.

 
https://packages.ubuntu.com/search?keywords=milter-regex&searchon=names&suite=all§ion=all

You have searched for packages that names contain milter-regex in all 
suites, all sections, and all architectures.
Sorry, your search gave no results

milter-regex runs fine on linux

on ubu, you've got a couple of options


(1) find/convert a rpm with alien

https://manpages.ubuntu.com/manpages/trusty/man1/alien.1p.html

here's one

https://src.fedoraproject.org/rpms/milter-regex


(2) if you're building from src, on linux, you'll want to edit/modify 
`Makefile.linux`, as appropriate, then

make -f Makefile.linux clean
make -f Makefile.linux
make -f Makefile.linux install

instead of just `make`

(3) adapt an rpm.spec, e.g.


https://src.fedoraproject.org/rpms/milter-regex/blob/rawhide/f/milter-regex.spec

& build/package your own deb for convenient apt-get mgmt

Re: header_checks and regexes

[Alex]

Hi,

> > I believe there's a dot missing in the first one, as in '.(386' but
> > it's more than that, because I experimented with that too.
>
> No, it would have to be:  \.(386|...)
> otherwise '.' just matches any character.  Your RE pattern is sloppy
> in places, ... correct REs take some care.

Yes, that is what I meant. I believe there were problems with the
regex that I fixed, but I was also using header_checks instead of
mime_header_checks.

Just for completeness, here's what worked for me.

Given the following attachment:
--caef4405d964f4b8
Content-Type: text/html; charset="US-ASCII"; name="download.html"
Content-Disposition: attachment; filename="download.html"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: f_l0chj96g0

TWFpbGd1biBNYWduaWZpY2VudCBBUEk=
--caef4405d964f4b8--

$ postmap -c /etc/postfix -q 'Content-Disposition: attachment;
filename="download.html"' pcre:/etc/postfix/mime_header_checks.pcre
REJECT ".html" file attachment types not allowed

mime_header_checks = pcre:/etc/postfix/mime_header_checks.pcre

/^Content-(Disposition|Type):\s+.+?(file)?name="?.+?\.(386|exe|ad[ept]|app|as[dpx]|ba[st]|bin|btm|cab|cb[lt]|cgi|chm|cil|cla(ss)?|cmd|cp[el]|crt|cs[chs]|cvp|dll|dot|drv|em(ai)?l|ex[_e]|fon|fxp|hlp|ht[ar]|in[fips]|html|isp|jar|jse?|keyreg|ksh|lib|lnk|md[abetw]|mht(m|ml)?|mp3|ms[ciopt]|nte|nws|obj|ocx|ops|ov.|pcd|pgm|pif|p[lm]|pot|pps|prg|reg|sc[rt]|sh[bs]?|slb|smm|sw[ft]|sys|url|vb[esx]?|vir|vmx|vxd|wm[dsz]|ws[cfh]|xlw|xms|\{[\da-f]{8}(?:-[\da-f]{4}){3}-[\da-f]{12}\})\b/
REJECT ".$3" file attachment types not allowed

Can I also ask a more general question? How are other people handling
attachments such as those I've listed which really have no purpose
these days but to spread malware?

The vast majority of HTML attachments we receive are not malicious,
but just silently quarantining them was leading to too many support
requests.

Thanks so much for your help.

Re: Setting Up Header Checks

[Austin Witmer]

See my question below.

> On Mar 4, 2022, at 3:08 PM, PGNet Dev  wrote:
> 
> On 3/4/22 4:46 PM, Wietse Venema wrote:
>> Austin Witmer:
>>> For some reason I can't make Milter-regex install on ubuntu? The
>>> "make" command gives me an error when I try to run it. Does it
>>> have to run on a BSD based server?
>> Did you try apt-get?
>>  Wietse
> 
> sigh.
> 
> https://packages.ubuntu.com/search?keywords=milter-regex&searchon=names&suite=all§ion=all
> 
>   You have searched for packages that names contain milter-regex in all 
> suites, all sections, and all architectures.
>   Sorry, your search gave no results
> 
> milter-regex runs fine on linux
> 
> on ubu, you've got a couple of options
> 
> 
> (1) find/convert a rpm with alien
> 
>   https://manpages.ubuntu.com/manpages/trusty/man1/alien.1p.html
> 
> here's one
> 
>   https://src.fedoraproject.org/rpms/milter-regex
> 
> 
> (2) if you're building from src, on linux, you'll want to edit/modify 
> `Makefile.linux`, as appropriate, then

What do I need to modify in the Makefile.linux file for my Ubuntu system?

> 
>   make -f Makefile.linux clean
>   make -f Makefile.linux
>   make -f Makefile.linux install
> 
> instead of just `make`

I had been trying to just use ‘make’ and was running into errors. Thanks for 
these commands. I will give them a try once I know how I should edit the 
Makefile.linux file.

> 
> (3) adapt an rpm.spec, e.g.
> 
>   
> https://src.fedoraproject.org/rpms/milter-regex/blob/rawhide/f/milter-regex.spec
> 
> & build/package your own deb for convenient apt-get mgmt

Re: Setting Up Header Checks

[PGNet Dev]

What do I need to modify in the Makefile.linux file for my Ubuntu system?

short answer: to whatever YOUR system, and your interests, need

i don't use ubuntu, so can't help you specifically

i strongly suggest you look at the defaults, and modify path accordingly for your ubu 
sys; if you're building from src & installing, you should know your tools & 
path paths

fwiw, mine, for *my* fedoral install, which i do NOT recommend you blindly 
copy/use, is

  milter-regex-2.7/Makefile.my_linux
CFLAGS+=
LDFLAGS=-L/usr/lib64 -lmilter -lpthread -lbsd

all: milter-regex milter-regex.cat8

milter-regex: milter-regex.o eval.o y.tab.o
gcc -o milter-regex milter-regex.o eval.o y.tab.o $(LDFLAGS)

milter-regex.o: milter-regex.c eval.h
gcc $(CFLAGS) -c milter-regex.c

eval.o: eval.c eval.h
gcc $(CFLAGS) -c eval.c

y.tab.o: y.tab.c
gcc $(CFLAGS) -c y.tab.c

y.tab.c: parse.y
yacc -d parse.y

milter-regex.cat8: milter-regex.8
nroff -Tascii -mandoc milter-regex.8 > milter-regex.cat8

clean:
rm -f *.core milter-regex y.tab.* *.o *.cat8

install:
rm -rf /usr/local/milter-regex
mkdir -p /usr/local/milter-regex/{share/man/man8,sbin}
cp ./milter-regex /usr/local/milter-regex/sbin
cp milter-regex.8 milter-regex.cat8 
/usr/local/milter-regex/share/man/man8/

uninstall:
rm -rf /usr/local/milter-regex

Re: Trying to understand this DNSBL blocking issue

[Gerben Wierda]

On 4 Mar 2022, at 19:13, Bastian Blank 
 wrote:
> 
> On Fri, Mar 04, 2022 at 06:58:33PM +0100, Gerben Wierda wrote:
>> Feb 27 06:02:19 mail postfix/dnsblog[46930]: addr 113.197.35.193 listed by 
>> domain zen.spamhaus.org as 127.255.255.254
>> The 254 response means: the query comes form an open resolver so we’re not 
>> going to reply properly. The mail is a spam messages and could be in a 
>> DNSBL, but I get a ’no reply for you’.
>> How do I fix the former one?
> 
> Don't use a public resolver.  A MTA using public DNSBL need to run their
> own recursive resolver.  This is a Spamhaus issue, they tell you to go
> away.

I cannot explicitly tell postfix to use another resolver (I’d like to like I 
can do with rspamd), right? Because the main resolver here uses cloud9 because 
of its blocking and for all clients this is fine. 

G

Re: Trying to understand this DNSBL blocking issue

[Gerben Wierda]

I am already running my own unbound resolver.

Van I configure my unbound in such a way that it forwards everything to 9.9.9.9 
(which is my setting so I can use its blocking) except DNS queries for 
spamhaus.org ?

If not, I need some way to tell postfix to use another resolver than the 
default one.

Or I must forego the use of 9.9.9.9 and lose its DNS blocking of ‘evil’ hosts. 

G

> On 4 Mar 2022, at 19:57, Noel Jones  wrote:
> 
> 
> On 3/4/2022 11:58 AM, Gerben Wierda wrote:
> 
>> Feb 27 06:02:19 mail postfix/dnsblog[46930]: addr 113.197.35.193 listed by 
>> domain zen.spamhaus.org  as *127.255.255.254*
> 
> This query was made on 27 Feb via a public DNS nameserver that is blocked by 
> spamhaus.
> 
> 
>> Mar 04 18:44:25 mail postfix/dnsblog[88230]: addr 189.51.96.252 listed by 
>> domain zen.spamhaus.org  as *127.0.0.4*
> 
> This query on 04 Mar was made via a different DNS nameserver that was not 
> blocked by spamhaus.
> 
> If you're using a public DNS service, it's possible some of their back-end 
> servers are blocked and some aren't, which will give you unpredictable 
> results.
> 
> To fix, insure you either use a local DNS nameserver installed on your 
> computer, such as unbound, or sign up for the free (for low volume) Spamhaus 
> Data Query Service
> 
> 
> 
>  -- Noel Jones

Re: Setting Up Header Checks

[Austin Witmer]

To be honest, this is the first install from source that I’ve attempted. I’m a 
total noob at this, so if someone wishes to help me out further with getting 
milter-regex installed on Ubuntu, I wouldn’t mind.

Maybe I will end up trying one of the other options that were suggested . . .

Thanks for all the help that I have been given so far! I appreciate it!

Austin Witmer

> On Mar 4, 2022, at 4:41 PM, PGNet Dev  wrote:
> 
> 
>> 
>> What do I need to modify in the Makefile.linux file for my Ubuntu system?
> short answer: to whatever YOUR system, and your interests, need
> 
> i don't use ubuntu, so can't help you specifically
> 
> i strongly suggest you look at the defaults, and modify path accordingly for 
> your ubu sys; if you're building from src & installing, you should know your 
> tools & path paths
> 
> fwiw, mine, for *my* fedoral install, which i do NOT recommend you blindly 
> copy/use, is
> 
>  milter-regex-2.7/Makefile.my_linux
>CFLAGS+=
>LDFLAGS=-L/usr/lib64 -lmilter -lpthread -lbsd
> 
>all: milter-regex milter-regex.cat8
> 
>milter-regex: milter-regex.o eval.o y.tab.o
>gcc -o milter-regex milter-regex.o eval.o y.tab.o $(LDFLAGS)
> 
>milter-regex.o: milter-regex.c eval.h
>gcc $(CFLAGS) -c milter-regex.c
> 
>eval.o: eval.c eval.h
>gcc $(CFLAGS) -c eval.c
> 
>y.tab.o: y.tab.c
>gcc $(CFLAGS) -c y.tab.c
> 
>y.tab.c: parse.y
>yacc -d parse.y
> 
>milter-regex.cat8: milter-regex.8
>nroff -Tascii -mandoc milter-regex.8 > milter-regex.cat8
> 
>clean:
>rm -f *.core milter-regex y.tab.* *.o *.cat8
> 
>install:
>rm -rf /usr/local/milter-regex
>mkdir -p /usr/local/milter-regex/{share/man/man8,sbin}
>cp ./milter-regex /usr/local/milter-regex/sbin
>cp milter-regex.8 milter-regex.cat8 
> /usr/local/milter-regex/share/man/man8/
> 
>uninstall:
>rm -rf /usr/local/milter-regex

Re: postfix 3.7.0 port 25 listening stops at some point (after max a few days), no error messages\

[Wietse Venema]

Gerben Wierda:
> 
> > On 4 Mar 2022, at 20:04, Bill Cole 
> >  wrote:
> > 
> > On 2022-03-04 at 06:20:27 UTC-0500 (Fri, 4 Mar 2022 12:20:27 +0100)
> > Gerben Wierda 
> > is rumored to have said:
> > 
> >> I have upgraded my postfix 3.6 to postfix 3.7.0 as well as
> >> having upgraded my macOS on which postfix runs from 10.4 (Mojave)
> >> to 12 (Monterey)

There has been no change in Postfix's event handling just about
$forever. And, no-one else is reporting that Postfix is stopping
to handle connections. From Postfix point of view, event handling
on MacOS is similar to what we did with FreeBSD 4.0 and earler.

One thing to try is to compile and run the old Postfix source version
on the new operating system. I suppose that the opposite, building
Postfix 3.7.0 on the old MacOS releasem will not be feasible.

Wietse

Re: postfix 3.7.0 port 25 listening stops at some point (after max a few days), no error messages\

[Andrew Ho]

MacOS 12 (Monterey) is the latest version. The security is pretty tight.

Mac is not a good machine for Postfix any more.


On 3/4/22 22:00, Wietse Venema wrote:

Gerben Wierda:

On 4 Mar 2022, at 20:04, Bill Cole  
wrote:

On 2022-03-04 at 06:20:27 UTC-0500 (Fri, 4 Mar 2022 12:20:27 +0100)
Gerben Wierda 
is rumored to have said:


I have upgraded my postfix 3.6 to postfix 3.7.0 as well as
having upgraded my macOS on which postfix runs from 10.4 (Mojave)
to 12 (Monterey)

There has been no change in Postfix's event handling just about
$forever. And, no-one else is reporting that Postfix is stopping
to handle connections. From Postfix point of view, event handling
on MacOS is similar to what we did with FreeBSD 4.0 and earler.

One thing to try is to compile and run the old Postfix source version
on the new operating system. I suppose that the opposite, building
Postfix 3.7.0 on the old MacOS releasem will not be feasible.

Wietse

Re: Trying to understand this DNSBL blocking issue

[Noel Jones]

I think you configure unbound with another forward-zone: name: 
“zen.spamhaus.org” and then don’t list any forwarding addresses. That should 
turn off forwarding for that zone.

A forum for your OS or for unbound will probably give an authoritative answer


  — Noel Jones

> On Mar 4, 2022, at 7:32 PM, Gerben Wierda  wrote:
> 
> I am already running my own unbound resolver.
> 
> Van I configure my unbound in such a way that it forwards everything to 
> 9.9.9.9 (which is my setting so I can use its blocking) except DNS queries 
> for spamhaus.org?
> 
> If not, I need some way to tell postfix to use another resolver than the 
> default one.
> 
> Or I must forego the use of 9.9.9.9 and lose its DNS blocking of ‘evil’ 
> hosts. 
> 
> G
> 
>> On 4 Mar 2022, at 19:57, Noel Jones  wrote:
>> 
>> 
>>> On 3/4/2022 11:58 AM, Gerben Wierda wrote:
>>> 
>>> Feb 27 06:02:19 mail postfix/dnsblog[46930]: addr 113.197.35.193 listed by 
>>> domain zen.spamhaus.org  as *127.255.255.254*
>> 
>> This query was made on 27 Feb via a public DNS nameserver that is blocked by 
>> spamhaus.
>> 
>> 
>>> Mar 04 18:44:25 mail postfix/dnsblog[88230]: addr 189.51.96.252 listed by 
>>> domain zen.spamhaus.org  as *127.0.0.4*
>> 
>> This query on 04 Mar was made via a different DNS nameserver that was not 
>> blocked by spamhaus.
>> 
>> If you're using a public DNS service, it's possible some of their back-end 
>> servers are blocked and some aren't, which will give you unpredictable 
>> results.
>> 
>> To fix, insure you either use a local DNS nameserver installed on your 
>> computer, such as unbound, or sign up for the free (for low volume) Spamhaus 
>> Data Query Service
>> 
>> 
>> 
>>  -- Noel Jones
> 

Re: Trying to understand this DNSBL blocking issue

[Viktor Dukhovni]

> On 4 Mar 2022, at 11:01 pm, Noel Jones  wrote:
> 
>  think you configure unbound with another forward-zone: name: 
> “zen.spamhaus.org” and then don’t list any forwarding addresses. That should 
> turn off forwarding for that zone.
> 
> A forum for your OS or for unbound will probably give an authoritative answer

More likely a stub-zone, but I haven't checked the docs just yet...

-- 
Viktor.