[pfx] Re: DKIM and DMARC

[Dominic Raferd via Postfix-users]

On 17/05/2023 08:18, Matus UHLAR - fantomas via Postfix-users wrote:

On 16.05.23 22:11, Tom Reed via Postfix-users wrote:

For OpenDMARC this setting:

SPFSelfValidate true

this only causes opendmarc to resolve SPF itself instead of using existing
Authentication-Results: header.
Actually (from man opendmarc.conf) it causes the filter to perform SPF 
check itself *when it can find no SPF results in the message header*.  
If SPFIgnoreResults is also set, it never looks for SPF results in 
headers and always  performs SPF check itself.

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Re: How do check DKIM and SPF on incoming email?

[Dominic Raferd]

On 16/11/2022 11:45, Matus UHLAR - fantomas wrote:

I use:
spf-milter (the same source as policyd-spf-python)
opendkim
openarc
opendmarc

so far in soft mode (no rejections)

opendmarc can use results of previous three in its decisions.
Does spf-milter have the same source as policyd-spf-python? It looks to 
me like a completely separate project, based on viaspf (both written in 
Rust). Or did you mean spf-milter-python (Debian package)?

Re: started getting 550 #5.7.1 SPF unauthorized mail

[Dominic Raferd]

On 25/08/2022 04:41, li...@sbt.net.au wrote:

I have a simple 'mail list' where an alias 'ct...@sbt.net.au' sends email
to several recipients, that's been in use since long time.

today noticed one of these addresses started bouncing with '5.7.1 SPF
unauthorized mail' since just today:

what am I doing wrong ?

worked:

Aug 23 09:27:25 geko postfix/smtp[12957]: Untrusted TLS connection
established to asav.tpg.com.au[27.32.32.10]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 23 09:27:27 geko postfix/smtp[12957]: 3119E21C52F:
to=, relay=asav.tpg.com.au[27.32.32.10]:25, delay=1.9,
delays=0.03/0/0.73/1.2, dsn=2.0.0, status=sent (250 ok:  Message 199653922
accepted)

no longer:

Aug 25 09:22:29 geko postfix/smtp[19538]: Untrusted TLS connection
established to asav.tpg.com.au[27.32.32.10]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Aug 25 09:22:30 geko postfix/smtp[19538]: 61DA820053B:
to=, relay=asav.tpg.com.au[27.32.32.10]:25, delay=1.9,
delays=0.08/0.02/0.74/1, dsn=5.0.0, status=bounced (host
asav.tpg.com.au[27.32.32.10] said: 550 #5.7.1 SPF unauthorized mail is
prohibited. (in reply to DATA command))

Aug 25 09:39:17 geko postfix/smtp[26188]: Untrusted TLS connection
established to asav.tpg.com.au[27.32.32.10]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Aug 25 09:39:18 geko postfix/smtp[26188]: 5C7FE2004D9:
to=, relay=asav.tpg.com.au[27.32.32.10]:25, delay=0.64,
delays=0.05/0.01/0.26/0.33, dsn=5.0.0, status=bounced (host
asav.tpg.com.au[27.32.32.10] said: 550 #5.7.1 SPF unauthorized mail is
prohibited. (in reply to DATA command))

looking at the log is see:

# grep 4678220053B  /var/log/maillog

Aug 25 09:38:55 geko postfix/smtpd[21733]: 4678220053B:
client=mail-me3aus01on2049.outbound.protection.outlook.com[40.107.108.49]
Aug 25 09:38:55 geko postfix/cleanup[26173]: 4678220053B:
message-id=
Aug 25 09:38:56 geko opendkim[930]: 4678220053B: failed to parse
authentication-results: header field
Aug 25 09:38:56 geko opendkim[930]: 4678220053B: DKIM verification successful
Aug 25 09:38:56 geko opendmarc[908]: 4678220053B ignoring
Authentication-Results at 1 from geko.sbt.net.au
Aug 25 09:38:56 geko opendmarc[908]: 4678220053B: SPF(mailfrom):
tld.com.au pass
Aug 25 09:38:56 geko opendmarc[908]: 4678220053B: tld.com.au none
Aug 25 09:38:56 geko postfix/qmgr[23312]: 4678220053B:
from=, size=629054, nrcpt=8 (queue active)

Aug 25 09:39:17 geko amavis[23896]: (23896-16) Passed CLEAN
{RelayedOpenRelay}, [40.107.108.49]:3695 [40.107.108.49] 
-> , Queue-ID: 4678220053B, Message-ID:
,
mail_id: ecrv8dP6h0oa, Hits: -1.712, size: 629477, queued_as: 5C7FE2004D9,
4939 ms

Aug 25 09:39:17 geko postfix/smtp[26175]: 4678220053B:
to=, orig_to=,
relay=127.0.0.1[127.0.0.1]:10024, delay=22, delays=1.2/16/0.01/4.9,
dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250
2.0.0 Ok: queued as 5C7FE2004D9)

Aug 25 09:44:04 geko postfix/qmgr[23312]: 4678220053B: removed
#


# grep 5C7FE2004D9  /var/log/maillog

Aug 25 09:39:17 geko postfix/smtpd[26177]: 5C7FE2004D9:
client=localhost[127.0.0.1]
Aug 25 09:39:17 geko postfix/cleanup[26173]: 5C7FE2004D9:
message-id=
Aug 25 09:39:17 geko postfix/qmgr[23312]: 5C7FE2004D9:
from=, size=629970, nrcpt=1 (queue active)
Aug 25 09:39:17 geko amavis[23896]: (23896-16) Passed CLEAN
{RelayedOpenRelay}, [40.107.108.49]:3695 [40.107.108.49] 
-> , Queue-ID: 4678220053B, Message-ID:
,
mail_id: ecrv8dP6h0oa, Hits: -1.712, size: 629477, queued_as: 5C7FE2004D9,
4939 ms
Aug 25 09:39:17 geko postfix/smtp[26175]: 4678220053B:
to=, orig_to=,
relay=127.0.0.1[127.0.0.1]:10024, delay=22, delays=1.2/16/0.01/4.9,
dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250
2.0.0 Ok: queued as 5C7FE2004D9)
Aug 25 09:39:18 geko postfix/smtp[26188]: 5C7FE2004D9:
to=, relay=asav.tpg.com.au[27.32.32.10]:25, delay=0.64,
delays=0.05/0.01/0.26/0.33, dsn=5.0.0, status=bounced (host
asav.tpg.com.au[27.32.32.10] said: 550 #5.7.1 SPF unauthorized mail is
prohibited. (in reply to DATA command))
Aug 25 09:39:18 geko postfix/bounce[26219]: 5C7FE2004D9: sender
non-delivery notification: 0C96B21C52C
Aug 25 09:39:18 geko postfix/qmgr[23312]: 5C7FE2004D9: removed


mail_version = 3.7.2

SPF works by checking the SPF record for the domain specified in the 
mail *envelope*. If the IP from which the email has been received does 
not meet the SPF record criteria, it is an SPF fail. My impression is 
that a number of email providers (including Gmail) have become much 
stickier about refusing emails that fail SPF testing of late, and it 
seems that tpg.com.au is one of them.


When you relay an incoming mail out to your mailing list subscribers you 
are retaining the original mail return address in the header, but the 
mail is coming from your IP, not the original sender's. For this sender 
it will result in an SPF failure because their SPF record (tld.com.au) 
at the time of writing is 'v=spf1 include:spf.protection.outlook.com -all'.


A workar

Re: dnswl.org lookup error

[Dominic Raferd]

On 08/05/2022 11:59, Byung-Hee HWANG wrote:

Dear Bastian,

Bastian Blank  writes:


Hi

On Sun, May 08, 2022 at 07:42:00PM +0900, Byung-Hee HWANG wrote:

May 8 10:24:25 bionic190316003 postfix/smtpd[10918]: warning:
17.188.51.209.list.dnswl.org: RBL lookup error: Host or domain name
not found. Name service error for name=17.188.51.209.list.dnswl.org
type=A: Host not found, try again
As shown above log, the line 'RBL lookup error' is normal? Can i ignore that?

No, this line is not normal.  It means you have an error in the DNS
resolution.  Maybe you are using a public resolver.

Thanks for quick reply Bastian!

Below is my /etc/resolv.conf:

#+begin_src text (/etc/resolv.conf in Google Compute Engine)
soyeomul@bionic190316003:~$ sudo cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0
search us-west1-b.c.elite-flow-234711.internal c.elite-flow-234711.internal 
google.internal
soyeomul@bionic190316003:~$
#+end_src

Possibly i would like to solve this problem.

Thanks!

Sincerely, Linux fan Byung-Hee

I think your system is using systemd-resolved for DNS lookups; this 
hands off the real work of resolving to public resolvers, so RBLs will 
block your lookups. This is a normal setup for a systemd-based distro 
but is not appropriate for a mail server.


First install a true local resolver such as bind9 or unbound and then 
switch your system to use it instead of systemd-resolved. To switch to 
bind9 you could try my 
https://www.timedicer.co.uk/programs/help/bind9-resolved-switch.sh.php.


[ If you want, bind9 can be set so that 'normal' lookups still go via 
external (public) resolvers (as you specify in 
/etc/bind/named.conf.options), but lookups for RBLs are routed directly. 
Perhaps unbound can do the same (I haven't tried it). ]

Re: Pre- or post-queue filter for authenticated submission

[Dominic Raferd]

On 13/04/2022 13:29, Jesper Dybdal wrote:

I use amavisd-new for the smtpd instances that receive authenticated
submission.

Are there any significant pros and cons in doing this as a pre-queue
filter (proxy) compared to doing it as a post-queue content filter?

I suspect that it doesn't really matter for a low-volume server like
mine, but I might have overlooked something.

(For unauthenticated mail from the outside, it will be a pre-queue
amavisd-milter setup.)

Thanks,
Jesper


Pro is that users know immediately that their email has been accepted 
(or not), rather than being informed afterwards.


Con is that users might experience slow submission of emails, because 
amavis (calling clamav, SA etc) may take quite a number of seconds to 
decide whether to accept the incoming email. (This should not normally 
be a problem for unauthenticated mail where delays are standard.)

Re: Best way forwarding to Gmail

[Dominic Raferd]

On 06/04/2022 18:09, John Levine wrote:

In my experience, forwarding to Gmail is an exercise in futility. I
got lots of DMARC rejections of entirely legitimate mail that was only
authenticated with SPF but had a strict DMARC policy, so Gmail rejected it.

I too see this, but rarely. relay-enforcer deals with it by encapsulation.

Re: AW: Best way forwarding to Gmail

[Dominic Raferd]

On 06/04/2022 13:26, Byung-Hee HWANG wrote:

"Ludi Cree"  writes:


(...thanks...)
My advice is not to forward to GMail if you can not exclude spam.

   ^
This is a worthwhile answer for me, thanks!


Agreed that first you must be rigorous and excluding spam (and worse); 
then see my script:

https://www.timedicer.co.uk/programs/help/relay-enforcer.sh.php

Re: postfix+amavis

[Dominic Raferd]

  
  
On 30/03/2022 15:14, natan wrote:


  Hi
It is probably not for this group, but... Maybe someone has such a 
solution and can suggest?

I have vuser and vdomain and my working environment (general scheme) :
postfix+haproxy(external 2 x amavis) ...

Spamassassin works fine with inwidual score (in mysql) but Amavis will 
overwrite the score with the value it has in amavid.conf

is there any method to prevent amavis from doing this (maby alternate 
for amavis) ?

amavis should not generally alter SA scores - see
  https://www.ijs.si/software/amavisd/#faq-spam.
  

Re: milter_header_checks, pcre, chroot

[Dominic Raferd]

On 22/03/2022 16:40, Benny Pedersen wrote:

OpenDMARC's internal SPF handling will be removed
 in a future version.


Modern versions of openDMARC can and should be built with dependency on 
libspf2, so would never use the very old internal spf code, and instead 
use libspf2 'under the hood' when set to do spf itself.  To test for this:


ldd $(command -v opendmarc)|grep libspf2

I have found it very reliable, and it plays nicely with opendkim.

Re: Trying to understand this DNSBL blocking issue

[Dominic Raferd]

On 05/03/2022 19:26, Gerben Wierda wrote:

On 5 Mar 2022, at 18:23, Matus UHLAR - fantomas  wrote:

On 05.03.22 12:43, Gerben Wierda wrote:

A forward zone without a forward address gives SERVFAIL

But I was able to use

forward-zone:
name: "spamhaus.org"
forward-addr: 127.0.0.1@1053 # do not resolve spamhaus via public DNS 
resolvers

Because I have a second non-forwarding unbound running on port 1053 for rspamd 
already (which has more or less the same issue, but which — unlike postfix — 
can be told to use a different name server itself)

so, you have multiple SW installed that have problems with forwarding DNS, but 
you insist on forwarding DNS?

Yes, because forwarding to quad9 (9.9.9.9) has advantages in that it will not 
resolve known bad actors. This adds to the protection my users who use my DNS 
resolver. The two who are having problems (postfix - DNSBL, and rspamd) are 
exceptions to the rule. rspamd can be configured to use a different resolver 
than the default resolver, postfix can’t.

For anyone who uses bind as their local resolver, this is a simplified 
forwarding setup (file /etc/bind/named.conf.options):


options {
    directory "/var/cache/bind";
    // forwarding to Cloudflare and Quad9, alter per your preferences
    forwarders { 1.1.1.1; 9.9.9.9; };
};
// Disable forwarding for DNSBL queries
zone "zen.spamhaus.org" { type forward; forwarders {}; };
// add further DNSBL zones to taste...

Re: smtp; 552 5.3.4 Message size exceeds fixed limit

[Dominic Raferd]

On 09/02/2022 16:53, Gary Aitken wrote:

Just got the message
  smtp; 552 5.3.4 Message size exceeds fixed limit
when attempting to receive a 7MB file:

$ postconf -d | grep size_limit
body_checks_size_limit = 51200
bounce_size_limit = 5
header_size_limit = 102400
mailbox_size_limit = 5120
message_size_limit = 1024

$ postconf -n | grep size_limit
mailbox_size_limit = 0

$ grep mailbox_size_limit *.cf
main.cf:mailbox_size_limit = 0

log:
NOQUEUE: reject: MAIL from mail-pf1-.google.com[xxx.xxx.xxx.xxx]: 
552 5.3.4 Message size exceeds fixed limit; from= 
proto=ESMTP helo=
Feb  8 17:30:25 my-system postfix/smtpd[28640]: > 
mail-pf1-.google.com[209.85.210.180]: 552 5.3.4 Message size 
exceeds fixed limit


It appears the:
   actual mailbox_size_limit is unlimited
   actual message_size_limit is 10,240,000
 which is > 7MB

What am I missing, thoughts on how to fix?
Is your attachment file exactly 7MB or a bit bigger? Encoding as Base64 
(to attach to an email) increases its size by c.37%. 
1024/1.37=7.13MB. Any attachment bigger than this will hit your 
message_size_limit.

Re: multi instance and always_bcc

[Dominic Raferd]

My understanding is that always_bcc does not work:
- if receive_override_options includes no_address_mappings; or
- after Postfix has forwarded mail internally; or
- for mails generated by Postfix itself

On 10/01/2022 16:28, Zsombor B wrote:

We'd like to debug some emails sent through a multi instance withouth
having any impact on the mail flow so I have added
always_bcc=de...@whatever.com to the main.cf of that instance and
reloaded it.

But instead of sending copies of the emails to the debug address,
postfix relays both the original and the bcc emails to the relayhost of
the multi instance as well.

This is postfix v3.2.10 on a SLES 12 SP5 server.

Is this the expected behaviour?

Re: email from servers claiming to be ours

[Dominic Raferd]

On 16/11/2021 22:55, Ruben Safir wrote:

I got an email from cpa...@mrbrklyn.com which is not from
us, as we are mrbrklyn.com

How do I block email with this on the From line

 From cpa...@mrbrklyn.com  Tue Nov 16 03:59:34 2021
Return-Path: 
X-Original-To: ru...@mrbrklyn.com
Delivered-To: ru...@mrbrklyn.com
Received: from bizcloud-linmaxtone.de (unknown [167.172.106.8])
by mrbrklyn.com (Postfix) with ESMTP id 495F2163FD5
for ; Tue, 16 Nov 2021 03:59:34 -0500 (EST)
Received: from cragsmoorfreelibrary.info (bizcloud-linmaxtone.de
[IPv6:::1])
by bizcloud-linmaxtone.de (Postfix) with ESMTP id
8AED332FAE0
for ; Tue, 16 Nov 2021
8:29:50 + (UTC)
From: "cPanel on mrbrklyn.com" 


Use
- check_sender_access to block mails that fake your domain in the 
envelope sender; and

- header_checks to block mails that fake your domain in the From: header

Both of the above should be applied only to non-authenticated and 
non-local emails. Something like this (assumes you block authenticated 
emails on port 25):


In master.cf:

smtpd pass  -   -   n   -   -   smtpd
  -o smtpd_recipient_restrictions=$smtpd_recipient_restrictions_wild
  -o cleanup_service_name=cleanup_wild
...

cleanup_wild unix  n   - n   -   0   cleanup
  -o header_checks=pcre:/etc/postfix/check_header_wild.pcre
  -o mime_header_checks=pcre:/etc/postfix/check_header_wild.pcre
  -o nested_header_checks=
...

In main.cf:

smtpd_recipient_restrictions_wild =
  ...
  check_sender_access hash:/etc/postfix/sender_access
  ...

In /etc/postfix/sender_access:

mydomain.tld REJECT privileged domain without authentication

In /etc/postfix/check_header_wild.pcre:

if /^From:/
/mydomain\.tld>?\s*$/ REJECT From header (impersonation domain in address)
fi

For homework, catch attempts to fake your domain in the text part of the 
From: header:
- more sophisticated catches in check_header_wild.pcre (these will 
require exceptions for 'legitimate' fakes)
- because postfix does not translate UTF, add some other 
filtration/scoring such as bespoke rules in spamassassin

Re: domain email handled by postfix

[Dominic Raferd]

On 12/11/2021 04:53, Walt Pang wrote:
How to set up postfix to forward all my domain's email to gmail, and 
enable authentication for SMTP outgoing messages?
The good news is that we have had this working for our own domains for 
years. The bad news is that I don't have the time to explain our 
somewhat involved setup here, sorry. Maybe someone else can?

Re: method to discard email with body containing gmail address

[Dominic Raferd]

On 08/11/2021 08:43, Ansgar Wiechers wrote:

On 2021-11-06 Wietse Venema wrote:

li...@lazygranch.com:

Reply-To: jm84450...@gmail.com

Use header_checks (not body_checks) if you want to block that.
Still, I would be concerned about rejecting legitimate email.

It's true that this can reject legitimate e-mail. However, the abuse of
Gmail Reply-To addresses by spammers/scammers is so rampant (at least in
my experience) that on my personal mail server I decided to reject
everything with a Gmail Reply-To except for whitelisted addresses.
Thanks for raising this. I tested how it might have worked for us, going 
back 9 months. We see this abuse, but all attempts over that period have 
been blocked by our existing spam-prevention tools. Whitelisting a 
handful of 'From:' addresses could have avoided false positives 
(applying hindsight), but - for us at least - the strategy would appear 
to add nothing except a risk of future fps. YMMV, of course.

Re: Rewrite subject for unauth messages only

[Dominic Raferd]

On 05/11/2021 10:20, Gionatan Danti wrote:

Il 2021-11-05 09:36 Dominic Raferd ha scritto:

Why permit auth connections on port 25? Restrict them to 587 and/or
465 then you can specify subject rewriting for (all) mails arriving
via port 25.  (And you can use postscreen on port 25.)

Yeah, it would be a very clean solution. However, we have many smtp
client already configured to authenticate on port 25 and so I can not
blindly use the connection port to identify to-be-tagged messages.


Presumably you are not concerned that rewriting subjects will break
DKIM/DMARC?

No, it is not an issue at the moment. But thanks to advice, it should be
considered a significant issue indeed. Let only say I am *strongly*
against this subject rewrite and/or disclaimer adding policy, and I hope
management recognizes they are useless to avoid phishing...


If you have the option, better to use pcre: than regex:.

Sure, regexp was only for a quick test.

Today I was able to get it working - hopefully correctly - in a test
environment. I edited my configuration files as following:

# main.cf
# auth client are immediately permitted, all other messages are FILTERed
smtpd_client_restrictions = permit_sasl_authenticated,
check_client_access regexp:/etc/postfix/custom

# master.cf
# secondary smtpd and cleanup process
# disable milters to avoid double spam check
127.0.0.1:10025inet  n   -   n   -   -   smtpd
-o smtpd_client_restrictions=
-o smtpd_milters=
-o cleanup_service_name=mycleanup
mycleanup unix  n   -   n   -   0   cleanup
-o header_checks=regexp:/etc/postfix/rewrite

# custom
# all unauth messages are FILTERed
/.*/FILTER smtp:127.0.0.1:10025

# rewrite
# only add tag if it is not already present
if !/^Subject: .*[EXTERNAL].*/i
/^Subject: (.+)$/i REPLACE Subject: [EXTERNAL] $1
endif

Do you see some grossly wrong config?
Regards.


I think you need to ensure that the rule runs only for Subject: headers, 
escape square brackets in the if clause, and cover the possibility of no 
space after 'Subject:' (note: all untested):


if /^Subject:/i
if !/^Subject: \[EXTERNAL\]/i
/^Subject: ?(.+)/i REPLACE Subject: [EXTERNAL] $1
endif
endif

Re: Rewrite subject for unauth messages only

[Dominic Raferd]

On 04/11/2021 21:51, Gionatan Danti wrote:

Dear all,
I was tasked to mark all messages coming from unauthenticated clients
(ie: incoming emails) with a specific subject line.

While subject rewrite is trivial per-se (via header_checks), I am having
big issues rewriting only selected messages. I fully understand that
header_checks only works with single lines, and so I can not set a
if/endif block between multiple lines/conditions.

I was trying to achieve the desired behavior by using two postfix
processes: the first FILTERing external messages, tunneling them to the
second postfix instance to rewrite the subject line. Something as:
- receive all mails on port 25 by the main smtpd process;
- set "smtpd_sender_access=check_sender_access
regexp:/etc/postfix/custom, permit_sasl_authenticated,
permit_mynetworks, reject"
- set /etc/postfix/custom to FILTER non-local emails to another smtpd
process - FILTER custom:localhost:10025
- for the second smtpd process, relax smtpd_sender_access but enable
subject rewrite -
smtpd_sender_access=regexp:/etc/postfix/rewrite_headers

...but it does not work. I have some issues grasping how to configure
the second postfix process via master.cf. I tried something as:
localhost:10025  inet  n   -   n   -   -   smtpd
-o smtpd_sender_access=regexp:/etc/postfix/rewrite_headers
but withtout success.

I already read http://www.postfix.org/FILTER_README.html and
http://www.postfix.org/SMTPD_PROXY_README.html, but I am not sure how to
proceed further.

So I would ask if what I am trying to do is at all possible with plain
postfix (ie: without mimedefang or similar milter, as I am already using
rspamd for spam filtering) and, if so, how to configure master.cf and
the FILTER rule.

Thanks.

Why permit auth connections on port 25? Restrict them to 587 and/or 465 
then you can specify subject rewriting for (all) mails arriving via port 
25.  (And you can use postscreen on port 25.)


Presumably you are not concerned that rewriting subjects will break 
DKIM/DMARC?


If you have the option, better to use pcre: than regex:.

Re: delete from hold queue

[Dominic Raferd]

On 29/10/2021 05:24, Viktor Dukhovni wrote:

On Thu, Oct 28, 2021 at 10:14:15PM -0400, Viktor Dukhovni wrote:


 postqueue -j | jq -nr --argjson $days '

Correction, that first line should be:

   postqueue -j | jq -nr --argjson days $days '

Setting the "jq" variabe "$days" to the shell variable "$days".

The rest is unchanged:


   (now - 86400 * $days) as $too_old
 | inputs
 | select(.queue_name == "hold" and .arrival_time  < $too_old)
 | .queue_id
 | select(test("^\\w+$")) # permit only valid queue-id syntax
 ' |
 postsuper -d - hold
Always great to learn from a master! I had not used postqueue -j, json 
or jq until yesterday...

Re: delete from hold queue

[Dominic Raferd]

I attach a script that can do it.

On 28/10/2021 11:56, richard lucassen wrote:

On Thu, 28 Oct 2021 12:26:31 +0200
Matus UHLAR - fantomas  wrote:


Why do you have _any_ messages in the hold queue?  Don't do that!

kind of quarantine I guess.

Yep. Most of these messages are bank phishing mails BTW, I delete the
hold queue once a day. But never mind, was just wondering if anybody
had written such a script.
#!/bin/bash
# hold_deleter.sh v0.1 by Dominic Raferd  [28 Oct 2021]
find_program() {
command -v "$1" || { echo "Cannot locate $1 program; aborted" >&2; exit 
1; }
}

# help
[[ -z $1 || $1 == "-h" || $1 == "--help" ]] && { echo -e "Usage: 
hold_deleter.sh DATETIME\nSpecify parameter 1 as a datetime (as understood by 
command 'date -d'); mails still in the postfix hold queue, and which entered it 
before then, will be deleted\nExample: ./hold_deleter.sh '-2 days'"; exit 0; }

# check dependencies
JQ="$(find_program jq)"
POSTQUEUE="$(find_program postqueue)"
POSTSUPER="$(find_program postsuper)"

# convert datetime to epoch style
BEFORE="$(date +%s -d"$1" 2>/dev/null)"
[[ $BEFORE =~ ^[1-9][0-9]+$ ]] || { echo "Error converting date/time; aborted" 
>&2; exit 1; }

# obtain QIDs, if any
QIDS=( $("$POSTQUEUE" -j|grep -F '"queue_name": "hold"'|"$JQ" '.arrival_time, 
.queue_id'|sed 'N;s/\n//;s/"/,/g'|awk -F, -v BEFORE="$BEFORE" '{if ($1&2
exit 1

Re: SSL_accept error from unknown

[Dominic Raferd]

On 19/10/2021 05:59, Maurizio Caloro wrote:

see today logs "SSL_accept Error", please its this a known issue?
installed Postfix 3.4.14, Openssl 1.1.1d, Debian 10.11.

Oct 19 05:59:18 nmail postfix/smtps/smtpd[32720]: SSL_accept error 
from 232.115.xx.xx.static.ip.windstream.net[40.138.xx.xx]: lost 
connection
Oct 19 06:45:31 nmail postfix/smtps/smtpd[688]: SSL_accept error from 
unknown[192.x.x.x]: -1
Oct 19 06:45:31 nmail postfix/smtps/smtpd[688]: warning: TLS library 
problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version 
number:../ssl/record/ssl3_record.c:332
Yes these are common on our mailservers too, I think they are caused by 
bad SSL/TLS on the sending host (most likely a spammer or hunting for 
SSL/TLS vulnerabilities).

Re: bizarre warning from postfix received

[Dominic Raferd]

On 25/08/2021 04:01, Jean-François Bachelet wrote:

Hello ^^)


In the today's report I've got from PFLogsumm about the Postfix 
activity from yesterday I have a warning that I see here :



Aug 24 19:48:55 servername postfix/postfix-script[1187]: warning: 
/var/spool/postfix/etc/ssl/certs/ca-certificates.crt and 
/etc/ssl/certs/ca-certificates.crt differ



first, what is surprising (to me) is that there is a copy of 
etc/ssl/certs/ca-certificates.crt contents in /var/spool/postfix/ssl ???


isn't /var/spool/postfix  for spooling mails ? so why finding 
configuration stuff there ? (ssl/cert, hosts, host.conf, localtime, 
nsswitch.conf, passwd, resolv.conf, services)



then that the ca-certificates.crt are different between the two places...


btw, if this is wanted, why the two cert files aren't in sync and why 
I don't get a warning each day with the report while the two cert 
files are out of sync since august 21 as I can see by the dates of the 
files ???



I've upgraded my server from buster to bullseye on august, 21, is it a 
side effect ?


You are running postfix chrooted, or you previously ran it chrooted and 
have not cleaned out the old chrooted files. If/when you are no longer 
running any postfix processes chrooted, you can remove a lot of cruft 
from /var/spool/postfix - including /var/spool/postfix/ssl.


This may be caused by a change in default behaviour: postfix <3.0.0 ran 
processes chrooted by default (i.e. where chroot entry in master.cf was 
set to '-'), this changed to non-chrooted by default for postfix >=3.0.0.

Re: Modifying subject for emails from external senders

[Dominic Raferd]

On 23/08/2021 14:02, Jens Hoffrichter wrote:

Hi,

I cannot find a previous discussion about this topic here on the mailing list.

We are running postfix instances for a big corporation, which delivers
to MS Exchange / Exchange online backends. We now have gotten the
requirement to mark all e-mails coming from external senders to mark
in the subjects.

I'm quite clear how to implement this, we have the infrastructure in place.

I'm looking more for some experiences and pros/cons for doing this in
postfix, or in Exchange. It will come nevertheless, I'm just looking
to minimize damage and impact for the end user, and where to do this
best.

Has anyone doing this experienced problems with S/MIME mail? Does this
maybe trigger spam detection, especially on an Exchange / Exchange
Online backend more? Does DKIM break?

It is likely to break DKIM where the Subject header  is signed (which is 
normal - and suggested by RFC6376 5.4). It will occasionally break DMARC 
(where sender has not also setup SPF correctly or has not aligned it), 
and such instances although rare could be serious (i.e. if sender's 
domain specifies p=reject).


If you are confident that neither the Exchange backends, nor any of the 
recipients' own software will be testing DMARC or DKIM after you have 
mangled the subjects, and you have ensured that mangling comes after 
DKIM/DMARC testing (if any) within your postfix instances, I guess it 
might work, but it's ugly IMO.


A possible workaround: rather than modify the existing Subject header, 
insert a new Subject header above it. Unless sender has oversigned for 
the Subject header (which is not normal), DKIM (and therefore DMARC) 
will still pass (I think) because DKIM tests against the first 
chronologically (i.e. last physically) such header, yet your header 
might be shown in the recipient's mail program as the Subject in place 
of the original one. This would need to be tested and TBH I hope it 
doesn't work.

Re: Question on DKIM signature

[Dominic Raferd]

On 16/08/2021 10:21, Ken N wrote:

I was reading this blog posting:
https://www.alexblackie.com/articles/email-authenticity-dkim-spf-dmarc/

But I am confused that, what content should DKIM signature for?
The message body or headers? what headers should be signed?


The body is always included for signing. For headers: if you want the 
technical answer look at RFC6376, Section 5.4. If you use opendkim you 
don't need to worry; by default it signs based on the RFC's suggested 
headers (and the body), though for safety you should also set 
'OversignHeaders From'.


Signing for more headers than suggested in the RFC may seem 'safer' but 
is more likely to cause FPs because the other headers can be changed 
legitimately by a relaying mail server.


And, in my opinion, using DKIM without DMARC is of limited value.

Re: Best current practice to analyze brute force login attempts?

[Dominic Raferd]

On 30/07/2021 18:05, Wietse Venema wrote:

Hadmut Danisch:

Hi,

we are experiencing permanent high traffic from numerous sites trying to
smtp auth to our postfix node, obviously trying to brute force password
dictionaries against mail address lists probably taken from spam lists
(including lots of oder message ids with the same syntax as mail
addresses).

For some reason beyond the common noise we need to do some deeper
analysis about who is trying which user account from where.

Unfortunately, the required data, i.e. client IP address and username
are distributed in different log files. The IP address is written to
postfix's log, while the username is in saslauthd's log in case of
failure, with the time stamp as the only link between both.

The Postfix 'disconnect' summary shows failed AUTH attempts without
the login name. Just block any SMTP client that has too many AUTH
failures, for example for 1 hour.

 postfix/smtpd[xxx]: disconnect from unknown[x.x.x.x] auth=0/1 commands=0/1

Anything that has auth=0 is suspect. There may be more commands
in the 'disconnect' summary.
Recent versions of fail2ban pick up such entries using postfix jail, 
mode = aggressive

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Dominic Raferd]

On 29/07/2021 17:24, Josh Good wrote:

On 2021 Jul 29, 10:01, Viktor Dukhovni wrote:

On 29 Jul 2021, at 8:17 am, raf  wrote:

The Rhenus email did say:

  "...must be sent with the TLS 1.2 protocol or higher.
  Any mail received without fulfilling this condition
  will be rejected by our server."

That second sentence sounds to me like a definite
statement that an SMTP connection that doesn't initiate
STARTTLS will not be able to send email. At least, I
can't see how else to interpret those words.

The simplest thing they could do is just disable TLS 1.0.
This would also comply with some brain in neutral audit.

My money is on brain in neutral, as opposed to a carefully
considered risk assessment in which they've concluded that
they only receive legitimate email from TLS-1.2-capable
senders.

Well, there is also the third option, the kamikaze approach: we're
disabling TLS 1.0, and while we are at it we will also disable this
"backdoor" we just found of "plain text" connections to our world-facing
SMTP servers... Risk assessments?, what are those? This is security!
Some commercial vulnerability scan services (e.g. by Qualys, 
SecurityMetrics) which are required by payment providers regard 
TLSv1/TLSv1.1 as absolute fails for PCI DSS compliance and organisations 
that must meet PCI DSS (https://www.pcisecuritystandards.org/) have no 
choice but to respect this. The same services do not treat port 25 open 
for plain text as a fail.

Re: Conditional milter_header_checks?

[Dominic Raferd]

On 14/07/2021 08:43, raf wrote:

On Wed, Jul 14, 2021 at 02:38:00PM +1000, raf  wrote:


On Tue, Jul 13, 2021 at 06:06:16PM -0400, post...@ptld.com wrote:

Viktor wrote:


That's because DMARC (which I don't use or recommed)

Why don't you recommend DMARC? What is wrong with it? Do you accept *ALL*
mail sent to you in your inbox spam or not? Other than SPF records and DMARC
what other tools exist to verify if mail came from the domain they purport
to?

Here's a (silly) thing that wrong with DMARC: :-)

I've sent two messages to this mailing list so far, and
I've received 52 DMARC forensic/failure report emails
as a result! :-)

I suppose that means that lots of list members have DMARC
checking set up.

But seriously, I'd also appreciate a critique of DMARC.
It seems like a reasonable attempt to solve some of the
flaws with SPF and DKIM. If it fails to do that, or it
has flaws of its own, I'd be interested in hearing
about it.

For what it's worth, anyone on these lists with SPF
might want to add these to their SPF record:

   ip4:168.100.1.3
   ip4:168.100.1.4
   ip4:168.100.1.7
   ip6:2604:8d00:0:1::3
   ip6:2604:8d00:0:1::4
   ip6:2604:8d00:0:1::7

It would be good if mailing lists published spf records
that members could include: in their spf records. But I
suppose most people wouldn't be able to benefit from
them.


We use DMARC for our main business domains (via opendmarc and opendkim) 
and I am a fan. The main problems with DMARC are that it has to be set 
up and tested carefully before setting p=reject, and that it is broken 
by many mailing lists (though not, I thought, this one). ARC, a 
development from DMARC, is meant to provide a way round the second 
problem - I have not tried it.


This is a mailing list so naturally many subscribers don't like DMARC!

A commonly-held view is that DMARC is only worthwhile for transactional 
emails - for instance it is now used by most responsible financial 
institutions. But, even though we are not such, I hate the idea that 
anyone can easily send emails that perfectly fake our identity. DMARC 
addresses this - maybe DANE does too?

Re: www.postfix.org site appears to be down.

[Dominic Raferd]

On 03/07/2021 07:48, @lbutlr wrote:

When going to https://www.postfix.org I get, after an invalid certificate 
error,...


The correct address is http://www.postfix.org (no https...)

Re: spamass.sock - No such file or directory

[Dominic Raferd]

Remove the slash after unix:

On Sat, 26 Jun 2021, 08:38 ,  wrote:

> Run with Debian 10
>
> I dont see why “spamass.sock: No such file or directory” this message
> appair
>
>
>
> >mail.log
>
> Jun 26 09:27:12 nmail postfix/smtps/smtpd[9509]: warning: connect to
> Milter service unix:/spamass/spamass.sock: No such file or directory
>
>
>
> >main.cf
>
> smtpd_milters = unix:/spamass/spamass.sock, unix:opendkim/opendkim.sock,
> unix:opendmarc/opendmarc.sock
>
>
>
> >/run/spamass# ls -la
>
> -rw-r--r--  1 spamass-milter spamass-milter 5 Jun 26 09:26
> spamass.pid
>
> srw-rw  1   postfix  postfix 0 Jun
> 26 09:26 spamass.sock
>
> or
>
> srw-rw  1   spamass-milter spamass-milter 0 Jun 26 09:26
> spamass.sock
>
>
>
> >/etc/group
>
> spamass-milter:x:128:postfix
>
>
>
> thanks for any help
>
> Mauri
>

Re: REDIRECT overrides always_bcc

[Dominic Raferd]

On 20/04/2021 10:04, Matus UHLAR - fantomas wrote:

On 2021-04-16 12:03, Dominic Raferd wrote:
> I have started using a REDIRECT action in a header_checks table
> which works but seems to prevent always_bcc from operating -
> the email is not bcc'd.



On Fri, 16 Apr 2021, 20:07 Rob McGee,  wrote:

It's ugly, but a possible workaround: REDIRECT to an address which
runs a script (transport_maps entry to a pipe(8) or to a local(8)
address with a ~/.forward), and the script delivers a copy to your
BCC address by some means.


On 19.04.21 21:47, Dominic Raferd wrote:

Thanks for this suggestion, I might well implement it


which reminds me, I have simply added the address in always_bcc to an 
alias

where such mail is redirected.


Rather late I have tried this and it works perfectly - thanks.

Re: Unable to get Postfix to respond on port 465

[Dominic Raferd]

On 14/06/2021 15:51, Linda Pagillo wrote:
Thanks everyone. I'm still at a loss here. I have tried everything you 
guys have suggested and it's also not a firewall issue so at this 
point I have no idea why I can't get this to work. Currently I have 
the following in my master.cf  for port 465...



If you have not already done so, try getting your server working with 
STARTTLS on port 587, something like:


587    inet  n   -   n   -   -   smtpd
  -o smtpd_tls_security_level=encrypt
  -o syslog_name=postfix/submission
  -o smtpd_sasl_auth_enable=yes

Re: strange characters in log

[Dominic Raferd]

On 24/05/2021 11:01, Benny Pedersen wrote:

On 2021-05-24 11:47, Dominic Raferd wrote:

On 24/05/2021 10:33, Benny Pedersen wrote:

On 2021-05-24 08:02, Dominic Raferd wrote:

On 24/05/2021 02:10, Jim Popovitch wrote:

On Mon, 2021-05-24 at 03:00 +0200, Fourhundred Thecat wrote:

I see following lines in my log (pasted below). What do these
errors
mean? Is somebody sending garbage characters to my server?

Same here


May 24 00:25:11 mx2 postfix/trivial-rewrite[13453]: warning:
midna_domain_to_ascii_create: Problem translating domain
"اختبار-
القبول-العالمي.شبكة" to ASCII form:
UIDNA_ERROR_DISALLOWED

+1. I added a new line to my fail2ban postfix jail to catch this
event
(based on the succeeding smtpd log entry):

mdre-normal=...
     ^warning: Illegal address syntax from [^[]*\[\] in MAIL
command:

symtom solving, is postconf -nf hard ?

i like to know if smtputf8 is enabled or not

is glibc support iconv, is idn supported on the host ?, it imho a
build
error not a postfix error

other then that i just like to know more

since you ask:

# postconf -nf|grep utf

strict_smtputf8 = yes

Standard postfix 3.4.13 build on Debian (Ubuntu 20.04). My glibc is
Ubuntu GLIBC 2.31-0ubuntu9.3, I don't know how to test for its iconv
support. Never had such log message before this weekend; I assume the
cause was malign.


my own "postconf -d | grep utf"

smtputf8_autodetect_classes = sendmail, verify
smtputf8_enable = no
strict_smtputf8 = no

unless ubuntu have backports on glibc its unstable

https://packages.gentoo.org/packages/sys-libs/glibc

i have postfix 3.6

# postconf -d|grep utf
smtputf8_autodetect_classes = sendmail, verify
smtputf8_enable = ${{$compatibility_level} < {1} ? {no} : {yes}}
strict_smtputf8 = no

and I set:
# postconf -nf compatibility_level
compatibility_level = 3

Re: strange characters in log

[Dominic Raferd]

On 24/05/2021 10:33, Benny Pedersen wrote:

On 2021-05-24 08:02, Dominic Raferd wrote:

On 24/05/2021 02:10, Jim Popovitch wrote:

On Mon, 2021-05-24 at 03:00 +0200, Fourhundred Thecat wrote:

I see following lines in my log (pasted below). What do these errors
mean? Is somebody sending garbage characters to my server?

Same here


May 24 00:25:11 mx2 postfix/trivial-rewrite[13453]: warning:
midna_domain_to_ascii_create: Problem translating domain
"اختبار-
القبول-العالمي.شبكة" to ASCII form:
UIDNA_ERROR_DISALLOWED

+1. I added a new line to my fail2ban postfix jail to catch this event
(based on the succeeding smtpd log entry):

mdre-normal=...
    ^warning: Illegal address syntax from [^[]*\[\] in MAIL
command:

symtom solving, is postconf -nf hard ?

i like to know if smtputf8 is enabled or not

is glibc support iconv, is idn supported on the host ?, it imho a build
error not a postfix error

other then that i just like to know more


since you ask:

# postconf -nf|grep utf

strict_smtputf8 = yes

Standard postfix 3.4.13 build on Debian (Ubuntu 20.04). My glibc is 
Ubuntu GLIBC 2.31-0ubuntu9.3, I don't know how to test for its iconv 
support. Never had such log message before this weekend; I assume the 
cause was malign.

Re: strange characters in log

[Dominic Raferd]

On 24/05/2021 02:10, Jim Popovitch wrote:

On Mon, 2021-05-24 at 03:00 +0200, Fourhundred Thecat wrote:

I see following lines in my log (pasted below). What do these errors
mean? Is somebody sending garbage characters to my server?

Same here


May 24 00:25:11 mx2 postfix/trivial-rewrite[13453]: warning:
midna_domain_to_ascii_create: Problem translating domain "اختبار-
القبول-العالمي.شبكة" to ASCII form:
UIDNA_ERROR_DISALLOWED


+1. I added a new line to my fail2ban postfix jail to catch this event 
(based on the succeeding smtpd log entry):


mdre-normal=...
   ^warning: Illegal address syntax from [^[]*\[\] in MAIL command:

Re: Block auth senders using other domains

[Dominic Raferd]

On 13/05/2021 16:12, Matus UHLAR - fantomas wrote:

On 13.05.21 12:12, Dominic Raferd wrote:

But it doesn't stop them sending from a different domain that is not
listed in my virtual_alias_domains, such as f...@gmail.com. Currently
I stop this with my own check_sender_access file (in an smtpd
restriction list applied only to auth emails) that DUNNOs my domains
and then REJECTs all others.

I feel there is (or ought to be) a way of achieving this that does not
require creating a bespoke file/entry. I see
'reject_unknown_sender_domain' but it does not match my use case, and
I cannot use 'reject_sender_login_mismatch' because some users need to
be able to send from >1 name (all @mydomain) but using 1 login. I
think I want 'reject_unlisted_sender_domain' (which does not exist).

On 13/05/2021 12:26, Matus UHLAR - fantomas wrote:

you can allow logins/senders with smtpd_sender_login_maps and after that
disable sender - only what you allow as sender will be accepted.

On 13.05.21 13:00, Dominic Raferd wrote:

Thanks but won't that have the same problem as
'reject_sender_login_mismatch'? I need to allow them to send from any
'legit' name@mydomain (not just their login name) but not from any
name@wilddomain.

Oh yes, sorry.

you can use check_sender_access and list wildcards in allowed from domains.

Note that all of these apply for (envelope) mail from:, not header From:

You probably could check headers with header_checks but that one could be
cheated e.g. using multiple From: headers or tricking From: to look like
having multiple address

And, of course, is applicable for all mail received by the same means e.g.
on submission/smtps port.
Understood. Good thinking but yes I cover this in my existing setup. I 
was thinking there must be a simpler way but no worries...

Re: Block auth senders using other domains

[Dominic Raferd]

On 13/05/2021 12:26, Matus UHLAR - fantomas wrote:

On 13.05.21 12:12, Dominic Raferd wrote:

But it doesn't stop them sending from a different domain that is not
listed in my virtual_alias_domains, such as f...@gmail.com. Currently
I stop this with my own check_sender_access file (in an smtpd
restriction list applied only to auth emails) that DUNNOs my domains
and then REJECTs all others.

I feel there is (or ought to be) a way of achieving this that does not
require creating a bespoke file/entry. I see
'reject_unknown_sender_domain' but it does not match my use case, and
I cannot use 'reject_sender_login_mismatch' because some users need to
be able to send from >1 name (all @mydomain) but using 1 login. I
think I want 'reject_unlisted_sender_domain' (which does not exist).

you can allow logins/senders with smtpd_sender_login_maps and after that
disable sender - only what you allow as sender will be accepted.
Thanks but won't that have the same problem as 
'reject_sender_login_mismatch'? I need to allow them to send from any 
'legit' name@mydomain (not just their login name) but not from any 
name@wilddomain.

Block auth senders using other domains

[Dominic Raferd]

My domains are listed in virtual_alias_domains and my legit 
senders/recipients in virtual_alias_maps.


I recently discovered the 'reject_unlisted_sender' option which 
successfully prevents (auth) senders from sending from an unknown 
name@mydomain. For instance f...@timedicer.co.uk is blocked as a sender. 
This is much simpler than my previous approach to this problem.


But it doesn't stop them sending from a different domain that is not 
listed in my virtual_alias_domains, such as f...@gmail.com. Currently I 
stop this with my own check_sender_access file (in an smtpd restriction 
list applied only to auth emails) that DUNNOs my domains and then 
REJECTs all others.


I feel there is (or ought to be) a way of achieving this that does not 
require creating a bespoke file/entry. I see 
'reject_unknown_sender_domain' but it does not match my use case, and I 
cannot use 'reject_sender_login_mismatch' because some users need to be 
able to send from >1 name (all @mydomain) but using 1 login. I think I 
want 'reject_unlisted_sender_domain' (which does not exist).


Am I missing something?

Re: SPF/DMARC modified by host en route

[Dominic Raferd]

On 26/04/2021 13:31, Jeff Abrahamson wrote:

On 26/04/2021 12:56, Dominic Raferd wrote:

On 26/04/2021 10:16, Jeff Abrahamson wrote:

I'm seeing a disturbing (but minority) number of hosts that class our
mail is spam.  After some digging, I've found an interesting test
case.  What I'm uncertain of is if this represents a config error on
our side or a (grossly) misbehaving mail host elsewhere.

The interesting test case is a correspondent with a private domain
(per...@example.com) and a gmail address (per...@gmail.com), both of
which deliver to his gmail address.  That is, MX for example.com
points to mx01.1and1.fr but the mail is still delivered to
per...@gmail.com.

When I mail to per...@gmail.com, he receives the mail fine, and gmail
reports that SPF, DKIM, and DMARC all pass.
When I mail to per...@example.com, he receives the mail classed as
spam, gmail reports that SPF is neutral, DMARC fails (and DKIM passes).

Now what's odd is that gmail reports that SPF passes with the IP of
my MX, but in the other case that it fails with the address of
mout.kundenserver.de.  We've confirmed that mout.kundernserver.de
handles mail to him via 1and1.fr, but not what could be causing an
issue.

Mangling headers so badly to cause SPF/DMARC failures seems so
egregious that I'm inclined to think it's somehow our fault.

(Note: this is about mail for mobilitains.fr and not p27.eu.)


When the third party relays your mail from their own mailserver into
gmail it breaks SPF because gmail sees the email coming from the third
party mailserver IP, not from your IP. This is outside your control
unless you want to add all the 3rd party's outgoing email IPs as valid
for your SPF record, which is not advisable. But it should not be a
problem - gmail does not block emails purely on SPF failure. Nor
should anyone else IMO.

If you use DMARC then ensure that you DKIM-sign all your emails and
they will pass DMARC testing when they reach gmail via the 3rd party
relay (despite SPF failure), this may also improve the reputation of
your email domain within gmail.
Thanks.  That's what I thought, too.  But this is the strange 

thing:

gmail reports that the DKIM signature is good even while complaining
that DMARC fails.  (And so gmail classes as spam, apparently.)

DMARC policy is set to "v=DMARC1; p=none; rua=mailto:dm...@p27.eu"; (for
_dmarc.mobilitains.fr).
That is strange, can you provide an example ARC-Authentication-Results 
header from mx.google.com?

Re: SPF/DMARC modified by host en route

[Dominic Raferd]

On 26/04/2021 10:16, Jeff Abrahamson wrote:


I'm seeing a disturbing (but minority) number of hosts that class our 
mail is spam.  After some digging, I've found an interesting test 
case.  What I'm uncertain of is if this represents a config error on 
our side or a (grossly) misbehaving mail host elsewhere.


The interesting test case is a correspondent with a private domain 
(per...@example.com) and a gmail address (per...@gmail.com), both of 
which deliver to his gmail address.  That is, MX for example.com 
points to mx01.1and1.fr but the mail is still delivered to 
per...@gmail.com.


When I mail to per...@gmail.com, he receives the mail fine, and gmail 
reports that SPF, DKIM, and DMARC all pass.
When I mail to per...@example.com, he receives the mail classed as 
spam, gmail reports that SPF is neutral, DMARC fails (and DKIM passes).


Now what's odd is that gmail reports that SPF passes with the IP of my 
MX, but in the other case that it fails with the address of 
mout.kundenserver.de.  We've confirmed that mout.kundernserver.de 
handles mail to him via 1and1.fr, but not what could be causing an issue.


Mangling headers so badly to cause SPF/DMARC failures seems so 
egregious that I'm inclined to think it's somehow our fault.


(Note: this is about mail for mobilitains.fr and not p27.eu.)

When the third party relays your mail from their own mailserver into 
gmail it breaks SPF because gmail sees the email coming from the third 
party mailserver IP, not from your IP. This is outside your control 
unless you want to add all the 3rd party's outgoing email IPs as valid 
for your SPF record, which is not advisable. But it should not be a 
problem - gmail does not block emails purely on SPF failure. Nor should 
anyone else IMO.


If you use DMARC then ensure that you DKIM-sign all your emails and they 
will pass DMARC testing when they reach gmail via the 3rd party relay 
(despite SPF failure), this may also improve the reputation of your 
email domain within gmail.

Re: Configuring always_bcc

[Dominic Raferd]

On 21/04/2021 16:17, Alex wrote:

I have postfix configured in a multi-instance setup in conjunction
with amavisd. I'm using always_bcc to create a copy of each email sent
or received.

The problem is that, while postfix appears to deliver the bcc-user
email separately from the other recipients, amavis somehow delivers to
all the recipients, including the bcc-user, as one email.

How do I configure always_bcc to bypass amavisd altogether so it isn't
processed at all?

# postconf -c /etc/postfix-116 always_bcc
always_bcc = bcc-user

I'm unsure what postconf details I can provide, so I'll instead just
provide the log entries.

Apr 21 10:58:24 xavier postfix-out/local[2682940]: 19D63305F4A09:
to=, relay=local, delay=0.01, delays=0.01/0/0/0,
dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail)

...


If you are running amavis as a content filter, you need the initial 
postfix instance (which feeds into amavis) to have


receive_override_options = no_address_mappings

and then permit mappings (which include always_bcc) to occur in the 2nd 
instance (for the mail that is returned by amavis), for example this 
might be in master.cf by:


127.0.0.1:10025 inet n   -   n   -   -   smtpd
  # note: absence of no_address_mappings means that address mapping 
*will* occur here, including always_bcc

  -o receive_override_options=no_unknown_recipient_checks,no_milters
  ...

Re: REDIRECT overrides always_bcc

[Dominic Raferd]

On Fri, 16 Apr 2021, 20:07 Rob McGee,  wrote:

> On 2021-04-16 12:03, Dominic Raferd wrote:
> > I have started using a REDIRECT action in a header_checks table
> > which works but seems to prevent always_bcc from operating -
> > the email is not bcc'd.
>
> It's ugly, but a possible workaround: REDIRECT to an address which
> runs a script (transport_maps entry to a pipe(8) or to a local(8)
> address with a ~/.forward), and the script delivers a copy to your
> BCC address by some means.
>

Thanks for this suggestion, I might well implement it

>

Re: REDIRECT overrides always_bcc

[Dominic Raferd]

On 16/04/2021 18:39, Wietse Venema wrote:

Dominic Raferd:

I have started using a REDIRECT action in a header_checks table which
works but seems to prevent always_bcc from operating - the email is not
bcc'd.

REDIRECT is a blunt tool that ignores all recipients. If there are
multiple redirect actions, then the last action will take effect.
Theoretically it would be possible to parse the REDIRECT argument
as an address list, but demand for this has been rare. Multi address
support would have to be implemented for every BCC feature, otherwise
we'd drive people insane with inconsistencies.

Well that's a shame but thanks for explaining it Wietse

REDIRECT overrides always_bcc

[Dominic Raferd]

I have started using a REDIRECT action in a header_checks table which 
works but seems to prevent always_bcc from operating - the email is not 
bcc'd.


I tried adding a subsequent BCC action triggered by the same header text 
but it has no effect. I realise that this is consistent with 
documentation but is there a way to do the redirection and still do bcc 
as well? So far as I can see redirection is only supported to one 
address, not two?

Re: opedmarc and opendkim

[Dominic Raferd]

On 31/03/2021 17:29, Benny Pedersen wrote:

On 2021-03-31 18:21, Dan Mahoney wrote:


problem is your setup used Sender-ID with is long time depricated

Why would you advise not using libspf2?

atleast not in opendmarc, sid-milter is imho fine

but it bulds in both cases of depricated Sender-ID


opendmarc's internal spf checking with libspf2 works fine with versions 
1.3.2 or higher, so you don't need to use an external spf checker 
(unless you want such for another purpose).

Re: Backscatter problems + fixes + RFC idea

[Dominic Raferd]

On 20/03/2021 18:52, Rahul Dhesi wrote:

On Sat, 20 Mar 2021, Dominic Raferd wrote:

You may find my script helpful: 
https://www.timedicer.co.uk/programs/help/relay-enforcer.sh.php


Looks very interesting, thanks. I ran 'shellcheck' on it and saw many 
scary warnings; highly recommended to revise the code to fix all of them.


Thanks for pointing me to shellcheck. Apart from 3 fps, relay-enforcer 
now passes.

Re: Backscatter problems + fixes + RFC idea

[Dominic Raferd]

On 20/03/2021 01:53, Rahul Dhesi wrote:

On Fri, 19 Mar 2021, Wietse Venema wrote:


See examples in:
http://www.postfix.org/postconf.5.html#default_delivery_status_filter
(this was originally designed to turn soft TLS errors into hard ones).


Thanks, that is a vey nice feature I did not know about.

I should mention that my strategy of using a cron job to delete 
spam-suspect queued mail is not yet final, because:


When Gmail returns a spam-related temporary error, it might just be 
greylisting the sending client for some time, and maybe the message is 
not spam and will eventually be accepted.


This needs to be observed further.


You may find my script helpful: 
https://www.timedicer.co.uk/programs/help/relay-enforcer.sh.php

Re: k8s: auto reload after cert renewal

[Dominic Raferd]

On 19/03/2021 11:14, Leo Baltus wrote:

Running postfix in k8s and using cert-manger to manage certificates it would be 
nice
if postfix could pickup new certificates for long running processes like smtpd.

Much like it picks up updated databases like those managed by postmap.

I do not see any mention of this in man 5 postconf.

For now I run a cronjob to just restart postfix every day, I gues with some
serious hacking I could get postfix reload as a sidecar running in a loop
but that would also be suboptimal. Any thoughts on why postfix cannot pick
this up automatically?

smtpd (unlike postscreen) is a short-lived process

Re: Error 4.4.2 Error: timeout exceeded

[Dominic Raferd]

On 18/03/2021 10:36, Burn Zero wrote:
I have a relay server named smtprelayservername which accepts emails 
from various clients. So one of the clients complain that they receive 
this error while sending email:


Error 4.4.2  Error: timeout exceeded

But I have checked in the relay server smtprelayservername and no such 
timeout issue is logged.


Please guide me how to tackle such timeout issues.

PS: the problematic client sends 1000's of emails and are delivered 
properly to this relay server but the timeout issue occurs only 
sometime and is not reproducible.


Do you have AV or spam-filtering running as milter? If so:
- milter_command_timeout has a default of 30s, you could increase it; or
- (less easy) reconfigure your AV/spam-filtering to run as post-queue 
content-filter.

Re: Milter Behavior

[Dominic Raferd]

On 12/03/2021 02:35, Dan Mahoney wrote:


On Mar 11, 2021, at 1:00 AM, Dominic Raferd <mailto:domi...@timedicer.co.uk>> wrote:


This works for me:

# grep ^RejectFailures /etc/opendmarc.conf # (note: false is the 
default anyway)

RejectFailures false


That’s orthogonal.

RejectFailures only affects domains tagged p=reject.  The feature I’m 
working with only affects p=quarantine.
So you might think, but actually RejectFailures does affect domains 
tagged p=quarantine: setting it to false (or, presumably, not setting it 
at all) prevents the 'hold' action being reported back to the MTA 
(opendmarc v1.3.2).

Re: Milter Behavior

[Dominic Raferd]

On 10/03/2021 19:00, Dan Mahoney (Gushi) wrote:

All,

I'm working with the OpenDMARC folks on doing bug triage, and someone 
has requested that if a domain's policy says p=quarantine, that it 
should be "accepted" by postfix, and left for something like 
SpamAssassin to deal with.  (I don't see any specific handling in 
spamassassin that treats quaratine differently, but that's beside the 
point).


Per for RFCs, "quarantine" really means "queue for mail admins to deal 
with manually".  This is an old concept, going back in sendmail at 
least a decade, but it's been rarely used to this point.  Opendmarc 
makes this relatively common, and will catch mail admins by surprise.


So my question is (I've been reading the postfix milter docs for a 
half hour), is there any way to say (either globally or per-milter), 
"if the milter says hold, just deliver as normal?"


This is a thing that can be fixed in the milter, or fixed in postfix, 
but in an ideal world, both would exist.


(I mean, short of an every-minute cron job that just moves the things 
to the deliver queue).


-Dan


This works for me:

# grep ^RejectFailures /etc/opendmarc.conf # (note: false is the default 
anyway)

RejectFailures false

# postconf -n milter_header_checks
milter_header_checks = pcre:/etc/postfix/milter_header_checks.pcre

# cat /etc/postfix/milter_header_checks.pcre
# opendmarc is set not to reject failed emails, nor to instruct they
#   be held (RejectFailures false) - but it will still add a header
#   showing dmarc=fail: so here we can redirect them to a local
#   mailbox (because they sometimes prove to be genuine
#   i.e. from sender with misconfigured email server(s))
/^Authentication-Results: my_authserv_id.*dmarc=fail 
\(p=(reject|quarantine)/ REDIRECT dmarcfail@localhost

Re: Using alternate identity

[Dominic Raferd]

On 05/03/2021 12:40, Peter White wrote:

...I tried using said alternate identity by using mutt an simply changing
the "From" header. It kind of works but seems to leak my real email
address, because the "Return-Path" still points to the main address.
..


This is not a postfix issue. In .muttrc:

set envelope_from=yes

mutt will then try to derive the message's envelope sender from the 
"From:" header

Re: How do I stop getting multiple copies of emails from "always_bcc" option?

[Dominic Raferd]

On 04/03/2021 11:42, Steve Dondley wrote:

On 03.03.21 18:23, Steve Dondley wrote:

I have enabled the always_bcc setting with:

always_bcc = exam...@example.org

It works, but I'm getting everything three times. How do I prevent duplicates?

this can happen if you use content_filter that feeds mail back to postfix.

OK, yeah, I got spam assassin installed and have this line in
master.cf for smtp:

-o content_filter=spamassassin
Steve: if you are keen to become a real postfix and mail server nerd, 
you are in the right place, but my impression from your 
comments/questions is that you have a lot to learn and you will need to 
do a lot of your own homework (because everyone here is busy). If this 
doesn't appeal, consider using a recipe for a postfix-based mail server 
such as https://mailinabox.email/ or https://www.iredmail.org/. You lose 
the flexibility of a bespoke setup but you get back some of your life - 
I speak as someone who lost it ;-)

Re: empty pid files

[Dominic Raferd]

On 22/02/2021 14:07, Wietse Venema wrote:

Dominic Raferd:

I used to run postfix chrooted but no longer do so.

|find /var/spool/postfix -type f -ls|

shows a list of files in /var/spool/postfix/pid/ with names inet.* and
unix.*, all very old and zero-length. Is this a hangover from running
postfix chrooted? Can I remove them all?

You can delete these files safely only after Postfix is stopped.


It also shows a few files in /var/spool/postfix/defer, some a few days
old others much older. |postqueue -p| reports 'Mail queue is empty'.
Question ditto.

Answer ditto.

Wietse
Thanks Wietse. Most of (or perhaps all) the pid files were recreated 
anyway when, or shortly after, postfix restarted.

Re: empty pid files

[Dominic Raferd]

On 22/02/2021 08:19, Dominic Raferd wrote:

I used to run postfix chrooted but no longer do so.

|find /var/spool/postfix -type f -ls|

shows a list of files in /var/spool/postfix/pid/ with names inet.* and 
unix.*, all very old and zero-length. Is this a hangover from running 
postfix chrooted? Can I remove them all?


It also shows a few files in /var/spool/postfix/defer, some a few days 
old others much older. |postqueue -p| reports 'Mail queue is empty'. 
Question ditto.
I should have said there is also a non-zero and newish file 
|/var/spool/postfix/pid/master.pid| which I presume should stay.

empty pid files

[Dominic Raferd]

I used to run postfix chrooted but no longer do so.

|find /var/spool/postfix -type f -ls|

shows a list of files in /var/spool/postfix/pid/ with names inet.* and 
unix.*, all very old and zero-length. Is this a hangover from running 
postfix chrooted? Can I remove them all?


It also shows a few files in /var/spool/postfix/defer, some a few days 
old others much older. |postqueue -p| reports 'Mail queue is empty'. 
Question ditto.

Re: SSL version question

[Dominic Raferd]

On 17/02/2021 14:49, Vincent Lefevre wrote:

On 2021-02-16 18:34:32 -0200, Viktor Dukhovni wrote:

On Feb 16, 2021, at 3:57 PM, Dominic Raferd  wrote:


In what way does that improve your security over the default, which
allows 1.0 and 1.1?

As stated this is for auth clients i.e. our own people, using SMTPS or 
STARTTLS. There is no problem for us in enforcing it for them, they don't use 
old MTAs anyway and if they did this would force them to upgrade, which would 
be good. This also seems to be the OP's scenario (as his logs imply the problem 
comes from submission port i.e. 587). We use standard postfix settings for 
permitted protocols for outsider emails (port 25) because (as frequently 
advised here) lower security is better than no security at all. HTH

Yes, on the submission port, dropping support for TLS < 1.2
is much more reasonable, because presumably you can make
informed judgements as to what software the authorised users
have at their disposal.

But since smtpd_tls_mandatory_protocols is not specific to the
submission port, I suppose that this should be done with a -o option
in the master.cf file. Is that right?

After searching a bit, I've seen that on

   https://forum.chatons.org/t/configuration-postfix-notation-cryptcheck/1684

some user has

   submission inet n - n - - smtpd
   -o smtpd_enforce_tls=yes
   -o smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1

Is there any reason that he uses smtpd_tls_protocols and not
smtpd_tls_mandatory_protocols? This seems incorrect since
smtpd_enforce_tls=yes is mandatory TLS.


smtpd_tls_mandatory_protocols applies only where tls is mandatory. I define it 
in main.cf, where I also define 'smtpd_tls_security_level = may'. Then in 
master.cf, for connections by MTAs (our users) I define '-o 
smtpd_tls_security_level=encrypt' (also '-o smtpd_sasl_auth_enable=yes'). The 
effect is that the settings for smtpd_tls_mandatory_protocols are applied for 
the MTAs ('tls security level is encrypt' means 'tls is mandatory') and not for 
connections on port 25 because tls is not mandatory there.

But yes you could put the definition of smtpd_tls_mandatory_protocols in the 
smtpd settings in master.cf for all ports used for auth connections instead of 
putting it once in main.cf - it might make the logic easier to follow.

smtpd_enforce_tls=yes is an old setting available for Postfix 2.2+ but not 
advised for Postfix 2.3+.

man 5 postconf is your friend!

Re: SSL version question

[Dominic Raferd]

On 16/02/2021 17:41, Bill Cole wrote:

On 16 Feb 2021, at 5:46, Dominic Raferd wrote:


On 16/02/2021 10:28, Jeff Abrahamson wrote:

I have a client that's triggering these errors in my logs (and is
therefore unable to send even though he can read mail ok):

 postfix/submission/smtpd[310140]: connect from [...]
 postfix/submission/smtpd[310140]: SSL_accept error from [...]: -1
 postfix/submission/smtpd[310140]: warning: TLS library problem:
 error:14209102:SSL
 routines:tls_early_post_process_client_hello:unsupported
 protocol:../ssl/statem/statem_srvr.c:1685:
 postfix/submission/smtpd[310140]: lost connection after STARTTLS
 from 53.6.119.80.rev.sfr.net[80.119.6.53]
 postfix/submission/smtpd[310140]: disconnect from [...] ehlo=1
 starttls=0/1 commands=1/2

Searching on the error string isn't helping me particularly, and I'm
not sure how to discover what SSL version is being attempted.  That
he can read mail suggests to me that it's not really an SSL version
issue, but I see that dovecot is not being as strict.

I'd like to do what I can to verify/understand and not just relax
constraints blindly.

On my server I've set this, which I thought was permissive enough but
not too much:

 smtpd_tls_mandatory_protocols = SSLv3, TLSv1

Thanks for any pointers.

(Fwiw, the client is running thunderbird on Windows 10. Hopefully
that's not relevant.)


Those are terrible settings, probably the opposite of what you want.
For auth clients I have:

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

That punishes older MTAs by forcing them  to use cleartext if they don't
do TLSv1.2+

In what way does that improve your security over the default, which
allows 1.0 and 1.1?
As stated this is for auth clients i.e. our own people, using SMTPS or 
STARTTLS. There is no problem for us in enforcing it for them, they 
don't use old MTAs anyway and if they did this would force them to 
upgrade, which would be good. This also seems to be the OP's scenario 
(as his logs imply the problem comes from submission port i.e. 587). We 
use standard postfix settings for permitted protocols for outsider 
emails (port 25) because (as frequently advised here) lower security is 
better than no security at all. HTH

Re: SSL version question

[Dominic Raferd]

On 16/02/2021 10:28, Jeff Abrahamson wrote:


I have a client that's triggering these errors in my logs (and is 
therefore unable to send even though he can read mail ok):


postfix/submission/smtpd[310140]: connect from [...]
postfix/submission/smtpd[310140]: SSL_accept error from [...]: -1
postfix/submission/smtpd[310140]: warning: TLS library problem:
error:14209102:SSL
routines:tls_early_post_process_client_hello:unsupported
protocol:../ssl/statem/statem_srvr.c:1685:
postfix/submission/smtpd[310140]: lost connection after STARTTLS
from 53.6.119.80.rev.sfr.net[80.119.6.53]
postfix/submission/smtpd[310140]: disconnect from [...] ehlo=1
starttls=0/1 commands=1/2

Searching on the error string isn't helping me particularly, and I'm 
not sure how to discover what SSL version is being attempted.  That he 
can read mail suggests to me that it's not really an SSL version 
issue, but I see that dovecot is not being as strict.


I'd like to do what I can to verify/understand and not just relax 
constraints blindly.


On my server I've set this, which I thought was permissive enough but 
not too much:


smtpd_tls_mandatory_protocols = SSLv3, TLSv1

Thanks for any pointers.

(Fwiw, the client is running thunderbird on Windows 10. Hopefully 
that's not relevant.)


Those are terrible settings, probably the opposite of what you want. For 
auth clients I have:


smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

This refuses anything below TLSv1.2, and works fine with clients running 
Thunderbird on Windows 10.


Thunderbird v78 disables TLSv1.0 and TLSv1.1 by default for good safety 
reasons. This is almost certainly the reason for the errors you are 
seeing - your server is trying to force the client to connect with 
outdated protocols (SSLv3 or TLSv1) and the client refuses.

Re: File-format for Included Files for main.cf Options

[Dominic Raferd]

On 12/02/2021 18:35, Chris Green wrote:

On Fri, Feb 12, 2021 at 01:08:07PM -0500, Viktor Dukhovni wrote:

On Fri, Feb 12, 2021 at 11:14:24AM +, Dominic Raferd wrote:


On 12/01/2021 01:21, Viktor Dukhovni wrote:

On Tue, Jan 12, 2021 at 01:00:26AM +, JL (Postfix Readers A/c) wrote:


Can someone point me at the right place in the docs, or offer advice
which maybe could also be added to the docs (!) to help others?

Each main.cf parameter documents its syntax.  Various parameters, that
take literal lists of values in-line, also take a file name whose
content contains similar values...

How to know which parameters accept a filename as argument in this way?

By experiment, myorigin does but mydomain and myhostname do not. It
would be helpful (to me) if myhostname took a filename as argument.

You're perhaps confusing myorigin with mydestination.

The myorigin parameter is also not a match list, and so (in the
"upstream" official Postfix releases) does not support indirect
specification via a file.

I am not aware of any "single-valued" parameters that are match lists in
the upstream release.  Debian patches Postfix to support an external
file for (IIRC) myhostname, but that's not something that you'll see
otherwise.


The Debian patch sets myorigin:-

 # Debian GNU/Linux specific:  Specifying a file name will cause the
 # first line of that file to be used as the name.  The Debian default
 # is /etc/mailname.
 #
 #myorigin = /etc/mailname
Thanks yes this is what I had in mind - I run postfix on Debian-derived 
distro (Ubuntu) and I had not realised that Debian patched the postfix 
source code; this explains why it is not mentioned in the postfix docs.

Re: File-format for Included Files for main.cf Options

[Dominic Raferd]

On 12/01/2021 01:21, Viktor Dukhovni wrote:

On Tue, Jan 12, 2021 at 01:00:26AM +, JL (Postfix Readers A/c) wrote:


Can someone point me at the right place in the docs, or offer advice
which maybe could also be added to the docs (!) to help others?

Each main.cf parameter documents its syntax.  Various parameters, that
take literal lists of values in-line, also take a file name whose
content contains similar values...


How to know which parameters accept a filename as argument in this way?

By experiment, myorigin does but mydomain and myhostname do not. It 
would be helpful (to me) if myhostname took a filename as argument.

Re: client and ehlo hostname mismatch

[Dominic Raferd]

On 11/02/2021 09:32, Eugene Podshivalov wrote:


Is it safe enough nowadays to drop dmarc failed incoming mail with 
opendmarc?


I would say not. I quarantine DMARC failures but do not reject - there 
are still fps because of misconfiguration by senders or mailing lists 
that are not DMARC-friendly (including, ironically, opendmarc-users).

Re: Stucked with "unable to look up host"

[Dominic Raferd]

On 09/02/2021 12:36, @lbutlr wrote:

On 09 Feb 2021, at 04:23, Dominic Raferd  wrote:

This shows plenty of 'good' servers still using TLSv1 or TLSv1.1 -  including 
the postfix-users list servers. Of course they would probably downgrade to 
plaintext if required, but that would reduce security.

That is odd. My mails from the postfix list server are using TLSv1.2. Are you 
sure the postfix list is using end-of-life encryption?...
It depends how far back one's logs go! Now I look just at my logs for 
this calendar year I see you are right. But there are still a few other 
'good' senders using TLSv1 or TLSv1.1, even if they shouldn't be. Not 
'plenty', I admit...

Re: Stucked with "unable to look up host"

[Dominic Raferd]

On 09/02/2021 10:58, @lbutlr wrote:

On 09 Feb 2021, at 03:53, @lbutlr  wrote:

Looking over the last few days, I see connections rom servers I do not accept 
mail from, so it looks to me based on my logs that I could easily reject TLSv1 
or TLSv1.1 without missing a single mail.

Meant to include this in case this helps:

bzgrep TLSv1 /var/log/mail.log.* | egrep -v '(TLSv1.3|TLSv1.2)' | egrep -o 
'established from [^:]*' | sort -u


My logs are unzipped or gzipped, so I needed:

zgrep -ha TLSv1 /var/log/mail.log*|egrep -v 'TLSv1\.[23]'|egrep -o 
'established from [^:]*'|cut -d" " -f3|sort|uniq -c|sort -n


This shows plenty of 'good' servers still using TLSv1 or TLSv1.1 -  
including the postfix-users list servers. Of course they would probably 
downgrade to plaintext if required, but that would reduce security.

Re: TCP wrappers and Postfix

[Dominic Raferd]

On 08/02/2021 08:04, Eugene Podshivalov wrote:
There are a bunch of spiders and spammers nowadays which are knocking 
the service every hour or so every day. Postfix has a really powerful 
access control system to protect itself but it becomes a bit hard to 
read the log file flooded by the connection attempts. I'm currently 
trying to filter those out by UFW but dynamic addresses make it quite 
inefficient.


My 2p (I also use ufw but as a last-resort):

Postscreen of course

Fail2ban 0.10+ with its postfix (and recidive) jails

If you run postfix's dnsblog you could remove it to reduce the number of 
log entries


If you allow incoming emails by IPv6 you might turn it off

Re: rejecting 'fancy' TLDs, allowing a specified one ?

[Dominic Raferd]

On 30/01/2021 20:22, Viktor Dukhovni wrote:

On Sat, Jan 30, 2021 at 01:20:13PM -0500, Phil Stracchino wrote:


I'm looking at implementing a rule to discard all
four-letter-and-above TLDs except whitelisted ones, because I'm tired
of playing whack-a-mole.

I'd like to strongly advise against filtering by TLD.  This is a very
low quality signal.  There is no shortage of abuse mail from the
traditional gTLDs, and also a non-trivial quantity of legitimate
email from new gTLDs.

Most of the ".brand" gTLDs are not open for public registration of
subdomains, and if say citibank decided to send email from a ".citi"
subdomain, that'd be just fine.  They should be able to use the gTLD
they control.

For example, the ".info" and ".name" gTLDs are established sources of
legitimate email.  Looking at DANE-enabled domains, which junk mail
senders are unlikely to bother setting up, I see the following top 30
domain counts by TLD, indicating a population of non-abusive domains.

   ...


Viktor's advice is (as always) sound. My original reply was a 
non-advisory answer to OP's question.


FWIW my approach is a bespoke header test within SpamAssassin (local.cf) 
against 'EnvelopeFrom' and 'From' which adds a heavy point penalty for 
TLDs that are - for us - out of the ordinary, with a few special 
exceptions. My welcome-listed TLDs do not include any of those listed by 
Viktor except for '.email'. But I am running private mail servers with 
active quarantine management so I can tweak these settings when FPs 
occur without significant risk of rejecting ham.

Re: How do you manage the ‘hold’ queue?

[Dominic Raferd]

On 27/01/2021 13:47, David Bürgin wrote:

Thanks everybody – I’ve decided that for me personally handling this is
too much work, and I’ve disabled this particular milter.

(There is an open issue in the OpenDMARC project that I have upvoted:
https://github.com/trusteddomainproject/OpenDMARC/issues/77)


Re that issue, my workaround can be easily modified to allow emails that 
fail DMARC testing but have p=quarantine to pass through automatically 
to original recipient, while retaining ones with p=reject.


FWIW my experience is that about 70% of DMARC failures proceed from 
fakes, the rest are genuine but misconfigured.

Re: trouble talking to NYC Government

[Dominic Raferd]

On 26/01/2021 15:46, Ruben Safir wrote:

I am getting this strange rejections to talk to NYC government

Final-Recipient: rfc822; cdeut...@council.nyc.gov
Original-Recipient: rfc822;cdeut...@council.nyc.gov
Action: delayed
Status: 4.4.3
Diagnostic-Code: X-Postfix; delivery temporarily suspended: Host or
domain name
not found. Name service error for name=mx2.nycdoitt.iphmx.com
type=A: Host not found, try again
Will-Retry-Until: Sun, 31 Jan 2021 04:42:53 -0500 (EST)

dig  mx2.nycdoitt.iphmx.com

;; ANSWER SECTION:
mx2.nycdoitt.iphmx.com. 3326IN  A   68.232.143.122
...


Check that your postfix instance can reach resolv.conf:

|# sudo -u postfix -H cat /etc/resolv.conf|

and that your postfix can use ipv4:

|# postconf inet_protocols|

Re: How do you manage the ‘hold’ queue?

[Dominic Raferd]

On 26/01/2021 07:13, David Bürgin wrote:

I’ve recently begun using the ‘hold’ queue, because of a milter that I
use. A milter may ‘quarantine’ a message, which causes the message to be
placed in the ‘hold’ queue (eg OpenDMARC does this when the DMARC policy
requests quarantine).

But how does one manage that queue? I know that
postqueue/postsuper/postcat exist, but it seems like a lot of work to
periodically (daily, weekly?) inspect each message in that queue and
deal with them one by one? Do people actually use quarantine/on-hold,
and if so how do you manage your queue?


This is my approach with openDMARC. Of course the resulting local mail 
store (mbox file in my case) still has to be checked and managed.


# grep -E "^(RejectFailures|AuthservID) " /etc/opendmarc.conf
RejectFailures false
AuthservID  streamingbats.co.uk

# postconf milter_header_checks
milter_header_checks = pcre:/etc/postfix/milter_header_checks.pcre

# cat /etc/postfix/milter_header_checks.pcre
/^Authentication-Results: streamingbats\.co\.uk.*dmarc=fail 
\(p=(reject|quarantine)/ REDIRECT ubuntu@localhost

Re: rejecting 'fancy' TLDs, allowing a specified one ?

[Dominic Raferd]

On 16/12/2020 11:07, li...@sbt.net.au wrote:

I have a check to reject 'fancy TLDs' as below

smtpd_sender_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_sender_access pcre:/etc/postfix/sender_pcre,
  check_sender_access pcre:/etc/postfix/reject_domains

cat /etc/postfix/reject_domains
/\.bid$/ REJECT We reject all .bid domains
/\.biz$/ REJECT We reject all .biz domains
...

that works well, but, now have a user who gets a valid inbound rejected

Dec 16 15:06:14 postfix/smtpd[8695]: NOQUEUE: reject: RCPT from
mail-sy4aus01on2077.outbound.protection.outlook.com[40.107.107.77]: 554
5.7.1 : Sender address rejected: We reject all .biz
domains; from= to= proto=ESMTP
helo=

is there an easy way, and how, to exempt a specified domain like
'abcd.biz' from my sender restriction ?


/etc/postfix/reject_domains:

/@abcd\.biz$/ DUNNO
/\.bid$/ REJECT We reject all .bid domains
/\.biz$/ REJECT We reject all .biz domains

Re: 'Send only' postfix configuration works on Ubuntu but not on Rasberry Pi - missing TLS library?

[Dominic Raferd]

On 07/12/2020 14:58, Chris Green wrote:

On Mon, Dec 07, 2020 at 02:34:14PM +, Dominic Raferd wrote:

On 07/12/2020 13:11, Chris Green wrote:

On Mon, Dec 07, 2020 at 01:01:16PM +, Chris Green wrote:
[snip]


While I'm about it why am I getting identical mail.log and mail.info
files created in /var/log on the Pi?
I could still do with an answer to this.


Check contents of /etc/rsyslog.d (e.g. 50-default.conf) and docs at
www.rsyslog.com/doc/

Yes, thanks (and Wietse), the Raspberry Pi default rsyslog
configuration has:-

 mail.*  -/var/log/mail.log
 ...
 ...
 mail.info   -/var/log/mail.info
 mail.warn   -/var/log/mail.warn
 mail.err/var/log/mail.err

Sorry for the noise.  I'll go quiet again soon when I've got Postfix
properly configured on these systems I've just added it to.


If immediately after the line beginning 'mail.*'  you insert a line:

& stop

this will stop any further mail facility logging. Or delete the later lines.

You will have to restart rsyslogd afterwards e.g. systemctl restart rsyslog

Re: 'Send only' postfix configuration works on Ubuntu but not on Rasberry Pi - missing TLS library?

[Dominic Raferd]

On 07/12/2020 13:11, Chris Green wrote:

On Mon, Dec 07, 2020 at 01:01:16PM +, Chris Green wrote:
[snip]



While I'm about it why am I getting identical mail.log and mail.info
files created in /var/log on the Pi?
I could still do with an answer to this.

Check contents of /etc/rsyslog.d (e.g. 50-default.conf) and docs at 
www.rsyslog.com/doc/

Re: adding AV scanning to working Postfix/SA system

[Dominic Raferd]

On 23/11/2020 16:34, Joe Acquisto-j4 wrote:

Not to waste anyone's time, but I posted this on SA list and a Sophos site, but, came up with zip. 
Not even a "do-dah".  Beyond "experiences"
any leads to general "how to: guides that work in practice?


SOHO system, on virtual machines.   Fairly recent versions. Running openSUSE 
Leap 15.1.

Due to some recent malware (in attachments, obvious stuff) wanted to add AV scanning.   I 
gather "Amavis-new" is the hot ticket these days,

I deal with Sophos products and would like to use their linux product to do the 
scanning.   Seems to be precious little on how to do that.

Any experiences?
None with Sophos products on Linux. But I use amavis as content-filter 
and it in turns calls SA (which presumably you already know about) and 
ClamAV. ClamAV works well provided you add various 3rd-party signatures. 
I know of two tools to assist with these: 
https://github.com/extremeshok/clamav-unofficial-sigs and the newer 
https://github.com/rseichter/fangfrisch.

Re: Fwd: Verify Proper method for sender restrictions

[Dominic Raferd]

On 28/10/2020 15:53, Allen Coates wrote:


On 28/10/2020 15:24, Viktor Dukhovni wrote:

On Wed, Oct 28, 2020 at 09:05:40AM +, Allen Coates wrote:


Some time ago (5 years maybe) I discovered that "OK" was not being universally
recognised in every access list;  I cultivated the habit of using the words
"ACCEPT" and REJECT" - and have had no problems since.

That's odd, because in fact Postfix does not support "ACCEPT", but
smtpd(8) definitely supports "OK" in *ALL* access(5) tables:

If I recall rightly, it was about the time I started using postscreen, and I was
using the file postscreen_access.cidr as a whitelist to bypass the tests in
smtpd_sender_restrictions.

But it was a LONG time ago, and all I can remember is that there was something
about "OK" that didn't give the results I expected.

I will have to have a "play" again...


The only acceptable commands for postscreen_access_list (per 
documentation) are: permit_my_networks / permit / reject / dunno / 
type:table. OK is not acceptable here.

Re: sanity-check postfix XCLIENT usage ?

[Dominic Raferd]

On 23/10/2020 09:27, Nick Tait wrote:

On 22/10/20 6:13 am, PGNet Dev wrote:
Before I take this up as an opendmarc question (my config &/or bug), 
& do more thorough digging re: intuit's published records,


(1) Is there anything obviously wrong/missing in that^ XCLIENT usage 
generally, or in the specific intuit.com case above, that would 
suggest a cause for the dmarc/milter FAIL, that 1st needs fixing?


I _suspect_ not, given the success with all _other_ domains ...


Two ideas:

 1. Configure the HistoryFile option in /etc/opendmarc.conf, and see
what gets written to that file?
 2. I presume you have "RejectFailures true" in /etc/opendmarc.conf
currently? Try changing that to false, to allow the email to be
delivered, and then see what Authentication-Results headers get
added? (E.g. They might suggest something like an alignment failure?)

+1, and when doing this you might want to redirect emails that fail 
DMARC into a special mailbox, something like:


/etc/postfix/main.cf:
...
milter_header_checks = pcre:/etc/postfix/milter_header_checks.pcre
...

/etc/postfix/milter_header_checks.pcre:
/^Authentication-Results: yourauthid_here.*dmarc=fail \(p=reject/ 
REDIRECT your_chosen@mailbox

Re: sanity-check postfix XCLIENT usage ?

[Dominic Raferd]

On 22/10/2020 00:39, PGNet Dev wrote:

On 10/21/20 4:31 PM, Wietse Venema wrote:

PGNet Dev:

Two questions:


clear.

i'll focus just on just the dmarc bits.

both debugging opendmarc, and replacing it with another option to see 
if behavior changes.


xclient's extremely helpful in any case.



It may be unrelated, but we have received a few fake intuit emails 
recently, all correctly identified as such by opendmarc.

Re: rbl check debug

[Dominic Raferd]

On 16/10/2020 22:04, David Wells wrote:
I have a postfix-3.3.2 installation (installed from source on 
slackware 14.2 from the slackbuilds package) that does rbl checks in 
the smtpd_recipient_restrictions section. I have been seeing an 
increasing amount of spam coming in so I added more reject_rbl_client 
instances listing more and more rbl servers. However I still am seeing 
large ammounts of spam getting through and I have checked several 
mails that have come in using http://multirbl.valli.org/ and the 
servers from which they arrive are listed in at least one of these rbl 
checks, most times in more than one. Is there a way to debug why these 
mails are getting through even though they come from an rbl 
blacklisted server?
On top of the excellent advice already given, another possible cause: 
you are not running a local DNS server and so your lookups are passing 
through an external one (such as your ISP's) and are RBLs are refusing 
to give (useful) responses because the source IP that they see (of the 
external DNS server) doesn't look private or has submitted too many 
lookups.

Re: repeated connect and disconnect

[Dominic Raferd]

On Thu, 8 Oct 2020 at 04:03, li...@lazygranch.com  wrote:
>
> Is there something I should be doing to mitigate this problem?
>
> Oct  8 02:11:42 myserver postfix/smtpd[11630]: connect from 
> unknown[180.123.163.212]
> Oct  8 02:11:43 myserver postfix/smtpd[11632]: connect from 
> unknown[180.123.163.212]
> Oct  8 02:11:43 myserver postfix/smtpd[11632]: lost connection after EHLO 
> from unknown[180.123.163.212]
> Oct  8 02:11:43 myserver postfix/smtpd[11632]: disconnect from 
> unknown[180.123.163.212] ehlo=1 commands=1
> ...
> Oct  8 02:11:55 myserver postfix/smtpd[11632]: warning: Connection rate limit 
> exceeded: 11 from unknown[180.123.163.212] for service smtp
> Oct  8 02:11:55 myserver postfix/smtpd[11632]: disconnect from 
> unknown[180.123.163.212] commands=0/0
> Oct  8 02:11:55 myserver postfix/smtpd[11630]: connect from 
> unknown[180.123.163.212]
> Oct  8 02:11:55 myserver postfix/smtpd[11630]: warning: Connection rate limit 
> exceeded: 12 from unknown[180.123.163.212] for service smtp
> Oct  8 02:11:55 myserver postfix/smtpd[11630]: disconnect from 
> unknown[180.123.163.212] commands=0/0
> Oct  8 02:15:15 myserver postfix/anvil[11633]: statistics: max connection 
> rate 12/60s for (smtp:180.123.163.212) at Oct  8 02:11:55
> Oct  8 02:15:15 myserver postfix/anvil[11633]: statistics: max connection 
> count 2 for (smtp:180.123.163.212) at Oct  8 02:11:43
> Oct  8 02:15:15 myserver postfix/anvil[11633]: statistics: max cache size 1 
> at Oct  8 02:11:42


smtpd is doing what you told it to and apart from the crud in the log
I don't think there is a problem. But otherwise, use postscreen +
RBLs? This ip address is blocklisted by many RBLs, including
zen.spamhaus.org.

Re: Reverse smtpd_sender_login_maps

[Dominic Raferd]

On Wed, 7 Oct 2020 at 14:04, Vieri Di Paola  wrote:
>
> On Wed, Oct 7, 2020 at 2:34 PM Tom Sommer  wrote:
> >
> > So SASL user "t...@example.com" would be able to send only from
> > "@example.com".
>
> smtpd_sender_login_maps = pcre:/etc/postfix/login_maps.pcre
>
> content of /etc/postfix/login_maps.pcre:
> /^(.*)@your(own)?domain\.org$/   ${1}
>
> This would force sasl-authed user "me" to only send from
> m...@yourdomain.org or m...@yourowndomain.org.
> You can change the regex to allow from @domain instead.

If, for authenticated users, you also want to enforce an *exact match*
between the Envelope Sender and the mail address in the 'From:'
header, this is offered by the milter at
https://github.com/magcks/milterfrom (but I have not tested it).

To enforce a domain-only match between the Envelope Sender and the
mail address in the 'From:' header the only way I can think of is to
use DMARC with p=reject, which is a big hammer for the given nut. Can
postfwd help here?

Re: How to allow relaying per domain?

[Dominic Raferd]

What about having multiple different smtpd services on different
ports; then set up the LAN mail agents to send to whichever port is
appropriate for their access, and you can have entirely bespoke
settings for each one.

On Mon, 28 Sep 2020 at 10:02, Hans van Zijst  wrote:
>
> Hi Nick,
>
> Thanks for your reaction, it gave me some food for thought.
>
> I can see how this works for a limited number of servers, but
> unfortunately (?) our environment is a lot bigger than that.
>
> I think my solution is to write a policy service:
>
> http://www.postfix.org/SMTPD_POLICY_README.html
>
> That would give me all the variables I need, at the disadvantage of
> having to write and maintain some separate code.
>
> On 27-09-2020 08:32, Nick Tait wrote:
> > Hi Hans.
> >
> > I'm not sure if there is an easier way, but one way to achieve this is
> > with a restriction class per server. (BTW I don't know much about LDAP
> > so the example below is based on files...)
> > ...
> >
> > Nick.
> >
> >
> > On 25/09/20 2:42 am, Hans van Zijst wrote:
> >> Is it possible to let Postfix decide which hosts to relay mail for,
> >> based on the domain from which that mail is sent?
> >>
> >> I'm building a relayhost that should accept e-mail from a whole bunch of
> >> internal mailservers, and relay it to the Internet, after scanning,
> >> DKIM-signing and rate limiting.
> >>
> >> But I don't want to give Postfix one list of all hosts that are allowed
> >> to relay mail through it, because that would allow users of all internal
> >> servers to send mail from all domains. I'm looking for a way to let
> >> Postfix check if the host is allowed to send mail for the domain involved.
> >>
> >> I'm using an LDAP backend and what I thought I wanted to do under
> >> "smtpd_relay_restrictions" is a "check_client_access" query for the
> >> domain, and return the attribute which contains the host(s) that are
> >> allowed, with "PERMIT", like this:
> >>
> >> smtpd_relay_restrictions =  check_client_access ldap:relay_access
> >>
> >> Where the file relay_access contains something like:
> >>
> >> query_filter = domainName=%d
> >> result_attribute = allowedHost
> >> result_format = %s PERMIT
> >>
> >> But the input key here is not the domain name, but the address of the
> >> smtpserver sending the message.
> >>
> >> How do I match a domain name with an IP-address or FQDN? Or am I looking
> >> in the wrong direction here?
> >>
> >> Kind regards,
> >>
> >> Hans

Re: smtpd_tls_CApath etc - needed?

[Dominic Raferd]

On Thu, 24 Sep 2020 at 09:12, Viktor Dukhovni
 wrote:
>
> On Wed, Sep 23, 2020 at 09:48:28AM +0100, Dominic Raferd wrote:
>
> > My mail servers, with LetsEncrypt certificates, seem to be working
> > perfectly (sending to, and receiving from, the world), but I have
> > never set any of:
> >
> > smtp_tls_CAfile
> > smtp_tls_CApath
> > smtpd_tls_CAfile
> > smtpd_tls_CApath
> > tls_append_default_CA
>
> Congratulations you have a working system that has not been tweaked
> based on cargo-culting some random HOWTO.
>
> > Should I be setting any of these?
>
> No.

Excellent, thank you Viktor!

smtpd_tls_CApath etc - needed?

[Dominic Raferd]

My mail servers, with LetsEncrypt certificates, seem to be working
perfectly (sending to, and receiving from, the world), but I have
never set any of:

smtp_tls_CAfile
smtp_tls_CApath
smtpd_tls_CAfile
smtpd_tls_CApath
tls_append_default_CA

Should I be setting any of these?

Re: Being blocked with error 554 5.7.1

[Dominic Raferd]

Jools, as David Burgin pointed out, your SPF record in DNS is (still)
broken (as well as your DMARC record) and this may well be the cause
of your problems.

v=spf1 mx a:81.145.130.2 -all
should be (because the 'a:...' syntax is wrong and superfluous):
v=spf1 mx -all
- I missed this on my original reading oops

For the DMARC record, remove the escaped quotes:
\"v=DMARC1; p=none; rua=mailto:sysad...@bordengrammar.kent.sch.uk\";
should be:
v=DMARC1; p=none; rua=mailto:sysad...@bordengrammar.kent.sch.uk


On Sat, 12 Sep 2020 at 19:17, Julian Pilfold-Bagwell
 wrote:
>
> Hi,
>
> I've fixed DKIM and have fired a message off to several DKIM validation
> sites which have come back with SPF, DMARC and DKIM as all having
> passed.   I changed the TLS setting you suggested as well
>
> We then sent a test batch and the first 11 went through, the following 8
> were rejected, and the next 7 went through.
>
> It really is weird.  If it was all of the messages being bounced I could
> understand it, but google and yahoo both seem to let a load through yet
> block a handful.  I guess it's possible that the end-users have an
> option to set the aggressiveness of the spam filtering but it seems like
> a setting that wouldn't be commonly used as Google's defaults are
> usually pretty good and we don't tend to get rejected in daily use.
>
>
> On 12/09/2020 14:53, Dominic Raferd wrote:
> > Just after I sent my reply to your later email I saw this reply of
> > yours (below) - which Google had accepted but put into my spam folder!
> >
> > On Sat, 12 Sep 2020 at 13:14, Julian Pilfold-Bagwell
> >  wrote:
> >>I'll make the change to TLS and see what happens as well as fix the
> >> DMARC.  The server's been running 24/7 since 2015 and is due for
> >> replacement in the summer of 2021 at which point I'll be upgrading the
> >> postfix version.
> >>
> >> I'll check the headers again and will get back.
> >>
> >> On 12/09/2020 12:15, Dominic Raferd wrote:
> >>> On Fri, 11 Sep 2020 at 22:49, Julian Pilfold-Bagwell
> >>>  wrote:
> >>>> I have a problem that's sprung to light after we bought in a 3rd party
> >>>> cloud provider.  I have postfix 2.10 running on Centos 7 (main.cf below)
> >>>> and our 3rd party provider is relaying mail out via our server, using
> >>>> authentication on a legit account.  However, the recipient ISPs reject
> >>>> mail with the error 554 5.7.1 recipient access denied, although this
> >>>> doesn't seem to happen on all the messages that are being sent.  If
> >>>> we're sending say 60 messages, the first block of 20 will go through,
> >>>> the next 20 will be blocked and the final 20 will go through.  I'm
> >>>> guessing that the receiving end is objecting to something in the headers
> >>>> from the relayed mail, but can't quite get to grips as to why it occurs
> >>>> in batches.
> >>>>
> >>>> The 3rd party provider is sending reports to all of our end users which
> >>>> is over a thousand emails+  so I've limited the delivery rate to 1
> >>>> message per domain every twenty seconds  to try to appear less spammy
> >>>> but it still happens as described.  The error message is as below:
> >>>>
> >>>> NOQUEUE: reject: RCPT from smtp.overnetdata.com[5.153.65.228]: 554 5.7.1
> >>>> : Recipient address rejected: Access denied;
> >>>> from= to=
> >>>> proto=ESMTP helo=
> >>>>
> >>>> and we're receiving this from talktalk.co.uk, sky.com, yahoo.co.uk,
> >>>> hotmail.com, outlook.com and gmail.com sometimes talks to us, and
> >>>> sometimes doesn't.
> >>>>
> >>>> and main.cf is shown here:...
> >>> The setup seems imperfect, and the version of postfix rather old, but
> >>> which if any of the imperfections is causing this new problem is hard
> >>> to say without fuller examples of what is being blocked, which I can
> >>> well understand you might not want to post on an open forum. My
> >>> observations are:
> >>>
> >>> Instead of 'smtp_use_tls = yes' it is advisable to use
> >>> 'smtp_tls_security_level = may' (Postfix 2.3+)
> >>>
> >>> Your SPF entry in DNS looks ok, provided as you say that the 3rd party
> >>> is sending your emails via your mail server and not independently.
> >>> Also your mail server's ip is not blacklisted at any of the 129 rbls I
> >>> regularly check, nor at https://ipremoval.sms.symantec.com/. You can
> >>> check its status with Microsoft by registering it at their Smart
> >>> Network Data Service.
> >>>
> >>> Your DMARC entry in DNS is broken, also you do not appear to be
> >>> signing outgoing emails with DKIM. But I doubt either of these is the
> >>> explanation for your problem.
> >>>
> >>> Is the third party sender using your domain in the 'From:' header as
> >>> well as in the envelope?
> >> --
> >> J. Pilfold-Bagwell,

Re: Forward mail and obey SPF and DKIM

[Dominic Raferd]

On 14/09/2020 15:09, IL Ka wrote:
On Mon, Sep 14, 2020 at 4:53 PM Dominic Raferd 
mailto:domi...@timedicer.co.uk>> wrote:


On 14/09/2020 14:31, IL Ka wrote:
> Hello.
> I have postfix running on linux box.
>
> I setup OpenDKIM with both smtpd and non_smtp milters.
> I also set my address in DNS as permitted IP for SPF.
>
> So far, so good.
>
> But I want all my mail to be forwarded to gmail.
>
> Some user sends me email from user@some_sender_domain.
>
> If I use .forward or alias, then postfix doesn't change "From"
header,
> so gmail believes email was sent from @some_sender_domain.
> This domain doesn't have my box IP as permitted in DNS, so SPF
failed.
>
> I can change header using headers_check. But then DKIM signature
> would be broken because some_sender_domain signed email and I
changed it.
>
> It seems that I need to:
> * Change headers
> * Sign email with my DKIM
> * Forward it to gmail
>
> But milters are not applied on forwarded emails because they aren't
> locally generated (or I failed to configure it correctly?)
>
> I can fix it using custom script that reads my local email
> and sends it to gmail.
>
> But how can I do that with postfix?

The short answer is that SPF failures do not normally matter when
forwarding to gmail. They only matter if sender uses DMARC with
p=reject
*and* has not signed their email with DKIM, which is a poor and rare
practice (though not forbidden). (Forwarding to gmail should not
break
the original sender's DKIM signature.)


> Thank you.
> I see "SPF: SOFTFAIL" in my gmail message.
>
> Authentication results:
> spf=softfail (google.com <http://google.com>: domain of transitioning 
some_user@sender_domain does not designate MY_IP_ADDR as permitted sender)

>
> While the message is not blocked, it is still not good to have SPF 
failure. Even when failure is soft.

>
> It seems that I can't fix it, right?

Don't worry about it. There are enough real problems to worry about.

Re: Forward mail and obey SPF and DKIM

[Dominic Raferd]

On 14/09/2020 14:31, IL Ka wrote:

Hello.
I have postfix running on linux box.

I setup OpenDKIM with both smtpd and non_smtp milters.
I also set my address in DNS as permitted IP for SPF.

So far, so good.

But I want all my mail to be forwarded to gmail.

Some user sends me email from user@some_sender_domain.

If I use .forward or alias, then postfix doesn't change "From" header,
so gmail believes email was sent from @some_sender_domain.
This domain doesn't have my box IP as permitted in DNS, so SPF failed.

I can change header using headers_check. But then DKIM signature
would be broken because some_sender_domain signed email and I changed it.

It seems that I need to:
* Change headers
* Sign email with my DKIM
* Forward it to gmail

But milters are not applied on forwarded emails because they aren't 
locally generated (or I failed to configure it correctly?)


I can fix it using custom script that reads my local email
and sends it to gmail.

But how can I do that with postfix?


The short answer is that SPF failures do not normally matter when 
forwarding to gmail. They only matter if sender uses DMARC with p=reject 
*and* has not signed their email with DKIM, which is a poor and rare 
practice (though not forbidden). (Forwarding to gmail should not break 
the original sender's DKIM signature.)

Re: spam uses my email address as sender in "header from"

[Dominic Raferd]

On 14/09/2020 11:35, Fourhundred Thecat wrote:

I am receiving spam, where the "header from" is my actual email (ie, the
email that this spam is delivered to)

The "envelope from" that I see in postfix logs is some random email.

What mechanisms are there to reject such messages, which use my email
address as sender ?

Can I reject messages that have different envelope from and header from?

Or what would be the best approach ?


If you are accepting authenticated senders on a different port of your 
server from unauthenticated (e.g. 587 versus 25), you can simply block 
(with header_checks) any emails sent to your port 25 that have your own 
email address in the 'From' header. As you will be sending through your 
server using authentication (typically port 587), your own emails will 
still pass through.

Re: Being blocked with error 554 5.7.1

[Dominic Raferd]

Interesting. Your off-list reply to mine was bounced by Google (when
our server relayed it). You wrote:

> The from header is:
> edulinkbordengrammar.kent.sch.uk
> however they've set a non-existent account as the reply to...

Those look fine to me.

But why was your message to me bounced by Google? Their bounce
response reads: 'Our system has detected that this message is
suspicious due to the nature of the content and/or the links within.
To best protect our users from spam, the message has been blocked.
Please visit https://support.google.com/mail/answer/188131 for more
information.'

You can read what Google say at that link. There is nothing in your
email that looks at all like spam to me.

Are you able to fix the DMARC entry in your DNS? It has spurious escaped quotes.

On Sat, 12 Sep 2020 at 12:15, Dominic Raferd  wrote:
>
> On Fri, 11 Sep 2020 at 22:49, Julian Pilfold-Bagwell
>  wrote:
> >
> > I have a problem that's sprung to light after we bought in a 3rd party
> > cloud provider.  I have postfix 2.10 running on Centos 7 (main.cf below)
> > and our 3rd party provider is relaying mail out via our server, using
> > authentication on a legit account.  However, the recipient ISPs reject
> > mail with the error 554 5.7.1 recipient access denied, although this
> > doesn't seem to happen on all the messages that are being sent.  If
> > we're sending say 60 messages, the first block of 20 will go through,
> > the next 20 will be blocked and the final 20 will go through.  I'm
> > guessing that the receiving end is objecting to something in the headers
> > from the relayed mail, but can't quite get to grips as to why it occurs
> > in batches.
> >
> > The 3rd party provider is sending reports to all of our end users which
> > is over a thousand emails+  so I've limited the delivery rate to 1
> > message per domain every twenty seconds  to try to appear less spammy
> > but it still happens as described.  The error message is as below:
> >
> > NOQUEUE: reject: RCPT from smtp.overnetdata.com[5.153.65.228]: 554 5.7.1
> > : Recipient address rejected: Access denied;
> > from= to=
> > proto=ESMTP helo=
> >
> > and we're receiving this from talktalk.co.uk, sky.com, yahoo.co.uk,
> > hotmail.com, outlook.com and gmail.com sometimes talks to us, and
> > sometimes doesn't.
> >
> > and main.cf is shown here:...
>
> The setup seems imperfect, and the version of postfix rather old, but
> which if any of the imperfections is causing this new problem is hard
> to say without fuller examples of what is being blocked, which I can
> well understand you might not want to post on an open forum. My
> observations are:
>
> Instead of 'smtp_use_tls = yes' it is advisable to use
> 'smtp_tls_security_level = may' (Postfix 2.3+)
>
> Your SPF entry in DNS looks ok, provided as you say that the 3rd party
> is sending your emails via your mail server and not independently.
> Also your mail server's ip is not blacklisted at any of the 129 rbls I
> regularly check, nor at https://ipremoval.sms.symantec.com/. You can
> check its status with Microsoft by registering it at their Smart
> Network Data Service.
>
> Your DMARC entry in DNS is broken, also you do not appear to be
> signing outgoing emails with DKIM. But I doubt either of these is the
> explanation for your problem.
>
> Is the third party sender using your domain in the 'From:' header as
> well as in the envelope?

Re: SMTP TLS delivery fallback

[Dominic Raferd]

On Tue, 18 Aug 2020 at 11:29, Leonardo Rodrigues
 wrote:
>
>
>  Hello Everyone,
>
>  Trying to enable smtp_tls_* on my server for allowing emails
> delivery to the world using TLS (not smtpd_tls_*, those are working just
> fine for years).
>
>  While i could get it working fine, i'm afraid that some wrongly
> configured servers, that offers TLS but have some problem on that,
> cannot receive my emails. I have configured smtp_tls_* to accept as low
> as TLSv1, but i'm afraid that even that might brake some deliveries.
>
>  Question: is there some parameter to allow smtp daemons to,
> somehow, fallback to non-TLS deliveries after, for example, N number of
> delivery tries or N seconds, for example? I have already searched on
> TLS_README.html but couldn't find anything like that. (running postfix
> 3.5.4)

smtp_tls_security_level = may

This is 'opportunistic TLS'. Normally you should not need to (and
should not) change any other smtp_tls_* settings from their defaults.

Re: non_smtp_milters don't work with spamassassin

[Dominic Raferd]

On Wed, 5 Aug 2020 at 08:36, Guido Goluke, MajorLabel
 wrote:
>
> I have a setup where I filter smtp mail with:
>
> smtpd_milters=unix:/spamass/spamass.sock,
> unix:/var/run/opendkim/opendkim.sock
>
> and non-smtp mail with
>
> non_smtpd_milters=unix:/spamass/spamass.sock,
> unix:/var/run/opendkim/opendkim.sock
>
> But when I receive non-smtp mail (typically LMTP, from a contact form
> from a website on the same server) I see no spamassassin headers. I do
> see DKIM headers though, so local miltering is working, just not for
> spamassassin. Does anyone have an idea on how I can get this to work?

I doubt it is a postfix issue. Your spamassassin may be configured so
that no headers get added unless it finds something spammy, maybe this
never happens with mail from your LMTP sources (deemed to be within
internal_networks or if there is some good filtering happening before
web contact form data is passed to postfix)?

Re: Using provider SMTP (Gmail)

[Dominic Raferd]

On Thu, 30 Jul 2020 at 16:31, Forums  wrote:
>
> This action modify "From:" and "Reply To:" when you send an email from your 
> Gmail account.
>
> I don't want to send email from a different "From:" address when I use my 
> Gmail account.
>
> The only thing I wanted is to have the good sender (xx...@mehl-family.fr) in 
> "From:" and "Reply To" when I use Gmail SMTP with my personal mail server.
>
>
> Le 30/07/2020 à 11:54, Arnold Greyling a écrit :
>
> On 23 Jul 2020, at 2:20 , Forums  wrote:
>
> Hello all.
>
> Sorry for my english I'm french.
>
> Due to some problems with my provider (using my private SMTP server prevents 
> some emails from happening, issue with IP) I have to use an external SMTP 
> (Gmail) as a relay.
>
> It works without issue but...
>
> When I send an email it is received with "From: " equal to Gmail account 
> (From: xx...@gmail.com) instead of my personnal email (From: 
> xx...@mehl-family.fr). And when receiver answer me email is sent to gmail 
> account. But sometime answer is sent to my personnal email 
> (xx...@mehl-family.fr).
>
> In the source of email I can see that "Reply-To:" is filled in with 
> "xx...@mehl-family.fr".
>
> And I see my emails sent using xx...@mehl-family.fr in "Mails sent" in my 
> Gmail account with sender=xx...@gmail.com.
>
> Must I modify something in my Postfix configuration or is the sender making a 
> mistake when he answers me?
>
>
> Gmail allows you to send mail from a different From: address
> The setup is described at https://support.google.com/mail/answer/22370
> I haven’t done this in a very long time but I did manage to achieve what you 
> want.
> Unfortunately I can’t remember what settings I used.
> Play around with the default address and alias settings to get the results 
> you want.

I don't believe Gmail permit what you want unless you have their
(paid) G Suite product (quote: "Show that you're in business and look
professional with custom email addresses at your company domain.").
The obvious solution (as already suggested here) is to get GSuite -
for one or a small number of email_addresses@yourdomain it isn't
expensive.

Otherwise, you need a mail server with *static ipv4*. (This is also
required for the solution/page to which Arnold refers, which permits
you to send emails@yourdomain using the Gmail app or the Gmail web
page). To achieve this:

- get a static ipv4 address for your mail server from your existing
provider (but they may not offer this, or it may be prohibitively
expensive)
- find a service offering free relaying (via static ipv4) from own
domain for (low volume) accounts
- rent a vps that offers static ipv4 address: this isn't free but for
>1 email address can be cheaper than G Suite

P.S. The preferred style on the postfix-users mailing list is to
bottom-post (as I have done here), not to top-post.

Re: How To Rewrite "Mail From:"?

[Dominic Raferd]

On 06/07/2020 20:53, Viktor Dukhovni wrote:

On Mon, Jul 06, 2020 at 07:40:27PM +, Drew Tomlinson wrote:


I use postfix for my own domain and have been forwarding my email to
outlook.com for years.  Recently, email has just been disappearing
between my server and my inbox so I set it to forward my email to
gmail.com.  Shortly after, I saw some messages like these in the logs:

You're running into intentional breakage caused by SPF and DMARC.
Sadly, this means that (simple) mail forwarding no longer works
reliably.


In reading Google documentation, I learned SPF is failing.  Further
reading revealed this is a common problem with forwarded email since
it is not being sent by an authorized IP address.  Other articles
suggested the workaround for this is to change the "Mail From:" to
reflect my domain since I have SPF configured for it.  And maybe this
is what is meant by SRS (Sender Rewriting Scheme)?

Even changing the envelope sender is not enough.  With DMARC you
need to also change the "From:" header in the message.

The simplest thing to do is to encapsulate the original message
as attachment to a new message.

 From: 
 To: 
 Subject: forwarded message from: 
 MIME-Version: 1.0
 Content-Type: message/rfc822

 Return-Path: 
 Received: ...
 ... original message header ...

 ... original message body

You'd need to forward your mail to a script that performs the
requisite encapsulation.  There are multiple ways to do that.
Nothing directly built-in.


OP might find useful my relay-enforcer script at 
https://www.timedicer.co.uk/programs/help/relay-enforcer.sh.php which 
was written for precisely this situation. There is also guidance on how 
to configure DSN code rewriting accordingly.

Re: sendmail_fix_line_length enhancement request

[Dominic Raferd]

On 18/06/2020 17:17, Dominic Raferd wrote:

On Thu, 18 Jun 2020 at 15:03, Wietse Venema  wrote:

Dominic Raferd:

I understand the reason for smtp_line_length_limit and for its default
value of 998, which is of course good.

It breaks DKIM signatures, it is needed only for mail that is sent
via SMTP, and worse, it breaks lines in the middle of a multibyte
character (and of course in the middle of a word, in the middle of
an HTML tag, and so on). So it really shuod not be considered a
reliable solution.

The main reason smtp_line_length_limit exists is to prevent other
MTAs from breaking MIME-formatted mail, where one huge message
header could cause all message content to become exposed in the
underlying encoding (base64 or quoted-printable).

If your problem is with cron job outputs that aren't sent across
the Internet, you could just disable this behavior by setting the
limit to zero, and by configuring other MTAs similarly.

Alternatively, as these cron jobs are under local control, you could
massage their output through a program that fixes long lines.


Thanks for your answer and explanation.

Your second suggestion is what I do, but it is difficult to catch all
instances. I have now followed your first and set the limit to zero
(which I believe is undocumented as a way to turn off automatic
line-breaking). Actually I am relaying into Gmail so it will be
interesting to see if it copes with overlong lines.
For information: setting smtp_line_length_limit = 0 works, however 
having such a long line (in the mail body) still breaks the DKIM 
signature. There must be something else going on (presumably unrelated 
to postfix).

Re: sendmail_fix_line_length enhancement request

[Dominic Raferd]

On Thu, 18 Jun 2020 at 15:03, Wietse Venema  wrote:
>
> Dominic Raferd:
> > I understand the reason for smtp_line_length_limit and for its default
> > value of 998, which is of course good.
>
> It breaks DKIM signatures, it is needed only for mail that is sent
> via SMTP, and worse, it breaks lines in the middle of a multibyte
> character (and of course in the middle of a word, in the middle of
> an HTML tag, and so on). So it really shuod not be considered a
> reliable solution.
>
> The main reason smtp_line_length_limit exists is to prevent other
> MTAs from breaking MIME-formatted mail, where one huge message
> header could cause all message content to become exposed in the
> underlying encoding (base64 or quoted-printable).
>
> If your problem is with cron job outputs that aren't sent across
> the Internet, you could just disable this behavior by setting the
> limit to zero, and by configuring other MTAs similarly.
>
> Alternatively, as these cron jobs are under local control, you could
> massage their output through a program that fixes long lines.
>

Thanks for your answer and explanation.

Your second suggestion is what I do, but it is difficult to catch all
instances. I have now followed your first and set the limit to zero
(which I believe is undocumented as a way to turn off automatic
line-breaking). Actually I am relaying into Gmail so it will be
interesting to see if it copes with overlong lines.

> The sendmail command is a bad place for doing this, why not the
> cleanup daemon?

Answering that question is way above my pay grade.

sendmail_fix_line_length enhancement request

[Dominic Raferd]

I understand the reason for smtp_line_length_limit and for its default
value of 998, which is of course good.

But it is an occasional problem for me that this wrapping action is
only applied at smtp stage and not earlier; in particular it is after
any (open)dkim milter adds its key, because smtp's wrapping means that
the key then becomes invalid.

The standard answer would be that it is the responsibility of an MUA
to ensure that emails do not break the RFC, so then smtp would not
have to fix a problem that is not of its own making.

But postfix's sendmail does not honour the RFC or the
smtp_line_length_limit value and happily submits emails with overlong
lines, and this is where my problem occasionally arises, say when
emailing output from a cron job.

I have various workarounds, and can imagine more. But the elegant
solution would be to make postfix's sendmail program honour and
enforce the smtp_line_length_limit parameter, or (better, and
backwards-compatible) to create another parameter dictating whether
sendmail would do this (e.g. sendmail_fix_line_length as
yes/no[default]). Obviously the limit should be applied after any
sendmail_fix_line_endings setting has been processed. Or an entirely
independent sendmail_line_length_limit parameter could be created (if
it is awkward to have sendmail honouring an smtp_ parameter).

Is that possible or is it a bad idea?

Re: Unable to receive emails from btinternet.com

[Dominic Raferd]

On Thu, 18 Jun 2020 at 09:46, David Hartley  wrote:
>
> I am running Postfix on a Synology NAS using DSM 6.2
>
> In general I can receive emails, however I cannot receive emails
> from@ btinternet.com.
>
> An example of the sender's failure report is:
>
> Reporting-MTA: dns; sa-prd-fep-040.btmx-prd.synchronoss.net
> Arrival-Date: Wed, 27 May 2020 18:31:52 +0100
> Received-From-MTA: dns; sa-prd-rgout-001.btmx-prd.synchronoss.net
> (10.2.38.4)
>
> Final-Recipient: RFC822; 
> Action: failed
> Status: 4.4.7
> Remote-MTA: dns; xxx.uk
> Diagnostic-Code: smtp; 250 2.1.5 Ok
>
> The Postfix log sees the BT mail server connect, but does not receive
> any data:
>
> 2020-06-09T12:04:00+01:00  postfix/smtpd[7356]: connect from
> mailomta12-sa.btinternet.com[213.120.69.18]
> 2020-06-09T12:04:01+01:00  postfix/smtpd[7356]: Anonymous TLS
> connection established from mailomta12-sa.btinternet.com[213.120.69.18]:
> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> 2020-06-09T12:04:01+01:00  postfix/smtpd[7356]: A33018C5A8C:
> client=mailomta12-sa.btinternet.com[213.120.69.18]
>
> 2020-06-09T12:09:01+01:00  postfix/smtpd[7356]: timeout after
> DATA (0 bytes) from mailomta12-sa.btinternet.com[213.120.69.18]
> 2020-06-09T12:09:02+01:00  postfix/smtpd[7356]: disconnect
> from mailomta12-sa.btinternet.com[213.120.69.18] ehlo=2 starttls=1
> mail=1 rcpt=1 data=0/1 commands=5/6
>
> Can anyone suggest what the problem is here please?
>
> Is is a problem at my end, or a problem at btinternet.com?

All incoming emails from BT (mailomta[0-9]+-sa\.btinternet\.com) have
been received by our mailservers ok, the most recent was yesterday

See the accepted answer at
https://serverfault.com/questions/295409/how-to-solve-error-550-4-4-7

I suspect some firewalling action either on your mailserver or on an
intermediate router.

Re: Mail being delivered to incorrect address

[Dominic Raferd]

On Thu, 18 Jun 2020 at 08:13, David Hobley 
wrote:

> Sorry, that got sent prior to my completing the email. I'll try again.
>
> /etc/postfix/main.cf
> alias_maps =
> append_dot_mydomain = no
> compatibility_level = 2
> ...
> myorigin = /etc/mailname

...
> virtual_alias_domains =
> virtual_alias_maps = hash:/etc/postfix/virtual
> virtual_mailbox_domains = domain1.com, domain2.com, domain3.com
> virtual_mailbox_maps = mysql:/etc/postfix/mysql-users.cf
> virtual_transport = lmtp:unix:/kopano/dagent.sock
>
> The virtual aliases look like:
> user1firstname.lastn...@domain3.com user1firstname.lastname
>
> user2firstn...@domain2.com user2firstname.lastname
> user2firstn...@domain1.com user2firstname.lastname
> user2firstname.lastn...@domain2.com user2firstname.lastname
>
> @domain3.com user2firstname.lastname
> @domain2.com user1firstname.lastname
> @domain1.com  user1firstname.lastname
>
>
> In effect, I have 3 users created for domain1.com. A catchall for domain1
> and domain2 to direct to user 1. Ignore domain3 for the time being.
>
> For some reason though, all emails are ending up in user1’s Inbox. If I
> send an email from an external email address to
> user2firstname.lastn...@domain1.com it ends up in
> user1firstname.lastname’s email. If I send an email to
> user2firstn...@domain2.com it also ends up in user1firstname.lastname's
> email.
>
> Interestingly, if I remove the @domain1.com catchall in the
> /etc/postfix/virtual file, email gets delivered correctly to
> user2firstname.lastn...@domain1.com and user2firstn...@domain2.com...
>
> Can anyone point me in the correct direction please. I have spent a couple
> of days on this trying to work out where I have gone wrong and I am
> mystified. Happy to provide a more full-featured config if that helps.
>

You presumably have the default setting:
append_at_myorigin = yes

Refer to http://www.postfix.org/virtual.5.html. Bear in mind that
processing of virtual alias table is recursive.

So: the first time, user2firstn...@domain2.com is rewritten to
user2firstname.lastn...@domain1.com (i.e. the 'myorigin' is appended, I am
guessing domain1.com is set in /etc/mailname)

Because a change occurred this is then passed back through the same file
and (unless you remove the @domain1.com catchall) gets rewritten to
user1firstname.lastn...@domain1.com

Re: Postfix restrictions

[Dominic Raferd]

On Mon, 8 Jun 2020 at 16:11, PGNet Dev  wrote:

> On 6/8/20 7:12 AM, Dominic Raferd wrote:
> > main.cf <http://main.cf>:
> > 
> > rbl_reply_maps = pcre:/etc/postfix/rbl_reply_maps.pcre
> > postscreen_dnsbl_reply_map =
> pcre:/etc/postfix/postscreen_dnsbl_reply_map.pcre
> > 
> >
> > # cat /etc/postfix/rbl_reply_maps.pcre
> > /[a-z0-9]*\.([a-z]*\.dq\.spamhaus\.net)/ $$rbl_code Service unavailable;
> $$rbl_class [$$rbl_what] blocked using ${1}$${rbl_reason?; $$rbl_reason}
> > # cat /etc/postfix/postscreen_dnsbl_reply_map.pcre
> > /[a-z0-9]*\.([a-z]*\.dq\.spamhaus\.net)/ ${1}
>
> ah, thx!
> that seems to work nicely -- for the SMTP reply; doesn't affect the
> dnsblog output (yet; poking around now)
> tho, reading some other examples I've now found in posts -- why the double
> "$$" here?
> reading http://www.postfix.org/pcre_table.5.html I do see ...


This was discussed before:
https://www.mail-archive.com/postfix-users@postfix.org/msg85706.html

Re: Postfix restrictions

[Dominic Raferd]

On Mon, 8 Jun 2020 at 15:07, PGNet Dev  wrote:

>
> in my logs, i see, e.g.
> Jun  8 06:49:08 mx postfix/dnsblog[21103]: addr 151.20.170.84
> listed by domain .zen.dq.spamhaus.net as 127.0.0.10
>
> with the "" clearly displayed.
>
> have you a setting/map in postfix that simply prevents/filters the
> "" value from explicit entry in the logs?
>

main.cf:

rbl_reply_maps = pcre:/etc/postfix/rbl_reply_maps.pcre
postscreen_dnsbl_reply_map =
pcre:/etc/postfix/postscreen_dnsbl_reply_map.pcre


# cat /etc/postfix/rbl_reply_maps.pcre
/[a-z0-9]*\.([a-z]*\.dq\.spamhaus\.net)/ $$rbl_code Service unavailable;
$$rbl_class [$$rbl_what] blocked using ${1}$${rbl_reason?; $$rbl_reason}
# cat /etc/postfix/postscreen_dnsbl_reply_map.pcre
/[a-z0-9]*\.([a-z]*\.dq\.spamhaus\.net)/ ${1}

Re: Alternative SMTP server

[Dominic Raferd]

On Mon, 8 Jun 2020 at 09:54, Forums  wrote:

> Hello all.
>
> Sorry for my english I'm french.
>
> I have a private mail server (at home) with my domain name.
>
> I have about 5% of my emails rejected by some SMTP servers for the
> following reasons:
>
> - rDNS is KO (my french provider don't give us possibility to create or
> modify our rDNS)
>
> Or
>
> - mail server IP comes from a dynamic pool IP (but my IP is static)
>
> So, my idea is to use automatically (managed by Postfix) an alternative
> SMTP server (Gmail SMTP with my Google account) when an email is
> rejected. But I don't know if it's possible and how to configure that.
>

I don't think you can send through Gmail smtp using your own domain name on
the From header unless you have GSuite, but you can do it with a free
low-volume account at Sendgrid.

I am not sure about relaying in the event of rejection, someone else can
maybe advise. Alternatively, and assuming your volumes are low, you could
just relay all your outgoing mails through [Sendgrid or another].

Command line simulation of postfix ip-matching syntax

[Dominic Raferd]

Is there a command-line tool that can simulate postfix's ip-matching syntax
with semicolons and double dots?

# echo "127.0.0.3"|grepcidr "127.0.0.[1;3;5]"
grepcidr: Not a valid pattern: 127.0.0.[1;3;5]
# echo "127.0.0.3"|grepcidr "127.0.0.[1..5]"
grepcidr: Not a valid pattern: 127.0.0.[1..5]

Re: Uninstalling postgrey

[Dominic Raferd]

On Mon, 25 May 2020 at 02:06, Ian Evans  wrote:
>
> Based on another thread here, I want to move to using postscreen/postwhite 
> and ditch postgrey.
>
> Just want to make sure I don't bungle stopping postgrey.
>
> So...
>
> - edit main.cf and remove "check_policy_service inet:127.0.0.1:10023" from 
> smtpd_recipient_restrictions.
> - restart Postfix
> - purge the postgrey package.
>
> Then go about getting postscreen working.

I suggest that you get postscreen (and maybe postwhite) working first.
And before (or after) purging postgrey do: rm -rf /etc/postgrey.

I can't try postwhite because it depends on spf-tools, which don't
have install instructions for people who aren't git experts.

Re: dnsblog_query: lookup error for DNS query x.x.x.x.zen.spamhaus.org: Host or domain name not found.

[Dominic Raferd]

On Fri, 8 May 2020 at 16:09, Alexander Meinhardt
 wrote:
> for inexplicable reasons i don't get any results from zen.spamhaus.org 
> anymore:
>
> Apr 08 16:20:29 [postfix/dnsblog] warning: dnsblog_query: lookup error
> for DNS query x.x.x.x.zen.spamhaus.org: Host or domain name not found.
> Name service error for name=x.x.x.x.zen.spamhaus.org type=A: Host not
> found, try again
>
> I knew the free-to-use requirements from Spamhaus and i didn't think
> that i ever would reach this regulations. (non-commercial, less than
> 100.000 smtp/day, less 300.000 queries/day)
>
> As local DNS resolver i am using unbound which interacts with Spamhaus.
> For a fallback solution, whenever unbound isn't accessible for
> whatever reason, i added my provider (Hetzner) nameservers as well.
>
> nameserver ::1
> nameserver 127.0.0.1
> nameserver 213.133.99.99
> nameserver 213.133.100.100
> nameserver 213.133.98.98
> nameserver 2a01:4f8:0:a111::add:9898
> nameserver 2a01:4f8:0:a102::add:
> nameserver 2a01:4f8:0:a0a1::add:1010
>
> Since a month i am getting no such results from Spamhaus anymore, so i
> stopped using them via Postfix.
>
> My setup contains approx 10 email addresses which receive approx 30-40
> emails/day.
>
> Can i do something to revert this blocking from Spamhaus?
> Like not quering for x days the list or so?
> Any other solutions?

A possible cause is that you are not using your own DNS resolver but
instead relying on a third party (such as your ISP), and their
resolver has been blocked by Spamhaus for over-usage. In which case
you need to set up your own DNS resolver (e.g. bind) and use this
instead, ensuring it does not forward DNS queries through a
third-party resolver.