[pfx] Re: long header folding and DKIM fails

[Scott Kitterman via Postfix-users]

On April 29, 2024 9:27:20 PM UTC, Steffen Nurpmeso via Postfix-users 
 wrote:
>Tim Coote via Postfix-users wrote in
> :
> |Thanks very much for the detailed response. My original issue was why \
> |dkim signatures were failing on some emails from email lists when arriving \
> |at my Postfix based domain (postfix-3.4.10-1.fc30.x86_64 - I know it \
> |needs updating: and that may be the only reasonable answer). I have \
> |only seen this sort of issue from two sources. So I tried subscribing \
> |to one of them with a gmail address and found the folded header differen\
> |ce, which, if the lines were merged meant that dkim signature verification \
> |worked (using dkimpy).  (tbh, I thought I’d done very well at this \
> |point as I’d spotted what had gone wrong for DKIM).
> |
> |That’s why I formed a hypothesis that (my) Postfix had changed this \
> |long header - as you note this is < 998 stmp limit. I presume it’s \
> |not directly involved now, as smtp_line_length_limit is the default (998)
> |
> |So, I tried creating an email using python and sending that to an account \
> |in my domain - that had the same  inserted after the \
> |‘,’ in the ‘List-Unsubscribe’ header. But if I use the python to send \
> |to an account in gmail, the behaviour is different from the externally \
> |sourced email as the 'List-Unsubscribe’, when observed with the gmail \
> |client in a browser does have an extra , but no .
> |
> |I clearly need to do several more experiments to work out what is going \
> |on.  It’s non-trivial when you control so little of the whole chain.
>
>Note that in practice only exim and the DKIM library it uses (from
>2009) produce really standard-conforming results, all other
>implementations i have tested have some edge cases.  For example,
>opendkim and rspamd (as of git) use (at least in pars, or always)
>the C function isspace(3) to normalize whitespace, which is not
>allowed according to the DKIM RFC.  They all do it wrong.  The
>most minimum and in practice very likely non-failing (or not at
>all) is dkimpy (which uses the python function trim(), but only as
>the very last step).  My upcoming sign-only milter will only
>support relaxed/relaxed, but is hard-conforming, too.


If you have examples of cases where dkimpy is wrong, please file bugs or email 
me off list.  It aims to support the RFC requirements with only minimal tweaks 
for interoperability.

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

[pfx] Re: Postfix stable release 3.9.0

[Scott Kitterman via Postfix-users]

On Thursday, March 7, 2024 12:09:51 PM EDT Wietse Venema via Postfix-users 
wrote:
> Postfix stable release 3.9.0 is available. Postfix 3.5 - 3.8 were
> updated earlier this week; after that, Postfix 3.5 will no longer
> be updated.
> 
> The main changes are below. See the RELEASE_NOTES file for further
> details.

I updated Debian's Postfix package for 3.9.0 yesterday (for internal distro 
reasons it's not available yet, but it will be 'soon').  It was very smooth 
and (as usual) well documented.  Absolutely the only problems I had were 
related to my occasional inability to type what I meant to and my inability to 
notice I'd typed something else until having stared at the problem for far too 
long.

Thanks, not just for the new release, but the excellent documentation that 
came with it.

Scott K


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

[pfx] Re: Milter multiline header formatting

[Scott Kitterman via Postfix-users]

On March 6, 2024 7:37:47 PM UTC, Steffen Nurpmeso via Postfix-users 
 wrote:
>Hello Wietse Venema :)
>
>Wietse Venema via Postfix-users wrote in
> <4tqhxw0ksyzj...@spike.porcupine.org>:
> |Steffen Nurpmeso via Postfix-users:
> |> Wietse Venema via Postfix-users wrote in
> |>  <4tqh100n6pzj...@spike.porcupine.org>:
> |>|Are you trying to say that Postfix represents a multiline message
> |>|header as text with \n instead of \r\n?
> |> 
> |> Yes.
> ...
> |>|I agree that \r\n would be better, but I'm surprised that this has
> |>|not come up before.
> ..
> |Every Received: header is multiline, and it is not unusual to have
>
>These are not "usually" DKIM signed i'd say.
>
> |multiline Subject:, To:, and other common headers.
>
>Yes.
>
> |Again, Postfix does not store line terminators, not when email comes
> |from UNIX tool with \n, via SMTP with \r\n, or encapsulated as
> |netstrings which uses neither. 
>
>OK then there is nothing i can do on the MUA side.
>
> |Instead, Postfix generates line terminators upon output, and until
> |now they are always \n.
> |
> |Postfix systems have been signing with Milters since Postfix Milter
> |support was added in 2006. I'm just surprised that the non-canoncal
> |line endings in a multiline header have not been a problem before.
>
>My milter now treats LF and CR not in a CRLF as real whitespace.
>The email i just sent was accepted by Google, this one should also
>wrap, and we see what this software does (rspamd is it i think).
>
>So it seems to me, without having looked what OpenDKIM does, and
>maybe i should explicitly Cc: Scott Kitterman for his dkimpy, but
>i know he is on this list, just let's wait a bit, that all these
>DKIM milters do it falsely, and treat LF and CR other than the
>combination of CRLF as whitespace.  Even though WSP is defined by
>"RFC 5234, B.1.  Core Rules:" as "WSP= SP / HT; white space",
>and that is what the DKIM and email standards go for.  For the
>latter i explicitly asked a month or so ago.
>So they break the email standard, postfix does, too, and in
>combination all is fine again.

As far as I know, we're doing it mostly correctly I'm dkimpy (see below).  It's 
used in lots of ways that have nothing to do with postfix, so I am strongly 
inclined to believe it's right or there would have been lots of reports of 
interoperability issues.  I am up to my eyeballs in other stuff at the moment, 
so there's no way I can even contemplate time for a code review in the absence 
of a known issue.

One thing that may be a factor is the canonicalization algorithm being used.  I 
tried simple early on, but it proved to be fragile.  I suspect (but equally 
haven't recently checked) most are using relaxed canonicalization.  For the 
header, line endings don't matter for it since you unfold everything.  The 
'simple' canonicalization is easy to implement, but very fragile.  It is, in 
fact, bad enough that even if you tell dkimpy to use simple for the header, it 
does relaxed anyway.  For the body it will do whichever is specified.

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

[pfx] Re: problem to add, alias failed

[Scott Kitterman via Postfix-users]

On Tuesday, January 30, 2024 1:57:18 PM EST Maurizio Caloro via Postfix-users 
wrote:
> if adding a new user with postfixadmin 3.3.8 or with cli this will run
> without problem.
> 
> 
> 
> GRANT ALL PRIVILEGES ON mailserver.* TO markus@'domain.com
>  ' IDENTIFIED BY
> '***';
> 
> FLUSH PRIVILEGES;
> 
> also on the DATABASES i see the entry
> 
> 
> 
> Debian 11.8
> 
> Postfix 3.5.23
> 
> mysql 10.5.21-MariaDB
> 
> 
> 
> but if adding with postfixadmin any alias, this will bounce, with following
> error
> 
> 
> 
> postfix/lmtp[102470]: 3E101208A1: to= 
> mar...@domain.com, relay=mail.domain.com[private/dovecot-lmtp],
> 
> delay=0.12, delays=0.06/0.01/0.02/0.02, dsn=5.1.1, status=bounced (host
> mail.domain.com[private/dovecot-lmtp]
> 
> said: 550 5.1.1 mar...@domain.com   User doesn't
> exist: mar...@domain.com   (in reply to RCPT TO
> command))
> 
> 
> 
> added :
> virtual_transport = lmtp:unix:private/dovecot-lmtp
> 
> 
> 
> please i dont see the mistake, thanks for any possible update

This may be due to a Debian specific mix of mariadb versions.  In stable 
(bookworm) we initially had trouble with the mysql extensions due to a mariadb 
bug.  It was fixed and rebuilding postfix against the newer mariadb released 
solved it.

The postfix version you have was built using a mariadb version that's older 
than the one currently in oldstable-proposed-updates (bullseye).  You 
installed it either from bullseye-updates or bullseye-proposed updates 
(packages for the newer version were only released yesterday).

There are updates for the next bullseye point release staged in bullseye-
proposed-updates for both postfix (3.5.24) and mariadb.  Please try installing 
both the newer postfix (which is built against the newer mariadb) and the newer 
mariadb from bullseye-proposed-updates.  If there was a similar problem in 
bullseye to what we saw in bookworm, then that should solve it.

Please let us know how it works out.

Scott K



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

[pfx] Re: Postfix and reproducible builds

[Scott Kitterman via Postfix-users]

I expected the same, but our CI test for reproducibility passed without it.  I 
was surprised.  Hopefully I'm about to learn something.

Scott K

On January 30, 2024 4:00:59 PM UTC, Matus UHLAR - fantomas via Postfix-users 
 wrote:
>On 30.01.24 10:12, Scott Kitterman via Postfix-users wrote:
>> It looks to me like it does fix it.
>
>Isn't/was't the sort important? (I'd expect it to be)
>
>> On Tuesday, January 30, 2024 9:14:09 AM EST Wietse Venema via Postfix-users
>> wrote:
>>> Scott Kitterman via Postfix-users:
>>> > In case anyone is unfamiliar, you can read about reproducible builds here:
>>> > reproducible-builds.org
>>> >
>>> > It looks like Postfix as shipped is very close to being reproducible.  We
>>> > got positive results on reproducibility with the patch below added.  Is
>>> > this something you could include in a future release?
>>> 
>>> I have "LC_ALL=C" at the top of many shell files, but forgot the
>>> makedefs script. Can you confirm that this fixes the problem?
>>> 
>>> Doing "LC_ALL=C" in the middle of one command means we can re-introduce
>>> the problem again with some other change.
>>> 
>>> Wietse
>>> 
>>> --- /var/tmp/postfix-3.9-20240129/makedefs  2024-01-04 12:50:28.0
>>> -0500 +++ ./makedefs2024-01-30 09:05:47.198434044 -0500
>>> @@ -184,6 +184,8 @@
>>>  #  New York, NY 10011, USA
>>>  #--
>>> 
>>> +LC_ALL=C; export LC_ALL
>>> +
>>>  # By now all shells must have functions.
>>> 
>>>  error() {
>>> 
>>> > Scott K
>>> >
>>> > diff --git a/makedefs b/makedefs
>>> > index d9dc529..2b376b3 100644
>>> > --- a/makedefs
>>> > +++ b/makedefs
>>> > @@ -211,7 +211,7 @@ echo
>>> > "#"
>>> >
>>> >  echo "# Start of summary of user-configurable 'make makefiles' options."
>>> >  echo "# CCARGS=$CCARGS"
>>> >  echo "# AUXLIBS=$AUXLIBS"
>>> >
>>> > -env | grep '^AUXLIBS_' | sed 's/^/# /'
>>> > +env | grep '^AUXLIBS_' | sed 's/^/# /' | LC_ALL=C sort
>>> >
>>> >  echo "# shared=$shared"
>>> >  echo "# dynamicmaps=$dynamicmaps"
>>> >  echo "# pie=$pie"
>
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix and reproducible builds

[Scott Kitterman via Postfix-users]

It looks to me like it does fix it.

Thanks,

Scott K


On Tuesday, January 30, 2024 9:14:09 AM EST Wietse Venema via Postfix-users 
wrote:
> Scott Kitterman via Postfix-users:
> > In case anyone is unfamiliar, you can read about reproducible builds here:
> > reproducible-builds.org
> > 
> > It looks like Postfix as shipped is very close to being reproducible.  We
> > got positive results on reproducibility with the patch below added.  Is
> > this something you could include in a future release?
> 
> I have "LC_ALL=C" at the top of many shell files, but forgot the
> makedefs script. Can you confirm that this fixes the problem?
> 
> Doing "LC_ALL=C" in the middle of one command means we can re-introduce
> the problem again with some other change.
> 
>   Wietse
> 
> --- /var/tmp/postfix-3.9-20240129/makedefs2024-01-04 12:50:28.0
> -0500 +++ ./makedefs  2024-01-30 09:05:47.198434044 -0500
> @@ -184,6 +184,8 @@
>  #New York, NY 10011, USA
>  #--
> 
> +LC_ALL=C; export LC_ALL
> +
>  # By now all shells must have functions.
> 
>  error() {
> 
> > Scott K
> > 
> > diff --git a/makedefs b/makedefs
> > index d9dc529..2b376b3 100644
> > --- a/makedefs
> > +++ b/makedefs
> > @@ -211,7 +211,7 @@ echo
> > "#"
> > 
> >  echo "# Start of summary of user-configurable 'make makefiles' options."
> >  echo "# CCARGS=$CCARGS"
> >  echo "# AUXLIBS=$AUXLIBS"
> > 
> > -env | grep '^AUXLIBS_' | sed 's/^/# /'
> > +env | grep '^AUXLIBS_' | sed 's/^/# /' | LC_ALL=C sort
> > 
> >  echo "# shared=$shared"
> >  echo "# dynamicmaps=$dynamicmaps"
> >  echo "# pie=$pie"
> > 
> > ___
> > Postfix-users mailing list -- postfix-users@postfix.org
> > To unsubscribe send an email to postfix-users-le...@postfix.org
> 
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org




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

[pfx] Postfix and reproducible builds

[Scott Kitterman via Postfix-users]

In case anyone is unfamiliar, you can read about reproducible builds here: 
reproducible-builds.org

It looks like Postfix as shipped is very close to being reproducible.  We got 
positive results on reproducibility with the patch below added.  Is this 
something you could include in a future release?

Thanks,

Scott K

diff --git a/makedefs b/makedefs
index d9dc529..2b376b3 100644
--- a/makedefs
+++ b/makedefs
@@ -211,7 +211,7 @@ echo 
"#"
 echo "# Start of summary of user-configurable 'make makefiles' options."
 echo "# CCARGS=$CCARGS"
 echo "# AUXLIBS=$AUXLIBS"
-env | grep '^AUXLIBS_' | sed 's/^/# /'
+env | grep '^AUXLIBS_' | sed 's/^/# /' | LC_ALL=C sort
 echo "# shared=$shared"
 echo "# dynamicmaps=$dynamicmaps"
 echo "# pie=$pie"


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

[pfx] Re: postfix repo

[Scott Kitterman via Postfix-users]

On January 16, 2024 3:11:37 AM UTC, Peter via Postfix-users 
 wrote:
>On 12/01/24 04:08, Wietse Venema via Postfix-users wrote:
>> Viktor Dukhovni via Postfix-users:
>>> On Thu, Jan 11, 2024 at 03:53:35PM +0100, natan via Postfix-users wrote:
 Hi Wietse Have you thought about postfix repo for Debian, just like dovecot
 has for his relase ?
 
>>> 
>>> What is a "Postfix repo for Debian"?  Do you mean binary release
>>> packages?  What's wrong with the packages from the Debian maintainers?
>> 
>> If he means Postfix distributing BINARY packages for Debian, RedHat,
>> *BSD, and so on, then I do not expect that to happen.
>
>As many are aware Ghettoforge builds these for EL.  To me the simplest way for 
>Debian and other distros is for a community member to take up the mantle and 
>build Postfix in a similar way.  It's not that difficult to do and it puts the 
>responsibility on someone who is genuinely interested in that particular 
>platform instead of putting the responsibility on Wietse to try to build 
>binary rpms for every distro under the sun.
>
You can actually install RPMs on Debian systems, but it would be a pretty 
unusual way to go about things.  I think for almost every one, the Debian 
stable updates that we provide should be sufficient.  For those that actually 
need the latest release, it's trivial to grab the Debianized source from a 
later release and build it for an earlier release.

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

[pfx] Re: postfix repo

[Scott Kitterman via Postfix-users]

On January 11, 2024 2:53:35 PM UTC, natan via Postfix-users 
 wrote:
>Hi Wietse Have you thought about postfix repo for Debian, just like dovecot 
>has for his relase ?
>
>I'm asking by the way

Current postfix updates for supported Debian releases are available through 
Debian:

https://lists.debian.org/debian-stable-announce/2023/12/msg4.html

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

[pfx] Re: SMTP Smuggling, workarounds and fix

[Scott Kitterman via Postfix-users]

On December 30, 2023 3:17:52 PM UTC, "Håkon Alstadheim via Postfix-users" 
 wrote:
>Just FYI, I got postfix 3.7.9-0+deb12u1 from bookworm-updates (i.e. Debian) 
>today.
>
For those still using Debian Bullseye (oldstable), postfix 3.5.23-0+deb11u1 is 
also available from bullseye-updates.  Both of these stable updates were 
released yesterday.

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

[pfx] Re: sasl_passwd hash

[Scott Kitterman via Postfix-users]

Cyrus SASL mailing lists can be found here:

https://cyrus.topicbox.com/groups

Scott K

On December 17, 2023 1:45:02 PM UTC, "saunders.nicholas--- via Postfix-users" 
 wrote:
>Would you be able to point me to anyone there, or a contact?
>
>I'm not seeing any contact information.
>
>thanks,
>
>Nick
>
>
>On Sun, 17 Dec 2023, Wietse Venema via Postfix-users wrote:
>
>> saunders.nicholas--- via Postfix-users:
>>> /etc/postfix/sasl/sasl_passwd  is where I have it.  The example is:
>> 
>> That file is mainained by Cyrus SASL. Questions about implementation
>> details are bettere asked there.
>> 
>>  Wietse
>> ___
>> Postfix-users mailing list -- postfix-users@postfix.org
>> To unsubscribe send an email to postfix-users-le...@postfix.org
>> 
>___
>Postfix-users mailing list -- postfix-users@postfix.org
>To unsubscribe send an email to postfix-users-le...@postfix.org
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Milter own Postfix-prepended Received

[Scott Kitterman via Postfix-users]

On December 10, 2023 3:54:13 PM UTC, Carlos Velasco via Postfix-users 
 wrote:
>
>Wietse Venema via Postfix-users escribió el 10/12/2023 a las 15:53:
>> Carlos Velasco via Postfix-users:
>>> 2. Duplicated SMTP Access Policy Delegation
>>> This issue is related to headers too.
>>> I'm using pypolicyd-spf as policy daemon to check SPF. It is working fine.
>>> The execution happens before milter. This is ok.
>>> Prepended "Received-SPF" header by pypolicyd-spf show up in the milter. 
>>> This is ok.
>>> But in the final email, the one received by the IMAP server,
>>> "Received-SPF" header is duplicated, one in the location shown at
>>> the milter process (heder callback), but another new one, just
>>> above the "own Postfix-prepended Received: header". This is weird.
>> If the milter adds Received-SPF twice, then you are processing a message
>> twice with that Milter.
>> 
>> Output from:
>> 
>> postconf -n
>> postconf -Mf
>> 
>> Is requuired fo further support.
>
>I have collected the postconfs (see below), but I I've done some tests and I 
>think I know what's happening.
>Please note that "Received-SPF" is not coming from milter, it comes from 
>policy daemon (inside smtpd_recipient_restrictions: check_policy_service 
>unix:private/policyd-spf).
>
>So, policyd-spf is executed first, along all smtpd_recipient_restrictions. 
>After, in the milter, the first header to show up in header callback is this 
>"Received-SPF".
>Now comes the "weird thing"... If I don't touch headers in the milter, all is 
>fine, "Received-SPF" is not duplicated, but note that, in the final email, 
>this header is located *above* own Received (the one missing in milter, that 
>is, my point 1).
>
>Test 1: If I delete this "Received-SPF" header in the milter (with chgheader 
>with index 1 and undef), the header still show up in the final email, again, 
>above own Received.
>Test 2: Delete this "Received-SPF" header in the milter (chgheader) and 
>recreate again (with addheader). Then duplicated "Received-SPF" headers show 
>up in the final email, one above own Received and another one in the placer 
>inserted by the milter.
>
>So, I think there is a "ghost" Received-SPF header coming from policyd that 
>doesn't works well with the milter.
>
>Info: the reason to delete/add headers is because the filter can, sometimes, 
>change the whole mail, so the headers are first deleted and then recreated, 
>this is how I hit this weird issue.
>
>As a workaround, I can just ignore/delete the "Received-SPF" header in the 
>milter, as it is *always* there in the final mail, above own Received.
>

That means you are somehow calling the policy server twice.

You didn't mention what version of the SPF policy server you are using.  Recent 
versions (under the project name SPF Engine, since it's not just a policy 
server anymore) also provide a milter front end if you would rather do all the 
processing in milters.  It uses the same SPF processing code, so it's merely a 
choice of how you would prefer to integrate with Postfix.

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

[pfx] Re: Recommendation for dkim signing

[Scott Kitterman via Postfix-users]

On November 6, 2023 12:39:35 PM UTC, Scott Kitterman via Postfix-users 
 wrote:
>
>
>On November 6, 2023 10:51:06 AM UTC, Patrick Ben Koetter via Postfix-users 
> wrote:
>>* Jens Hoffrichter via Postfix-users :
>>> Hi!
>>> 
>>> We are looking into implementing DKIM signing for one of our services,
>>> and there are multiple ways to implement that.
>>> 
>>> So far I have found that you can do it with opendkim and amavis - any
>>> recommendation for one or the other, or maybe something completely
>>> different I haven't found yet?
>...
>>dkimpy-milter::
>>dkimpy-milter supports RSA-SHA256 and ED25519-SHA256. If you have
>>experience running opendkim you will feel at home using dkimpy-milter.
>>dkimpy-milter used to have and I don't know if it still has problems
>>handling email message headers containing UTF-8 chars when there shouldn't
>>be any, like in a Subject that reads "Passwort zurücksetzen", which MUST
>>be ISO encoded, but then there are developers who don't know that and …
>>dkimpy-milter crashes because of the way Python 3.x handles UTF-8. I've
>>no idea if Scott has found time to address and fix that.
>...
>
>This is fixed.  It still does properly implement support for non-ASCII 
>headers, but the crashes should be a thing of the past.
>
Sigh.  That should have been ... doesn't ...

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

[pfx] Re: Recommendation for dkim signing

[Scott Kitterman via Postfix-users]

On November 6, 2023 10:51:06 AM UTC, Patrick Ben Koetter via Postfix-users 
 wrote:
>* Jens Hoffrichter via Postfix-users :
>> Hi!
>> 
>> We are looking into implementing DKIM signing for one of our services,
>> and there are multiple ways to implement that.
>> 
>> So far I have found that you can do it with opendkim and amavis - any
>> recommendation for one or the other, or maybe something completely
>> different I haven't found yet?
...
>dkimpy-milter::
>dkimpy-milter supports RSA-SHA256 and ED25519-SHA256. If you have
>experience running opendkim you will feel at home using dkimpy-milter.
>dkimpy-milter used to have and I don't know if it still has problems
>handling email message headers containing UTF-8 chars when there shouldn't
>be any, like in a Subject that reads "Passwort zurücksetzen", which MUST
>be ISO encoded, but then there are developers who don't know that and …
>dkimpy-milter crashes because of the way Python 3.x handles UTF-8. I've
>no idea if Scott has found time to address and fix that.
...

This is fixed.  It still does properly implement support for non-ASCII headers, 
but the crashes should be a thing of the past.

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

[pfx] Re: Recommendation for dkim signing

[Scott Kitterman via Postfix-users]

On November 2, 2023 10:18:38 AM UTC, Jaroslaw Rafa via Postfix-users 
 wrote:
>Dnia  2.11.2023 o godz. 09:42:01 Matus UHLAR - fantomas via Postfix-users 
>pisze:
>> (once more: DKIM applies on header From:, SPF on envelope from:).
>
>And DMARC requires that both be identical (actually, from the same domain -
>user part may be different), which makes things even harder.

This is only true for strict alignment, which is not the default.  For relaxed 
alignment (which is the default and what most domains use), the Mail From 
domain (for SPF) and the DKIM signing domain (for DKIM) need to be either the 
same domain as the body From domain or a subdomain.  This provides significant 
flexibility relative to the strict alignment requirements, but this is little 
to do with the topic of the thread.

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

[pfx] Re: Recommendation for dkim signing

[Scott Kitterman via Postfix-users]

On Monday, October 30, 2023 3:10:22 PM EDT Viktor Dukhovni via Postfix-users 
wrote:
> On Mon, Oct 30, 2023 at 10:06:46AM +0100, Jens Hoffrichter via Postfix-users 
wrote:
> > We are looking into implementing DKIM signing for one of our services,
> > and there are multiple ways to implement that.
> > 
> > So far I have found that you can do it with opendkim and amavis - any
> > recommendation for one or the other, or maybe something completely
> > different I haven't found yet?
> 
> Both OpenDKIM and dkimpy-milter work reasonably well, but the former is
> IIRC no longer actively maintained.  Note, though have similar
> configuration formats, they're not quite identical.   Where the
> OpenDKIM signers file wants:
> 
> domain  keyname
> 
> the opendkimpy-milter wants:
> 
> *@domainkeyname
> 
> Scott Kitterman, when he gets around to reading this thread will I hope
> have more to say the subject.
> 
> Though dkimpy-milter is likely the more future-proof choice, perhaps
> OpenDKIM is slightly more polished at present, be it also dated (
> lacking some of the newer algorithms).
> 
> For signing, lack of bleeding-edge algorithms is less important, so if
> you're not also validating, OpenDKIM would be sufficient.

I've implemented the options from OpenDKIM that I thought made sense.  If it's 
in the documentation for dkimpy-milter as implemented, it should work fine.  If 
you need something I didn't document as implemented from OpenDKIM, then you 
should stick with OpenDKIM.

Neither milter deals with EAI email well.

I think my approach to signing both RSA and ed25119 in a single instance is 
better than the OpenDKIM approach that requires multiple milter instances.  
Due to limited ed25119 support, you don't want to do ed25119 only.

If you're allergic to Python, then you want to stick with OpenDKIM.

I guess (from reading the thread) if you think the fact that I wrote the SPF 
RFC and some SPF related software means I can't write DKIM related software 
(really?), then you should stick with OpenDKIM.

OpenDKIM is faster, but I think DNS performance tends to dominate, at least 
for DKIM verification, so that may or may not matter.

If there's something you don't like about dkimpy-milter and you're going to 
write something about "if you don't change X, I'll switch to something else", 
go ahead and use the something else.

Scott K




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

[pfx] Re: Typo in man postconf ("Postix")

[Scott Kitterman via Postfix-users]

On July 3, 2023 10:04:05 PM UTC, Viktor Dukhovni via Postfix-users 
 wrote:
>On Mon, Jul 03, 2023 at 09:52:28PM +0000, Scott Kitterman via Postfix-users 
>wrote:
>
>> >Should I ask WTF BTS?
>>
>> Bug Tracking System.  No.
>
>I see...  The Postfix project does not curate bugs.  There are, except
>briefly for O(1 day) from the date the bug is reported, zero known
>outstanding bugs.  Therefore, also no need for a "BTS".
>

That's almost verbatim what I told him in the part of the IRC conversation he 
elided from the email.

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

[pfx] Re: Typo in man postconf ("Postix")

[Scott Kitterman via Postfix-users]

On July 3, 2023 9:43:39 PM UTC, Viktor Dukhovni via Postfix-users 
 wrote:
>On Tue, Jul 04, 2023 at 06:19:26AM +1000, Trent W. Buck via Postfix-users 
>wrote:
>
>> master:postfix/proto/postconf.proto:6450: This feature is available in 
>> Postix 2.10 and later. 
>> master:postfix/proto/stop:1185:Postix
>> 
>> Are these typos?
>
>Yes.  The fix is trivial:
>
>--- proto/postconf.proto
>+++ proto/postconf.proto
>@@ -6450 +6450 @@ smtpd_recipient_restrictions.
>- This feature is available in Postix 2.10 and later. 
>+ This feature is available in Postfix 2.10 and later. 
>--- proto/stop
>+++ proto/stop
>@@ -1185 +1184,0 @@ OpenSSL's
>-Postix
>
>The other two files are machine-generated.
>
>> There is no public VCS.
>
>So far, not much need.  FWIW, you can find a tracking git repository at:
>
>https://github.com/vdukhovni/postfix
>
>but since it is not the place to submit changes, it is not immediately
>applicable to your needs.
>
>>  Is there a BTS?
>
>Should I ask WTF BTS?
>
Bug Tracking System.  No.

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

[pfx] Re: Is it possible in postfix spf policy to utilize multiple action=prepend to add multiple headers?

[Scott Kitterman via Postfix-users]

On June 19, 2023 9:44:59 PM UTC, Viktor Dukhovni via Postfix-users 
 wrote:
>On Mon, Jun 19, 2023 at 09:12:29PM +, Anton Hvornum via Postfix-users 
>wrote:
>
>> Yea found libmilter, appears to have some python bindings too.
>
>You don't need to go that far down the stack.  Try the "Milter" package.
>There are sample Milters available, just tweak one to your needs.
>
>For example:
>
>https://pythonhosted.org/pymilter/index.html

In fact, the spf-engine project that was mentioned up thread has a milter front 
end that uses pymilter, in addition to supporting the Postfix policy interface.

I'll also mention that there are multiple standardized ways to record SPF 
authentication results in the header of an email.  I would recommend using one 
of those, rather than inventing your own.

Scott K

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

[pfx] Re: [pfx]: DKIM and DMARC

[Scott Kitterman via Postfix-users]

On May 16, 2023 1:20:53 PM UTC, Ralf Hildebrandt via Postfix-users 
 wrote:
>* Scott Kitterman via Postfix-users :
>
>> DKIM has no policy mechanism associated with it, so there's no basis in any 
>> standardized mechanism to determine if a DKIM failure should be cause for 
>> rejection.  I don't think it makes logical sense to treat a message with a 
>> DKIM signature that failed to verify any more harshly than you would 
>> unsigned mail.
>> 
>> DMARC does have such a policy component.  Rejecting mail which fails DMARC 
>> for domains that have a policy of p=reject is common.  DMARC does have a 
>> high error rate for some types of email, so I would recommend a careful 
>> evaluation of what you would be rejecting before you do so.
>
>I always thought DMARC was the policy component for DKIM.

Sort of.  DMARC is it's own protocol that is built on top of the email 
authentication information provided by DKIM and SPF.  It uses both in ways that 
are somewhat different than what they were designed for, but more or less works 
(the less part leads to the failure cases).

To the extent there is a policy component for DKIM, DMARC is it, but they are 
each their own thing.  This is different than DomainKeys, which had policy 
built in.

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

[pfx] Re: DKIM and DMARC

[Scott Kitterman via Postfix-users]

On May 16, 2023 12:16:21 PM UTC, Tom Reed via Postfix-users 
 wrote:
>Hello list,
>
>Should we reject failed message on DKIM validation stage, or DMARC
>validation stage, or both?

No and it depends.

DKIM has no policy mechanism associated with it, so there's no basis in any 
standardized mechanism to determine if a DKIM failure should be cause for 
rejection.  I don't think it makes logical sense to treat a message with a DKIM 
signature that failed to verify any more harshly than you would unsigned mail.

DMARC does have such a policy component.  Rejecting mail which fails DMARC for 
domains that have a policy of p=reject is common.  DMARC does have a high error 
rate for some types of email, so I would recommend a careful evaluation of what 
you would be rejecting before you do so.

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

[pfx] Re: DKIM questions

[Scott Kitterman via Postfix-users]

On Tuesday, April 25, 2023 2:12:23 PM EDT Ken Peng via Postfix-users wrote:
> Hello
> 
> Can the domain certificates sign its sub domain?
> For example, mail.a.com was signed by certs of a.com.
> If so, does this make sense to DMRC of mail.a.com?

Yes.

If I understand the second question correctly, yes, as long as you use relaxed 
alignment (the default).

Scott K


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

[pfx] Re: SPF: HELO does not publish an SPF Record

[Scott Kitterman via Postfix-users]

On April 12, 2023 2:00:01 PM UTC, Steffen Nurpmeso via Postfix-users 
 wrote:
>Matus UHLAR - fantomas wrote in
> :
> |On 12.04.23 12:41, Fourhundred Thecat via Postfix-users wrote:
> ...
> |>Does it mean that I should either:
> |>
> |>  1) create SPF record for mail.mydomain.com
> ...
> |I would do the first:
> |
> |fantomas.fantomas.sk descriptive text "v=spf1 a -all"
>
>Interesting this still works for you.  I had to change to ~all
>because some behind-alias-expansion-and-forward collocutor
>de-facto uses a GMail address.  Just three weeks ago on the LUGA
>ML that also came up
>
> |     host gmail-smtp-in.l.google.com said: 550-5.7.26 The MAIL FROM
> |     domain [] has an SPF record with a hard fail 550-5.7.26 policy
> |     (-all) but it fails to pass SPF checks with the ip:
>
>My (earlier own) communication then ended with
>
>   |> 2015.  Changing to ~all could be done, i do not know if Google
>   |> gets that.
>   |
>   |Google may have been ignoring your -all until recently.
>
>  Google seems to have been laxe regarding FreeBSD forwarding.
>  I have cloned https://github.com/roehling/postsrsd.git to have
>  a look at it.

Generally the interoperability issues that can arise with SPF for Mail From 
don't come up with HELO.  I don't think I've ever heard of a problem with -all 
for HELO.  For Mail From, some people have issues, as you describe.

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

[pfx] Re: Question to reject_rbl_client zen.spamhaus.org

[Scott Kitterman via Postfix-users]

On April 10, 2023 4:52:04 AM UTC, tom--- via Postfix-users 
 wrote:
>On 2023-04-10 12:39, Peter via Postfix-users wrote:
>> On 10/04/23 14:21, tom--- via Postfix-users wrote:
>>> I have resolved the issue by:
>>> 
>>> 1. install unbound as dns resolver locally
>> 
>> This is good.
>> 
>>> 2. change this statement:
>>>     check_policy_service unix:private/policyd-spf,
>>>    to this one:
>>>     check_policy_service { unix:private/policyd-spf, default_action=DUNNO },
>> 
>> The default_action here actually defines what action postfix will take if 
>> the policyd errors out (e.g. not running).  By default this is "451 4.3.5 
>> Server configuration problem" which results in a deferral, so it would not 
>> cause the message to pass by default but rather to defer. That said, there 
>> is nothing wrong with this setting if that's what you actually want to 
>> happen if the policyd isn't working.
>> 
>
>I was thinking the python version configuration for policyd-spf maybe have 
>bugs.
>from the doc:
>https://manpages.debian.org/testing/postfix-policyd-spf-python/policyd-spf.conf.5.en.html
>
>which says:
>
>HELO/EHLO PASS RESTRICTION
>HELO Pass Restriction allows integration with other Postfix access controls by 
>provding a user supplied name of a postfix access restriction to be applied to 
>a message when the HELO checking result is Pass. The indicated restriction 
>must be an action as defined for a Postfix SMTP server access table access(5) 
>and explained in the Postfix RESTRICTION CLASS README. The 
>README.per_user_whitelisting file provided with this distribution provides 
>examples. Note: A helo pass restriction will be the returned result even if 
>the mail from result would cause the message to be rejected.
>
>Example:
>
>HELO_pass_restriction = helo_passed_spf
>
>Default:
>
>None
>
>
>I think the Default should be set to "DUNNO" here. but it's None. so a system 
>argument
> like mine is required.
>
>Am I right?
>Thanks.

No.  If you set HELO_pass_restriction, you can override the normal responses.  
If it's None (the default) the normally appropriate response will be returned 
(e. g. DUNNO).  If you haven't set a value for the option, you don't need to 
worry about it, it does nothing.

Scott K


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

[pfx] Re: simple content filter for outgoing message

[Scott Kitterman via Postfix-users]

On April 6, 2023 11:39:10 AM UTC, Corey Hickman via Postfix-users 
 wrote:
>Hello buddies,
>
>I just want to make some simple filters for outgoing messages.
>for example, the message content has some keywords (like "VPN sale") included, 
>it will be rejected by the system.
>
>I know there are the software Rspamd and Spamassassin, but they are too heavy 
>for my simple usage.
>
>Do you have any other ideas?

If you want a custom solution, a milter is probably the simplest way to get 
access to the message body.  There are language bindings for libmilter that 
make it relatively simple.  I've had a lot of success using pymilter and 
Python, but there are others.

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

[pfx] Re: [P-U] Re: New List Host and Reply-to Header

[Scott Kitterman via Postfix-users]

On March 24, 2023 10:50:35 PM UTC, raf via Postfix-users 
 wrote:
>On Fri, Mar 10, 2023 at 09:11:58AM +1300, Peter via Postfix-users 
> wrote:
>
>> * Don't add a Reply-To:.  I actually question if this is really needed as we
>> likely want replies to go to the list the vast majority of time anyways.  I
>> have seen other lists explicitly exclude this step and it works well.
>> 
>> Peter
>
>Removing Reply-To would remove functionality that is
>important, even if it is only occasionally required.
>Off-list replies would become impossible. That is a
>loss of functionality. Just because something is wanted
>the vast majority of the time, it doesn't mean that
>it's OK to enforce it 100% of the time.

This is true, but only because from is being rewritten.  In my view the old 
approach of not making changes that break DKIM signatures was much simpler.  
Then the ML could happily ignore the existence of DMARC.

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

[pfx] Re: MySQL error from not all the receiver

[Scott Kitterman via Postfix-users]

On Sunday, March 12, 2023 7:02:41 PM EDT Gerald Galster via Postfix-users 
wrote:
> > unfortunately I don't know this topic, but I'm really willing to study.
> > Please do you have any documentation on this?
> Sorry, I can't recommend an up to date howto. Perhaps other list members can
> help.
> 
> A lot of links at https://www.postfix.org/docs.html are outdated or do not
> exist anymore.

My recommendation to the OP would be to reconsider what they are trying to 
accomplish and what's the simplest way to do so.  Through this thread I 
haven't seen anything that would need MySQL or for which MySQL would make 
things particularly easier.  Keep it simple to start and only and more moving 
parts if you really need them.

Scott K


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

[pfx] Re: milter: could it splice (, somehow)?

[Scott Kitterman via Postfix-users]

On March 11, 2023 6:05:52 PM UTC, Steffen Nurpmeso via Postfix-users 
 wrote:
>postfix-users@postfix.org wrote in
> :
> |On Sat, Mar 11, 2023 at 01:54:01AM +0100, Steffen Nurpmeso via Postfix-u\
> |sers wrote:
> |
> |> - sign the entire message as for now,
> |
> |You're confusing the message and the envelope.
>
>..no?  No.
>
> |> - but include a "cramped=1" tag that signals that all receivers
> |>   are actually covered by the DKIM signature, so
> |
> |The envelope is not part of the signed message, and the envelope changes
>
>That "cramped=1" would be in the usual DKIM header, i'd presume.
>
> |in transit, and is knowable to the message signer when the message is
>
>(But mostly MUST NOT with some SHOULD NOTs, right?)
>
> |first submitted to the mail system.
> |
> |Whatever problem you're trying to solve, it has nothing to do with
> |DKIM.
>
>I was talking RFC 6376.
>They try to deal with DKIM replay, and a real (beside all
>the babble) suggestion was exactly what i wrote.
>So the message would be signed just as now, but to avoid replay
>the actual RCPT-TO would get its own additional signed Header
>field (i would think that was the idea), so that had to be spliced
>into the RCPT-TO:<> specific variant of the message.
>
>(The alternative to fullfil this RCPT-TO:<> specific variant would
>be to sign _the entire message_ for each RCPT-TO:<>, which is more
>expensive.  This is what the MUA i maintain does for S/MIME
>encryption, but i think at scale this would be way more expensive
>for say a ML that DKIM signs than simply preparing the message and
>prepending a RCPT-TO:<> specific signed DKIM addition that is
>signalled via a tag in the normal DKIM signature.)
>
>But i treat your answer as if milters will not do that.

If you want to talk about DKIM replay, the IETF DKIM working group was just 
rechartered to work on that exact thing: ietf-d...@ietf.org .

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

[pfx] Re: [P-U] Re: New List Host and Reply-to Header

[Scott Kitterman via Postfix-users]

On Friday, March 10, 2023 7:04:30 AM EST Patrick Ben Koetter via Postfix-users 
wrote:
> * Gerald Galster via Postfix-users :
> 
> > >>> This list uses Mailman configuration settings, not handcrafted code.
> > >>> If people believe that it is worthwhile to change the Mailman
> > >>> implementation or the DMARC spec, then I suggest that they work
> > >>> with the people responsible for that.
> > >> 
> > >> 
> > >> There is no need for changing implementations, it's already there.
> > >> 
> > >> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/config
> > >> /docs/config.html
 
> > >> 
> > >> remove_dkim_headers
> > > 
> > > 
> > > THAT is a global Mailman setting. It cannot be configured on a
> > > per-list basis. The postfix lists are hosted on a multi-tenant
> > > service, it does not run on its dedicated MTA.
> > 
> > 
> > I just wrote that because p@rick (sys4 AG) asked on the mailop
> > mailinglist
> > 2023-02-17 "Should mailing list messages be DKIM signed? (ARC / DKIM)".
> > He was about to setup a new mailing list server with mailman 3.
> > Given there are virtually no other lists in postorious index, chances are
> > this is a new server currently only hosting the postfix mailinglist
> > and some testlists so that settings might not be final yet.
> > 
> > Just out of curiosity it would have been nice to know why he made
> > that choice.
> 
> 
> You mean why I choose to use Mailman 3 and not other MLMs?
> 
> I used to by python.org postmaster for 20 (?) years and there's a natural
> sympathy for anything that comes from pydotorg. Then I used to be on the
> MM3
 developer team in the early 2000s and some of the ideas and concepts I
> came up with have found their way into MM3. Besides my personal historic
> preferences, I choose MM3 because it has been there for a few years now and
> I don't see it being used widely, though I believe it should. We
> (community) need a modern MLM and MM3 is modern. There are some things I
> don't like about MM3. If you come from Postfix MM3 documentation is, to put
> it, frustrating. It's developers who documented what is interesting to
> developers, but there don't seem to be any documents for operators. That
> kicks in when you need to find out how mailman-core, hyperckitty and
> postorius play together. The web application, to me, should really see some
> UX love. I constantly get lost hunting options I saw, but I can't remember
> where. Besides, rendering descriptions / options of parameters visibly into
> the interface blows up each settings page and the rendering lacks
> structure. So you end up scanning through a blob of options trying to catch
> what might to what you want. Wietse can probably tell how much he suffered
> at some point to get MM3 what he wanted it to do for the postfix-mumble
> lists. What I like about MM3 is it's approach to subscriber self
> management. Once you've become a registered MLM platform participant you
> can easily change settings that will apply to all lists you've subscribed
> to in one place. I consider that a great usability benefit for subscribers.
> 
> But most of all I wanted to create a Mailing list platform that is capable
> of and uses modern email technologies. We have ARC in place and need to
> figure out a few undocumented issues we still need to address before it
> will actually work. But that's a temporary problem. I want it to use ARC
> because even though it is still EXPERIMENTAL, it will likely be here to
> stay and ARC has been designed to fix the DMARC issues that had been put on
> our shoulders when DMARC was adopted by major industry players.
> 
> And… while I write work is going on in the background to provide a fully
> DNSSEC enabled DNS stack which will allow us to host a DANE enabled mailing
> list platform.
> 
> ⌁ [p:~] $ dig +short +dnssec MX postfix.org
> 10 list.sys4.de.
> MX 13 2 3600 20230322050014 20230308042038 60616 postfix.org.
> DXMTOwxrFmyCf7fv02gAR0qmVeB78gGwPu74oR17y1l6vls/zbUP7P6C
> G5ZZWtHDCMruSzwISYfdwVBNnDdjXg== ⌁ [p:~] $ dig +short +dnssec A
> list.sys4.de
> 188.68.34.52
> A 8 3 3600 20230315165309 20230308142813 46365 sys4.de.
> Oi9o51moM26dA2Y2zMjMXErEz8wj/o+tadfas9QedSv5AqPg0C0uBaZd
> 31IeAZRxGxFLwECqLqPncJgyyKkNLXlTY2t1qQ60/GT3rjRof9kmIwpO
> lwYgFBwUfsjhz1rPF16W81ya+5DdPJefXuYMN4G6hOWvJPgiMo5qeUGb JFs=
 
> This will allow us to add TLSA RRs to list.sys4.de soonish and then
> postfix.org finally will life what it brought to live when Viktor
> implemented DANE support making Postfix the first and reference MTA on
> this planet to support DANE.
> 
> Secure Email Transport and Email Authentication are the two cornerstones of
> todays email policing and my personal wish is to provide a state of the art
> platform and hopefully a template how to run mailing lists in the 2020s. 
> p@rick


I think that all sounds reasonable, although I think you're overselling ARC, 
but that's a discussion for a different list.

Is there any chance of From 

[pfx] Re: [P-U] Re: Postfix lists are migrating to a new list server

[Scott Kitterman via Postfix-users]

On Wednesday, March 8, 2023 1:52:47 AM EST Patrick Ben Koetter via Postfix-
users wrote:
> * Scott Kitterman via Postfix-users :
> 
> ...
> 
> 
> > For Debian, if someone can find/test patches, I can get them into Debian's
> > package.  I assume other distributors are similar.  Feel free to update
> > the Debian bug with information.  It's unfortunate we don't have a better
> > maintained solution.
> 
> In Germany the German government is preparing an initiative to foster open
> source projects that are considered to be vital for e.g. the security of
> people when they are on the internet.
> 
> At eco e.v., Germanies lobby organization for businesses on the internet,
> we are currently investigating if opendkim and opendmarc could receive
> grant from the government.
> 
> openspf, opendkim and opendmarc have been very useful when the IETF created
> the RFCs, because you need "rough consensus and running code", and the
> programs always served to provide the latter, but then, after they had
> become the de facto standard applications, no one took on the task of
> "software gardening" and so bugs that had been discovered did not get fixed
> and new functionality has not been added. That's one of the reasons it has
> become harder to run a modern mail platform on your own if you are not a
> major player.

That would be great.  I started dkimpy-milter for two reasons: I wanted to 
experiment with the new DKIM crypto types that lead to RFC 8463 and there 
didn't seem to be much activity with opendkim maintenance (this is, of course, 
ironic given how well I did with dkimpy-milter maintence recently).

I did finally get a new release out recently and as far as I can tell with the 
updates to pymilter, dkimpy, and dkimpy-milter the crashes from non-ASCII/
UTF-8 data are a ting of the past (if someone knows otherwise, please file 
bugs).

Scott K


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

[P-U] Re: Postfix lists are migrating to a new list server

[Scott Kitterman via Postfix-users]

On March 7, 2023 11:37:53 PM UTC, Phil Stracchino via Postfix-users 
 wrote:
>On 3/7/23 15:28, John Stoffel via Postfix-users wrote:
>>> "mailmary---" == mailmary--- via Postfix-users 
>>>  writes:
>> 
>>> Unfortunately I've seen this crash as well, its actually quite
>>> frequent in my case and I'm using a newer version of OpenDMARC than
>>> you:
>> 
>>> # opendmarc -V
>>> opendmarc: OpenDMARC Filter v1.4.2
>>> SMFI_VERSION 0x101
>>> libmilter version 1.0.1
>>> Active code options:
>>> WITH_SPF
>>> WITH_SPF2
>> 
>> 
>>> No solution so far, I think there are 2-3 open bug reports on
>>> github, but since the project is very dead, nobody has bothered to
>>> fix the problem.
>> 
>> So what's the option for a more upto date version of DKIM milter for debian?
>
>
>s/for debian//
>
>
>FIFY

For Debian, if someone can find/test patches, I can get them into Debian's 
package.  I assume other distributors are similar.  Feel free to update the 
Debian bug with information.  It's unfortunate we don't have a better 
maintained solution.

I've considered creating a Python based milter for DMARC the way I did for DKIM 
(due to the level of OpenDKIM maintenance), but they're not enough hours in the 
day.

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

Re: Postfix with opendkim generates "ssl error"

[Scott Kitterman]

On February 11, 2023 3:41:06 PM UTC, nj140...@yahoo.com wrote:
>Trying to send an email from n...@complete-web-solutions.com on the
>host sv9.complete-web-solutions.com results in the following messages
>in mail.log:
>...

>But opendkim seems correctly configured because the command:
>opendkim-testkey -d complete-web-solutions.com -s 202302081 -v -x
>/etc/opendkim.conf
>gives the result:
>opendkim-testkey: key secure

You only tested the availability of the public key, but your error is with the 
private key.  See the -k option.

http://www.linuxcertif.com/man/8/opendkim-testkey/

Scott K

Re: SPF fail and domain fail, why?

[Scott Kitterman]

On January 17, 2023 2:25:34 AM UTC, raf  wrote:
>On Mon, Jan 16, 2023 at 08:01:10PM +0100, Maurizio Caloro  
>wrote:
>
>> Hello
>> 
>> Please one more thing about Opendmarc, if send any email to any where
>> i see in log SPF fail, domain.ch fail ?
>> 
>> Jan 16 19:43:39 nmail opendkim[16490]: B6090404C3: DKIM-Signature field
>> added (s=nmail, d=caloro.ch)
>> Jan 16 19:43:39 nmail opendmarc[16483]: B6090404C3: SPF(mailfrom): caloro.ch
>> fail
>> Jan 16 19:43:39 nmail opendmarc[16483]: B6090404C3: caloro.ch fail
>> 
>> if recieve any mail from any where, any thing pass
>> Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: mailc-bb.linkedin.com
>> [A.B.C.D] not internal
>> Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: not authenticated
>> Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: message has signatures
>> from linkedin.com, mailc.linkedin.com
>> Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: signature=muv88Rcz
>> domain=linkedin.com selector=d2048-201806-01 result="no signature error";
>> signature=IKaXoyzS domain=mailc.linkedin.com selector=proddkim1024
>> result="no signature error"
>> Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: DKIM verification
>> successful
>> Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: s=d2048-201806-01
>> d=linkedin.com SSL
>> Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3 ignoring
>> Authentication-Results at 2 from nmail.caloro.ch
>> Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3: SPF(mailfrom):
>> bounce.linkedin.com pass
>> Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3: linkedin.com pass
>> 
>> --
>> on the header from any mail that i send will appair following
>> Authentication-Results-Original: caloro.ch, calm-ness.ch; spf=fail
>> 
>> # cat opendmarc.conf
>> AuthservID          caloro.ch, calm-ness.ch
>> AuthservIDWithJobID false
>> AutoRestart         false
>> AutoRestartRate         10/1h
>> Background          true
>> DNSTimeout  5
>> HistoryFile /var/spool/postfix/opendmarc/opendmarc.dat
>> IgnoreAuthenticatedClients  true
>> IgnoreHosts     /etc/opendmarc/ignore.hosts
>> PidFile /var/run/opendmarc/opendmarc.pid
>> RejectFailures  false
>> RequiredHeaders true
>> PublicSuffixList /etc/opendmarc/effective_tld_names.dat
>> Socket  inet:8892@127.0.0.1
>> SoftwareHeader  true
>> SPFSelfValidate true
>> SPFIgnoreResults    false
>> Syslog      true
>> SyslogFacility  mail
>> # TrustedAuthservIDs    nmail.caloro.ch, nmail.calm-ness.ch
>> TrustedAuthservIDs  caloro.ch, calm-ness.ch
>> UMask   077
>> UserID  opendmarc:opendmarc
>> 
>> if checking online dmarc, dkim, spf from domain appair anything correct!
>> please why me email will fail?
>> 
>> thanks for any hint
>> Mauri
>
>I could be wrong, but I suspect that the problem is
>that you haven't configured OpenDMARC to not check
>locally originating mail. According to the first
>Received: header, the mail is coming from 37.120.190.188
>(which is mentioned in multiple ways in the SPF record),
>but your mail server at that IP address shouldn't be
>performing this check on outgoing mail.
>
>Perhaps you need to add this to your /etc/opendmarc.conf:
>
>  IgnoreAuthenticatedClients true
>
>Unfortunately, the code doing the SPF check doesn't
>explain why it failed. Some do. For example, the
 package on debian would
>probably show the IP address that caused the failure.
>Maybe it's 127.0.0.1 (or the IP address of an
>authenticated submission client).

The internal SPF implementation in OpenDMARC is not a full implementation of 
the protocol.  In general, you are likely to be better off having something SPF 
specific check SPF and then have OpenDMARC consume that result for it's DMARC 
processing.  If you are inclined towards Perl, then postfix-policyd-spf-perl is 
a good choice.  SPF Engine supports either a milter (pyspf-milter) or policy 
server (postfix-policyd-spf-python) interface with Postfix, depending on which 
you prefer, if you're up for a Python based solution.

Scott K

Re: postfix/pickup question

[Scott Kitterman]

On January 16, 2023 2:13:42 PM UTC, Wietse Venema  wrote:
>Maurizio Caloro:
>> The option that was cause:
>>   -failurereports
>>   -failureReportssendby emailaddress
>
>DO NOT run milters as the 'postfix' user. Only Postfix programs
>should use that userid.

FYI,

Since this appears to be a Debian system, the Debian package for opendmarc runs 
as it's own dedicated user (I double checked).  All the other packaged milters 
I'm aware of do the same.

Scott K

Re: after update - postfix turble with %i

[Scott Kitterman]

Sending again with the right address.

Scott K

On January 11, 2023 7:02:58 PM UTC, Scott Kitterman  
wrote:
>This is related to Debian specific packaging scripts, not upstream Postfix.  
>Please file a bug in the Debian Bug Tracking System (BTS) and we'll work on it 
>there.
>
>As a general rule, you should not be directly touching configure-instance.sh.  
>It has no user serviceable parts.
>
>Scott K
>
>On January 11, 2023 6:46:03 PM UTC, Maurizio Caloro  wrote:
>>Hello
>>After updating debian i have little truble with postfix service "postmulti"
>>varibles, i think that this varible "%i" are not recoginzed correctly when 
>>start postfix
>>
>>i try also multiple version to add "  '  " so that the %i can by recognize, 
>>and after adding
>>"configure-instance.sh postfix/" this will mount the main.cf but what the 
>>other
>>commands "configure-instance.sh postfix/" dont recognize this!?
>>
>>thanks - Mauri
>>
>>
>>main.cf
>>multi_instance_enable = yes
>>
>># systemctl status postfix@-.service
>>● postfix@-.service - Postfix Mail Transport Agent (instance -)
>>   Loaded: loaded (/lib/systemd/system/postfix@-.service; enabled; vendor 
>>preset: enabled)
>>   Active: active (running) since Wed 2023-01-11 19:25:28 CET; 4s ago
>> Docs: man:postfix(1)
>>  Process: 4966 ExecStartPre=/usr/lib/postfix/configure-instance.sh - 
>>(code=exited, status=0/SUCCESS)
>>  Process: 5281 ExecStart=/usr/sbin/postmulti -i - -p start (code=exited, 
>>status=0/SUCCESS)
>>    Tasks: 3 (limit: 2358)
>>   Memory: 6.3M
>>   CGroup: /system.slice/system-postfix.slice/postfix@-.service
>>   ├─5514 /usr/lib/postfix/sbin/master -w
>>   ├─5515 pickup -l -t unix -u
>>   └─5516 qmgr -l -t unix -u
>>
>>Jan 11 19:25:25 nmail systemd[1]: Starting Postfix Mail Transport Agent 
>>(instance -)...
>>Jan 11 19:25:28 nmail postfix/postfix-script[5512]: starting the Postfix mail 
>>system
>>Jan 11 19:25:28 nmail postfix/master[5514]: daemon started -- version 3.4.23, 
>>configuration /etc/postfix
>>Jan 11 19:25:28 nmail systemd[1]: Started Postfix Mail Transport Agent 
>>(instance -).
>>
>># cat postfix@-.service
>>[Unit]
>>Description=Postfix Mail Transport Agent (instance %i)
>>Documentation=man:postfix(1)
>>PartOf=postfix@-.service
>>Before=postfix@-.service
>>ReloadPropagatedFrom=postfix@-.service
>>After=network-online.target nss-lookup.target
>>Wants=network-online.target
>>
>>[Service]
>>Type=forking
>>GuessMainPID=no
>>ExecStartPre=/usr/lib/postfix/configure-instance.sh %i
>>ExecStart=/usr/sbin/postmulti -i %i -p start
>>ExecStop=/usr/sbin/postmulti -i %i -p stop
>>ExecReload=/usr/sbin/postmulti -i %i -p reload
>>
>>[Install]
>>WantedBy=multi-user.target
>>
>>
>>

Re: warning: disabling connection caching

[Scott Kitterman]

On December 20, 2022 11:40:02 AM UTC, Fourhundred Thecat <400the...@gmx.ch> 
wrote:
>> On 2022-12-20 12:13, Wietse Venema wrote:
>> Fourhundred Thecat:
>> 
>>> Also, if I wanted to test scache, how can I trigger it?
>>> 
>>> If I send one email to multiple email addresses on same domain, will
>>> this trigger scache? (ie, deliver multiple emails in one connection to
>>> the server?)
>> 
>> Did you build Postfix?
>> 
>> Is this one of those container-optimized libc implementations?
>
>no, I am using standard postfix package (3.4.14) on Debian 10
>
>I don't suspect anything wrong with the build, I think something
>unrelated on my system might have been wrong. I have restarted the
>server, and I thought I would trigger scache, to make sure it is working now

You ought to consider installing the available updates.  3.4.23 is available in 
the archive for Debian 10.  Also, if your Postfix is out of date, there are 
probably other things too.  Who knows, maybe even an update that fixes the 
unrelated thing that went wrong.

Scott K

Re: Is it possible to rewrite the envelop from address for all mail that's being relayed?

[Scott Kitterman]

On December 5, 2022 4:19:21 PM UTC, Sean Hennessey 
 wrote:
>I'm curios if it's possible to set up postfix to rewrite the envelop from 
>address for all email the instance is relaying? I'm doing some research and 
>want to force the envelop from to be a known value that I know will pass spf 
>checks.
>
>Thanks in advance.

Not just using postfix.  With a milter, it's quite possible.  
https://github.com/croessner/vrfydmn does not do exactly what you're asking 
for, but it's in the ballpark to give an idea of how to approach the problem.

Scott K

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

[Scott Kitterman]

On November 20, 2022 11:47:02 PM UTC, raf  wrote:
>On Sun, Nov 20, 2022 at 03:29:33PM +0100, Matus UHLAR - fantomas 
> wrote:
>
>> > 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.
>> 
>> On 20.11.22 08:21, Dominic Raferd wrote:
>> > 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)?
>> 
>> Sorry, you are correct.
>> 
>> There was no other spf milter available in debian when I checked.
>> 
>> Package: pyspf-milter
>> Source: spf-engine
>> 
>> Package: postfix-policyd-spf-python
>> Source: spf-engine
>
>There are also Debian packages for policy server versions:
>
>  postfix-policyd-spf-perl
>  postfix-policyd-spf-python

The Perl implementation is very rudimentary.  Unless one is completely allergic 
to Python for some reason, I definitely recommend the Python one.  

The backend logic/code in pyspf-milter is shared with the policy server.  For 
Postfix, I don't think it matters much if you use the milter or the policy 
server.

Scott K

Re: SPF questions

[Scott Kitterman]

On November 18, 2022 3:04:44 AM UTC, linux...@gmx.net wrote:
>Dear List,
>
>I have enabled policyd-spf in postfix:
>
>smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, 
>reject_unauth_destination, check_policy_service unix:private/policyd-spf
>
>
>but can you help that, when a SPF check fails, where should I setup the reject 
>action?
>
>Thanks

In the config file for the policy server.

Scott K

Re: Issue routing mail

[Scott Kitterman]

On Sunday, November 13, 2022 7:26:25 PM EST David wrote:
> Folks
> I'm noticing that two installations of Postfix:
>   version 3.4.13-0ubuntu1.2) on Ubuntu 20.04.5
>   version 3.6.4-1ubuntu1 on Ubuntu 22.04.1
> are both failing to use the MX value for outgoing
> mail.  Specifically, sending mail to any...@sonic.net (forget that no
> such account exists) should be connecting to the mail exchange at
> mailin-01.mx.sonic.net or mailin-02.mx.sonic.net and NOT to
> sonic.net.  The contents of the /var/log/maillog show the attempted
> connects to sonic.net which obviously fail, since "sonic.net" is not
> a mail server.
> 
> In both cases, I'm running BIND9 to serve a local network, and am
> using systemd's resolvconf.  In both cases, also, both "dig mx
> sonic.net" and "host -mx sonic.net" produce the correct MX values.
> 
> I have been unable to figure out what knob or switch or setting might
> be causing this behavior; any pointers or clues would be
> appreciated.  I can supply copies of configuration files if someone
> wants to dig further.

Debian puts Postfix in a chroot by default.  Ubuntu inherits this from Debian.  
The view of what's in DNS may not be the same inside the chroot as it is 
outside.  I'd recommend taking them out of the chroot and seeing if that fixes 
the problem.

Scott K

Re: policyd-spf error

[Scott Kitterman]

On October 31, 2022 8:12:08 AM UTC, Forums  wrote:
>Hello,
>
>Since this morning I can receive email, whitout doing something on my server.
>
>In maillog I can see the following errors:
>
>
>2022-10-31 08:59:37
>postfix/smtpd[6632]: NOQUEUE: reject: RCPT from fr-srvcomm[192.168.1.170]: 451 
>4.3.5 : Recipient address rejected: Server configuration problem; from= to= 
>proto=ESMTP helo=
>2022-10-31 08:59:37
>postfix/smtpd[6632]: warning: problem talking to server private/policyd-spf: 
>Connection reset by peer
>2022-10-31 08:59:37
>postfix/smtpd[6632]: warning: premature end-of-input on private/policyd-spf 
>while reading input attribute name
>2022-10-31 08:59:37
>postfix/spawn[6636]: warning: command /usr/bin/policyd-spf exit status 1
>2022-10-31 08:59:36
>postfix/smtpd[6632]: warning: premature end-of-input on private/policyd-spf 
>while reading input attribute name
>2022-10-31 08:59:36
>postfix/spawn[6636]: warning: command /usr/bin/policyd-spf exit status 1
>2022-10-31 08:59:34
>postfix/smtpd[6632]: connect from fr-srvcomm[192.168.1.170]
>2022-10-31 08:59:34
>postfix/postscreen[6631]: WHITELISTED [192.168.1.170]:33462
>2022-10-31 08:59:34
>postfix/postscreen[6631]: CONNECT from [192.168.1.170]:33462 to 
>[192.168.1.160]:25
>
>
>When I disable policyd-spf it's works without issue.
>
>
>* main.cf:
>
>policyd-spf_time_limit = 3600
>smtpd_recipient_restrictions =
>    check_policy_service unix:private/policyd-spf
>
>
>* master.cf:
>
>policyd-spf unix    -   n   n   -   0   spawn
>   user=nobody  argv=/usr/bin/policyd-spf 
>/etc/postfix-policyd-spf-python/policyd-spf.conf
>
>
>* /etc/postfix-policyd-spf-python/policyd-spf.conf:
>
>debugLevel = 2
>TestOnly = 1
>
>HELO_reject = Fail
>Mail_From_reject = Fail
>
>PermError_reject = False
>TempError_Defer = False
>
>skip_addresses = 127.0.0.0/8,:::127.0.0.0/104,::1
>
>Whitelist = 192.168.1.0/24

There should be log entries from the policy server with those settings.  Please 
post a question at https://answers.launchpad.net/spf-engine with those log 
entries related to the error.  Without that information it's just a guess.

Also, please include the version and where you installed it from.

Scott K

Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)

[Scott Kitterman]

On June 3, 2022 3:20:31 PM UTC, Viktor Dukhovni  
wrote:
>On Fri, Jun 03, 2022 at 09:27:15AM -0400, Viktor Dukhovni wrote:
>> On Fri, Jun 03, 2022 at 11:09:08AM +0200, Matus UHLAR - fantomas wrote:
>> 
>> > >Also can you "apt-get source postfix", and post a link to the tarball?
>> > 
>> > this will unpack the tarball in local directory.
>> > I use standard debian packages, there's SASL related patch but it doesn't 
>> > seem to affect this issue
>> > 
>> > https://sources.debian.org/patches/postfix/3.5.6-1/
>> > https://sources.debian.org/patches/postfix/3.5.6-1/07_sasl_config.diff/
>> 
>> The patch introduces a "SASL_CB_GETCONFPATH" callback, that indeed adds
>> "/etc/postfix/sasl" to the SASL config search path.  This creates two
>> conflicting ways to set the location, with the patch likely overriding
>> "cyrus_sasl_config_path", and not providing any mechanisms to choose
>> alternative locations.
>> 
>> This patch is IMHO obsolete and counterproductive, and should be
>> deprecated.  Debian should take advantage of "cyrus_sasl_config_path",
>> possibly with a custom compile-time default, or else just set at
>> install, or at upgrade time (if not already set, and the previous
>> Postfix version contains the patch).
>
>I am also a bit puzzled about memory correctness in this patch.  It
>allocates the callback data with the Postfix concatenate(), which uses
>the Postfix mymalloc(), but if/when SASL ever frees the value, the docs
>say it is freed with the C library free(), unless the application
>configures a different "free_t" function, which I believe is not the
>case.
>
>All in all, I'd like to see this patch go away.

I looked and the patch is unchanged from before I got involved in Postfix 
maintenance in Debian in 2016.  As you no doubt recall, Lamont had a low 
threshold for adding distribution patches.  I think given the existence of 
cyrus_sasl_config_path this can definitely go away.

Scott K

Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)

[Scott Kitterman]

On June 1, 2022 10:38:55 PM UTC, raf  wrote:
>On Wed, Jun 01, 2022 at 03:56:02PM +1200, Peter  wrote:
>
>> On 30/05/22 2:48 pm, raf wrote:
>> > > If set
>> > > +empty (the default value) the search path is the one compiled into the
>> > > +Cyrus SASL library.  
>> > 
>> > I don't think that's entirely correct. On Debian, for
>> > example, the default value of cyrus_sasl_config_path is
>> > empty, and /etc/postfix/sasl is the directory that is
>> > used. They haven't changed the default value to be
>> > non-empty.
>> 
>> It couldn't possibly be that they've compiled it into the cyrus sasl
>> library?
>> 
>> > But it does look like it's not the postfix package that
>> > they changed. They changed the sasl2-bin package.
>> > The only executable binary that contains the string
>> > /etc/postfix/sasl is /usr/bin/saslfinger which is
>> > provided by the sasl2-bin package.
>> 
>> Which suggests that it's been compiled into the cyrus sasl library.
>> 
>> Peter
>
>No. Perhaps in the past, but no longer. I grepped for
>/etc/postfix/sasl in every file on a debian11 system
>and it didn't appear in libsasl2 or anywhere
>interesting. It did appear in things like saslfinger
>and apparmor rules and the postfix package file list
>and augeas-lenses (a config file parser). But nothing
>in any libsasl files or postfix files.

That setting predates my involvement in Debian's postfix maintenance and since 
I use Dovecot, it isn't something that I test.  It definitely used to look in 
/etc/postfix/sasl and I didn't on purpose change it.  I'll add looking into 
this to my unfortunately long TODO for Debian postfix.

Scott K

Re: postfix-policyd-spf-python

[Scott Kitterman]

On May 13, 2022 12:14:38 PM UTC, Alex  wrote:
>> >> Not sure if this is the right place to post the question concerning
>> >> postfix-policyd-spf-python but I can't seem to find any working links
>> >> for the openspf project.
>> >>
>> >
>> >You should start here,
>> >
>> >  https://launchpad.net/spf-engine
>> >
>> >but the author is also on this list (I believe) and may reply directly.
>> >
>> Thanks.  Yes.  If you have additional questions, please ask questions/file
>> bugs there.
>>
>
>I also posted a question about pypolicyd-spf, so I posted it here, not at
>the above link. Is this related?
>
>My question involves understanding how the whitelist works - hosts seem to
>be whitelisted even though they're not in my Domain_Whitelist or
>skip_addresses list in my policyd-spf.conf file. How does it determine when
>to skip SPF
>
>May 13 08:11:11 xavier policyd-spf[2230289]: prepend X-Comment: SPF skipped
>for whitelisted relay domain - client-ip=54.240.14.218; helo=
>a14-218.smtp-out.amazonses.com; envelope-from=
>01000180bd5476c0-5cfcde84-8ec2-4b76-a4bf-f0b4ce69ce04-000...@mail.connectedcommunity.org;
>receiver=
>
>https://answers.launchpad.net/pypolicyd-spf/+question/701685
>
>The problem I'm having is that it seems to affect how my welcomlist_auth
>entries work with spamassassin.

I renamed pypolicyd-spf spf-engine when I added the option of using the milter 
interface.  That's the right place to ask questions.

Scott K

Re: postfix-policyd-spf-python

[Scott Kitterman]

On May 12, 2022 9:12:44 PM UTC, Michael Orlitzky  wrote:
>On Thu, 2022-05-12 at 21:03 +, Dino Edwards wrote:
>> Hi,
>> 
>> Not sure if this is the right place to post the question concerning
>> postfix-policyd-spf-python but I can't seem to find any working links
>> for the openspf project.
>> 
>
>You should start here,
>
>  https://launchpad.net/spf-engine
>
>but the author is also on this list (I believe) and may reply directly.
>
Thanks.  Yes.  If you have additional questions, please ask questions/file bugs 
there.

Scott K

Re: postfix-policyd-spf-python

[Scott Kitterman]

On May 12, 2022 9:03:32 PM UTC, Dino Edwards  
wrote:
>Hi,
>
>Not sure if this is the right place to post the question concerning 
>postfix-policyd-spf-python but I can't seem to find any working links for the 
>openspf project.
>
>Our postfix-policyd-spf-python server recently rejected an e-mail from a 
>sender that was using SPF macros. I tried to find out if our version of spf 
>(2.0.0) supported SPF macros but I can't seem to find any information on that. 
>Can someone shed some lights on this?

It does.

Scott K

Re: PATCH: Postfix throws fatal errors when milter is not found

[Scott Kitterman]

On Wednesday, April 6, 2022 3:09:52 AM EDT Christian Degenkolb wrote:
> Hi,
> 
> On 2022-04-04 21:11, Wietse Venema wrote:
> > christ...@degenkolb.net:
> >> How high is the possibility this will, on success, land in a future
> >> release of postfix so I one day I can stop the "build postfix in a
> >> docker container from source"?
> > 
> > The patch is already done for Postfix 3.4 .. 3.8. Expect a code
> > release in a week or so.
> > 
> > The change is safe, because it is in a function that already
> > returns an error when the connection attempt fails. No changes
> > are needed in the callers of that function.
> 
> This is good news. Looking forward to the release. Thanks for your work
> on the mailer daemon.
> I then just have to convince the debian people to include this in
> old-stable or the mailcow people to update the container to debian
> stable.
> Well, some more mails are going to be written.

No need.  It will eventually get updated in Stable and Old Stable, but things 
are moving glacially slow at the moment, so it may be awhile.

Scott K

Re: SPF and policyd

[Scott Kitterman]

On Sunday, February 20, 2022 10:26:56 AM EST Alex wrote:
> Hi, I'm using the SPF policyd service recommended here some time ago.
> I hoped I could ask some questions about how it works since it doesn't
> appear to have any other direct support avenues available.
> 
> I'm trying to understand the following log entry:
> 
> Feb 20 10:01:59 armor policyd-spf[2466782]: prepend X-Comment: SPF
> skipped for whitelisted relay domain - client-ip=168.245.99.219;
> helo=o25.sg.marketing.agoda.global;
> envelope-from=bounces+8548506-62a0-05448=hotel.example.com@marketing.agoda.g
> lobal; receiver=
> 
> None of the IPs or domains listed above are in my local whitelist, but
> the IP is listed in the SPF record for marketing.agoda.global. Is that
> what it is referring to? I tried tracing the code, but I'm not much of
> a python programmer.
> 
> It appears to check the SPF record for the domain in the whitelist,
> not the sending domain. bypass_list_list is the whitelist entries in
> my config.
> 
> for domain in bypass_list_list:
>res = spf.check2(ip, domain, domain,
> querytime=configData.get('Whitelist_Lookup_Time'))
>if domain_res[0] == 'Pass':
>...
> 
> and if it results in "Pass", then it returns True if the domain in the
> whitelist entry, not the sending domain?
> 
> Here's how I have it set up:
> policy-spf  unix  -   n   n   -   -  spawn
>  user=nobody argv=/usr/libexec/postfix/policyd-spf
> 
> And the relevant info from my policyd-spf.conf:
> skip_addresses =
> 139.138.56.0/24,127.0.0.0/8,209.216.90.0/24,:::127.0.0.0/104,::1,52.128.
> 98.0/24,74.203.184.0/24,74.200.60.0/24,209.222.82.0/24 Domain_Whitelist =
> harrimanre.com,ventusnetworks.com,digi.com

That looks like it is working as documented.  Here's the definition of 
Domain_Whitelist:

Domain_Whitelist: List of domains whose sending IPs should be whitelisted from 
SPF checks.  Use this to list trusted forwarders by domain name.  Client IP 
addresses are tested against SPF records published by the listed domains. This
is useful for large forwarders with complex outbound infrastructures and SPF 
records.  This option is less scalable than the SPF IP Whitelist.  An x-header 
is prepended indicating the IP was whitelisted against SPF checks.  This is a 
trace header only.  This option does nothing if the domain does not have an 
SPF record.  In this case use the SPF IP Whitelist described above or 
Domain_Whitelist_PTR (below). 

See man 5 policyd-spf.conf for additional information.  If that's not what you 
want to have happen, you should look at the other options that are mentioned.

https://git.launchpad.net/spf-engine/tree/policyd-spf.conf.5

Scott K

Re: Received-SPF: Temperror

[Scott Kitterman]

On Sunday, February 6, 2022 7:28:22 AM EST Matus UHLAR - fantomas wrote:
> >The spf.py script seems to take the first nameserver only, and whet it
> >gets no response generates the Tempfail error.
> 
> That's bad SW design.  If one nameserver returns fail, you should try
> another one.

It's an issue in the DNS module.  Newer versions of pyspf support either DNS 
or dnspython (and they are alternate depends in Debian 11, the current stable 
release).  If using dnspython (python3-dnspython in Debian), it will do 
exactly that.

Scott K

Re: Received-SPF: Temperror

[Scott Kitterman]

On Saturday, February 5, 2022 11:36:40 AM EST Fourhundred Thecat wrote:
>  > On 2022-02-05 16:00, Scott Kitterman wrote:
> > On Saturday, February 5, 2022 8:48:22 AM EST Fourhundred Thecat wrote:
> >> policyd-spf: prepend Received-SPF: Temperror (mailfrom)
> >> 
> >> identity=mailfrom; client-ip=77.75.76.210; helo=mxd2.seznam.cz;
> > 
> > The policy server itself has the ability to produce more verbose logs that
> > would likely make it clearer what is happening.
> 
> I have increased verbosity level, and now one of the debug lines says:
> 
>spfcheck: pyspf result: "['Temperror', 'SPF Temporary Error: DNS
> Error: exceeded max query lookup time', 'mailfrom']"
> 
> full log here: https://ctxt.io/2/AABg47FDFg
> 
> >  If this was a one time
> > 
> > problem, it may be that there was a temporary DNS issue when resolved
> > itself.
> it is not one time problem. It has been not working for several hours
> already, and the sending server tries again and again to deliver the
> mail unsuccessfully.
> 
> > Also it would be useful to know which version of python3-spf and the
> > policy
> > server you are using as will as if you are using py3dns (DNS module) or
> > dnspython (dns module).
> 
> I am using python3-spf 2.0.12t-3 installed from package on Debian 10.
> I am not using py3dns
> 
> > Relative to the other suggestion of changing the Lookup_Time value, if 20
> > seconds isn't enough you probably have other issues that should be
> > investigated.  That would be a last resort kind of thing in my opinion.
> 
> as i wrote before, the DNS lookup works fine when I execute it manually
> on the mailserver:
> 
> # host -t txt seznam.cz
> seznam.cz descriptive text "v=spf1 mx ip4:77.75.78.0/23
> ip4:77.75.76.0/23 ip6:2a02:598::/32 ?all"
> 
> so it does not look like DNS problem, as far as I can tell.

Here's how you would do essentially the same query as mentioned in the log 
directly with pyspf:

python3 /usr/lib/python3/dist-packages/spf.py 77.75.76.210 seznam.cz 
t...@seznam.cz

All one line.  When I do that (on a Debian 10 system) I get:

result: ('pass', 250, 'sender SPF authorized') ip4:77.75.76.0/23

If you don't have python3-dns installed, that would perhaps explain the 
problem.  The python3-spf package depends on it, so I'm not sure how you 
managed it, but if you did, what you're seeing might be the result.

Scott K

Re: Received-SPF: Temperror

[Scott Kitterman]

On Saturday, February 5, 2022 8:48:22 AM EST Fourhundred Thecat wrote:
> Hello,
> 
> I am using python3-spf and I am getting following error from one host
> trying to deliver email:
> 
>policyd-spf: prepend Received-SPF: Temperror (mailfrom)
> identity=mailfrom; client-ip=77.75.76.210; helo=mxd2.seznam.cz;
> 
> full log here: https://ctxt.io/2/AABgmS4AFw
> 
> What exactly is happening, and what does the Temperror mean?
> 
> Originally I thought there might be temporary problem with DNS
> resolution, but when i try on the mailserver, DNS seems to work finer
> and lists the IP address as authorized:
> 
> # host -t txt seznam.cz
> seznam.cz descriptive text "v=spf1 mx ip4:77.75.78.0/23
> ip4:77.75.76.0/23 ip6:2a02:598::/32 ?all"

https://datatracker.ietf.org/doc/html/rfc7208#section-2.6.6

The policy server itself has the ability to produce more verbose logs that 
would likely make it clearer what is happening.  If this was a one time 
problem, it may be that there was a temporary DNS issue when resolved itself.  
If it's an ongoing problem, I recommend making the policy server's log level 
higher to get a better idea of what's happening.

Also it would be useful to know which version of python3-spf and the policy 
server you are using as will as if you are using py3dns (DNS module) or 
dnspython (dns module).  Recent versions of pyspf support either, but there 
are some related bugs in older versions which might be relevant.

Relative to the other suggestion of changing the Lookup_Time value, if 20 
seconds isn't enough you probably have other issues that should be 
investigated.  That would be a last resort kind of thing in my opinion.

Scott K

Re: Multi-instance and outbound fails SPF

[Scott Kitterman]

On Friday, February 4, 2022 3:14:29 PM EST Wietse Venema wrote:
> Alex:
> > Hi,
> > I have a multi-instance postfix config and am trying to figure out why
> > Microsoft 365 is marking my email from the outbound instance as SPF
> > softfail.
> > 
> > I am trying to send mail from my gmail account to the multi-instance
> > postfix system through to my Microsoft 365 account, where I've set up
> > mail filters to accept mail from all postfix instances without
> > blocking or filtering. All IPs involved are listed in the SPF record
> > for the domain:
> > 
> > example.org.978 IN  TXT "v=spf1
> > ip4:209.222.90.0/24 include:spf.protection.outlook.com -all"
> > 
> > There are two MX records set for this domain - relay1.example.com
> > (209.222.90.118) and relay2.example.com (209.222.90.113). I believe
> > the problem is that mail is leaving through the postfix-out instance
> > (209.222.90.109), and although all IPs are listed in the SPF record,
> > it appears Microsoft doesn't like that it's not being sent from the
> > same IP as it was received?
> 
> Random guess: what name does the MTA send in the EHLO command, and
> does that name match the IP address? The EHLO is not visible in the
> email headers that you included.

Failed HELO check for SPF is indeed a possibility.  

Another one is that their check is buggy.  I have seen cases of them checking 
SPF when receiving mail via an internal relay.  I don't know how common that 
is.  If it's on their end, there's not much you can do about it.

Scott K

Re: Postfix "fatal: daemon initialization failure"

[Scott Kitterman]

On January 26, 2022 4:57:09 PM UTC, Laura Smith 
 wrote:
>Good news, I found the cause of of the problem.
>
>I was using interface aliases to permit different postfix instances.
>
>However these were configured in the traditional/legacy manner using 
>/etc/network/interfaces.
>
>It seems that although the Postfix systemd unit employs the 
>"network-online.target" dependency, this dependency does not recognise the 
>legacy manner of configuring aliases.
>
>Therefore Postifx was crashing becuase it was unable to bind to the IPs that 
>had not yet been bound to the interfaces.
>
>Once I re-configured networking in the modern style using systemd-networkd 
>(/etc/systemd/network/if.network) Postfix was happy because the 
>"network-online.target" dependency was now operating correctly.

If you would file a bug in the Debian BTS with the details, I would appreciate 
it.  I'd like to see what we can do in Debian to improve the situation.

Thanks,

Scott K

Re: How to filter email (DKIM) without keeping the message in memory and without writing it to disc twice?

[Scott Kitterman]

On Saturday, January 15, 2022 8:08:51 PM EST Robert Siemer wrote:
> > > Conceptually DKIM needs to go over the email twice: once to calculate
> > > and sign the checksum and once to write it out with the result of the
> > > previous step in the headers.¹
> > 
> > Prepending a header does not require rewriting the message body.
> > Postfix queue files support efficient header insertion.
> 
> So I read. Good to know.
> 
> > > A DKIM signer can do this by either keeping the message in memory (a
> > > no-go for me) or write it to a file.
> > 
> > Neither is necessary, just compute a streaming checksum, and emit the
> > signature as a prepended header.
> 
> With milter it can indeed. With pipe-like filtering it could not, I believe.
> > > So far I see that the after-queue content filter mechanism
> > > (FILTER_README) forces you to write the email to disc again.
> > 
> > Yes, it forces you to buffer the message content if you want to make
> > body-dependent header modifications.  But do you really need to optimise
> > this to avoid making a copy? Writing 150MB to (SSD) disk or a tmpfs with
> > a few GB of space is quite fast, and the file can be pre-removed aiding
> > cleanup.
> 
> Yes, doable. To be honest, I just feared that there is a flat mail file in
> queue and no way to get it. That looked wrong in my head.
> > > The alternative, the before-queue milter (MILTER_README), is
> > > insufficiently documented for me to see if it avoids keeping the
> > > message in memory and avoids writing the original mail to file twice.
> > 
> > A milter can compute the desired header in a streaming manner, and then
> > respond with a "prepend header" action.
> > 
> > Find some good milter API documentation...
> 
> ...does not reveal how it is implemented in Postfix. But reading Wietse’s
> and your reply I believe it does a smart job here. And I see the advantage
> of a milter solution.
> 
> I guess I go with opendkim. I wish it would support ec25519. Python dkimpy
> and the milter version of it support it, but keep the mail in memory.
> Something I really want to avoid. (An extra write out of an email to file
> is probably less of an issue.)

Newer versions of opendkim do have some support for ed25519, but I think the 
interface is clunky.  This is discussed in a bug report I filed a while ago:

https://github.com/trusteddomainproject/OpenDKIM/issues/6

It might be easier to run two instances, one for RSA signing and one for 
ed25519 signing.

Not keeping the mail in memory for to better support large mails is on my TODO 
list for dkimpy-milter.

Scott K

Re: Received-SPF: Softfail

[Scott Kitterman]

On Monday, January 10, 2022 11:00:43 PM EST Fourhundred Thecat wrote:
> Hello,
> 
> is it safe to ban senders that generate SPF Softfail ?
> 
>policyd-spf: prepend Received-SPF: Softfail
> 
> I have pasted full header here: https://ctxt.io/2/AABg5vIYEw
> 
> What I am asking is, are there situations where legitimate sender
> (non-spam) would generate soft fail?

Yes.

Scott K

Use of CIDR with mynetworks tables

[Scott Kitterman]

Last one on my postfix bug triage pile for today:

A Debian user complained that using CIDR notation in hash tables for 
mynetworks doesn't work.  Of course it doesn't.  I found discussions about 
this going back a long time [1], which suggests to me that the documentation 
might be improved to make this clearer.  Please see the attached patch for 
postconf.5 (I used 3.6.3) as a suggestion.

Thanks,

Scott K

[1] 
https://list.postfix.users.narkive.com/RvXVPsgO/hash-etc-postfix-network-tablediff --git a/man/man5/postconf.5 b/man/man5/postconf.5
index b91b908c..ca15ae36 100644
--- a/man/man5/postconf.5
+++ b/man/man5/postconf.5
@@ -4660,6 +4660,9 @@ Note 2: IP version 6 address information must be specified inside
 "/file/name".  IP version 6 addresses contain the ":" character,
 and would otherwise be confused with a "type:table" pattern.
 .PP
+Note 3: CIDR ranges cannot be specified in hash tables.  Use cidr
+tables if CIDR ranges are used.
+.PP
 Examples:
 .PP
 .nf
@@ -4670,6 +4673,7 @@ mynetworks = !192.168.0.1, 192.168.0.0/28
 mynetworks = 127.0.0.0/8 168.100.189.0/28 [::1]/128 [2001:240:587::]/64
 mynetworks = $config_directory/mynetworks
 mynetworks = hash:/etc/postfix/network_table
+mynetworks = cidr:/etc/postfix/network_table
 .fi
 .ad
 .ft R

Re: Possible issue when user has single space as comment

[Scott Kitterman]

On Monday, January 3, 2022 10:24:07 AM EST Wietse Venema wrote:
> Scott Kitterman:
> > I have been remiss in forwarding this bug report, thinking I would get
> > time to build a concise test case.  It keeps not happening, so here you
> > go.
> > 
> > A Debian user reported [1] a problem where their cleanup process was
> > killed by signal 11 during local mail injection:
> > 
> > Aug 06 16:57:30 amilcar postfix/pickup[11470]: warning:
> > maildrop/88D7A333A: error writing 7082252D6: queue file write error
> > Aug 06 16:57:30 amilcar postfix/master[6205]: warning: process
> > /usr/lib/postfix/sbin/cleanup pid 18641 killed by signal 11
> > 
> > We did the usual is it apparmor dance.  They did provide a trace [2]. 
> > After some work they discovered that the users associated with all the
> > failures had a passwd comment set to a single space, e.g.[3]:
> > 
> > username:x:1234:1234: :/home/username:/bin/bash
> > 
> > This was using Postfix 3.4.14.
> > 
> > Any suggestions?
> 
> This was FIXED IN JULY 2021 with:
> 
> postfix-3.3.19
> postfix-3.4.22
> postfix-3.5.12
> postfix-3.6.2
> 
> Do we have a process problem?
> 
>   Wietse
> 
> 20210705
> 
> Bugfix (introduced: Postfix 3.3): "null pointer read" error
> in the cleanup daemon when "header_from_format = standard"
> (the default as of Postfix 3.3) and email was submitted
> with /usr/sbin/sendmail without From: header, and an all-space
> full name was specified in 1) the password file, 2) with
> "sendmail -F", or 3) with the NAME environment variable.
> Found by Renaud Metrich. File: cleanup/cleanup_message.c.

Thanks.  

We (meaning me) had a problem where I ended up getting distracted from Debian 
for almost a year and no one picked up on postifx stuff while I was gone.  I'm 
working on catching up, both on updating stable releases and on bug triage.  
Maybe I picked the wrong order ...

Scott K

Possible issue when user has single space as comment

[Scott Kitterman]

I have been remiss in forwarding this bug report, thinking I would get time to 
build a concise test case.  It keeps not happening, so here you go.

A Debian user reported [1] a problem where their cleanup process was killed by 
signal 11 during local mail injection:

Aug 06 16:57:30 amilcar postfix/pickup[11470]: warning:
maildrop/88D7A333A: error writing 7082252D6: queue file write error
Aug 06 16:57:30 amilcar postfix/master[6205]: warning: process
/usr/lib/postfix/sbin/cleanup pid 18641 killed by signal 11

We did the usual is it apparmor dance.  They did provide a trace [2].  After 
some work they discovered that the users associated with all the failures had 
a passwd comment set to a single space, e.g.[3]:

username:x:1234:1234: :/home/username:/bin/bash

This was using Postfix 3.4.14.

Any suggestions?

Scott K

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968057
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?
att=1;bug=968057;filename=cleanup.strace.out;msg=5
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968057#29

Re: message_size_limit documentation

[Scott Kitterman]

On Thursday, December 23, 2021 3:51:57 PM EST Wietse Venema wrote:
> Scott Kitterman:
> > Currently, postconf.5 has this to say about message_size_limit:
> > 
> > message_size_limit (default: 1024)
> > 
> > The maximal size in bytes of a message, including envelope
> > information.
> > 
> > Note: be careful when making changes. Excessively small values will
> > result
> > 
> > in the loss of non-delivery notifications, when a bounce message size
> > exceeds the local or remote MTA's message size limit.
> > 
> > 
> > It documents the default, but not the maximum.
> 
> The maximum is determined by (kernel) resource limits, file system sizes,
> and...
> 
> >  Apparently there is one (and
> > 
> > who would care, one of Debian's users, apparently [1]).  I'm not
> > particularly confused about why there would be a maximum, but it might be
> > reasonable to document what it is.  Perhaps add something like "Maximum
> > value is 2147483647." at the end of the note so that users don't have to
> > find out the hard way:
> > 
> > fatal: bad numerical configuration: message_size_limit = 2147483648
> 
> That is the LONG_MAX value for 32-bit machines. It's much bifgger
> for 64-bit systems.
> 
> I guess we could put that in the manpage. I have ab old wishlist
> item to migrate file sizes from to off_t (which is 64 bits on
> most systems).
> 
> But that is a lot of effort, and I was kind-of hoping that 32-bit
> systems will go away.

Thanks.  I don't think it's worth a lot of effort.  I'd imagine it's a pretty 
niche use case to send multi-gigabyte files via SMTP.  People do do it though 
(clearly or there wouldn't be a bug).

I wrestled with a few options for a simple explanation, but didn't come up 
with anything I particularly liked.  I think it's correct that there's a hole 
in the documentation, but I don't have a good recommendation on how to fill it.

Scott K

message_size_limit documentation

[Scott Kitterman]

Currently, postconf.5 has this to say about message_size_limit:

message_size_limit (default: 1024)

The maximal size in bytes of a message, including envelope information.

Note: be careful when making changes. Excessively small values will result 
in the loss of non-delivery notifications, when a bounce message size exceeds 
the local or remote MTA's message size limit.


It documents the default, but not the maximum.  Apparently there is one (and 
who would care, one of Debian's users, apparently [1]).  I'm not particularly 
confused about why there would be a maximum, but it might be reasonable to 
document what it is.  Perhaps add something like "Maximum value is 
2147483647." at the end of the note so that users don't have to find out the 
hard way:

fatal: bad numerical configuration: message_size_limit = 2147483648 

Scott K

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960272

Re: postconf outputs 2 bounce_notice_recipient lines

[Scott Kitterman]

On Wednesday, December 22, 2021 11:00:12 AM EST Wietse Venema wrote:
> Scott Kitterman:
> > > > Any chance of the glibc-2.34 fix being in there too?  We haven't
> > > > switched, so not a rush directly for Debian, but some of our
> > > > downstreams have, so it would be nice to see.
> > > 
> > > What is 'the glibc-2.34 fix'?  closefrom() ?
> 
> Thanks for confirming that this is the closefrom portability fix.
> 
> > > I have been backporting GLIBC workarounds for broken DNSSEC support
> > > 
> > > and they seem to be ignored. Example from Postfix 3.5.1:
> > >Workaround for broken DANE support after an incompatible
> > >change in GLIBC 2.31. THIS AVOIDS THE NEED FOR NEW OPTIONS
> > >IN /etc/resolv.conf. Files: dns/dns.h, dns/dns_lookup.c.
> > > 
> > > I was not impressed with the lack of uptake by distros. That makes
> > > me less motivated to spend time backporting GLIBC workarounds for
> > > trivial problems like closefrom.
> 
> Has this been adopted, or do people on 3.5.* still have to tinker with
> their /etc/resolv.conf files?

Debian hasn't upgraded to 2.34 yet, so I can't say.  I've pinged the Ubuntu 
people that did the patch there for feedback.  Hopefully they or maybe someone 
from Fedora, Gentoo, etc. can tell us.

Scott K

Re: postconf outputs 2 bounce_notice_recipient lines

[Scott Kitterman]

On Wednesday, December 22, 2021 9:35:20 AM EST Wietse Venema wrote:
> Scott Kitterman:
> > >> I was just reviewing the 3.7 development changelog and didn't see
> > >> 2025
> > >> listed.  Is this fix still planned?
> > >
> > >The fix is in the 3.7 code, but I forgot to update the HISTORY file.
> > >It is also planned for the next stable releases, together with the
> > >fix below.
> > >
> > >These are low-priority fixes, so expect to see these early January.
> > >
> > >   Wietse
> > >
> > >20211216
> > >
> > >   Bugfix (introduced: Postfix 3.0): the proxymap daemon did not
> > >   automatically authorize proxied maps inside pipemap (example:
> > >   pipemap:{proxy:maptype:mapname, ...}) or inside unionmap. Problem
> > >   reported by Mirko Vogt. Files: proxymap/proxymap.c.
> > 
> > Thanks.  Certainly no rush.  I only wanted to make sure it wasn't
> > forgotten.
> > 
> > Any chance of the glibc-2.34 fix being in there too?  We haven't
> > switched, so not a rush directly for Debian, but some of our
> > downstreams have, so it would be nice to see.
> 
> What is 'the glibc-2.34 fix'?  closefrom() ?
> 
> I have been backporting GLIBC workarounds for broken DNSSEC support
> and they seem to be ignored. Example from Postfix 3.5.1:
> 
>Workaround for broken DANE support after an incompatible
>change in GLIBC 2.31. THIS AVOIDS THE NEED FOR NEW OPTIONS
>IN /etc/resolv.conf. Files: dns/dns.h, dns/dns_lookup.c.
> 
> I was not impressed with the lack of uptake by distros. That makes
> me less motivated to spend time backporting GLIBC workarounds for
> trivial problems like closefrom.

Sorry for not being clear.

The one discussed in:

https://marc.info/?t=16275452534=1=2

Based on that, Ubuntu came up with:

https://git.launchpad.net/ubuntu/+source/postfix/tree/debian/patches/
postfix-3.6.2-glibc-234-build-fix.patch

Presumably based on the patch metadata Fedora and Gentoo have something 
similar.  I'd imagine others as well.

Scott K

Re: postconf outputs 2 bounce_notice_recipient lines

[Scott Kitterman]

On December 22, 2021 2:34:22 AM UTC, Wietse Venema  wrote:
>Scott Kitterman:
>> On Monday, November 15, 2021 9:03:32 AM EST  wrote:
>> > Vincent Lefevre:
>> > > Under Debian, after the postfix upgrade from 3.5.6 to 3.5.13,
>> > > postconf now outputs duplicate bounce_notice_recipient lines:
>> > > 
>> > > zira:~> postconf | grep '^bounce_notice_recipient'
>> > > bounce_notice_recipient = postmaster
>> > > bounce_notice_recipient = postmaster
>> > > 
>> > > Can you reproduce this?
>> > 
>> > Yes. It was introduced with postfix-3.3-patch19, postfix-3.4-patch22,
>> > postfix-3.5-patch12, and postfix-3.6-patch02.
>> > 
>> > 20210708
>> > 
>> > Bugfix (introduced: 1999): the Postfix SMTP server was
>> > sending all session transcripts to the error_notice_recipient,
>> > instead of sending transcripts of bounced mail to the
>> > bounce_notice_recipient. File: smtpd/smtpd_chat.c.
>> > 
>> > The above replaced error_notice_recipient with bounce_notice_recipient,
>> > but did not update the default setting. The fix for the fix is
>> > below.
>> > 
>> >Wietse
>> > 
>> > 2025
>> > 
>> >Bugfix (introduced: 20210708): duplicate bounce_notice_recipient
>> >entries in postconf output. The fix to send SMTP session
>> >transcripts to bounce_notice_recipient was incomplete.
>> >Reported by Vincent Lefevre. File: smtpd/smtpd.c.
>> > 
>> > The same fix applies to postfix-3.3.19, postfix-3.4.22, postfix-3.5.12,
>> > postfix-3.6.2, and later.
>> > 
>> > --- /var/tmp/postfix/src/smtpd/smtpd.c 2021-07-24 18:20:43.0 
>> > -0400
>> > +++ src/smtpd/smtpd.c  2021-11-15 08:42:43.088958256 -0500
>> > @@ -6419,7 +6419,7 @@
>> >VAR_EOD_CHECKS, DEF_EOD_CHECKS, _eod_checks, 0, 0,
>> >VAR_MAPS_RBL_DOMAINS, DEF_MAPS_RBL_DOMAINS, _maps_rbl_domains, 0, 0,
>> >VAR_RBL_REPLY_MAPS, DEF_RBL_REPLY_MAPS, _rbl_reply_maps, 0, 0,
>> > -  VAR_BOUNCE_RCPT, DEF_ERROR_RCPT, _bounce_rcpt, 1, 0,
>> > +  VAR_BOUNCE_RCPT, DEF_BOUNCE_RCPT, _bounce_rcpt, 1, 0,
>> >VAR_ERROR_RCPT, DEF_ERROR_RCPT, _error_rcpt, 1, 0,
>> >VAR_REST_CLASSES, DEF_REST_CLASSES, _rest_classes, 0, 0,
>> >VAR_CANONICAL_MAPS, DEF_CANONICAL_MAPS, _canonical_maps, 0, 0,
>> 
>> I was just reviewing the 3.7 development changelog and didn't see 2025 
>> listed.  Is this fix still planned?
>
>The fix is in the 3.7 code, but I forgot to update the HISTORY file.
>It is also planned for the next stable releases, together with the
>fix below.
>
>These are low-priority fixes, so expect to see these early January.
>
>   Wietse
>
>20211216
>
>   Bugfix (introduced: Postfix 3.0): the proxymap daemon did not
>   automatically authorize proxied maps inside pipemap (example:
>   pipemap:{proxy:maptype:mapname, ...}) or inside unionmap. Problem
>   reported by Mirko Vogt. Files: proxymap/proxymap.c.

Thanks.  Certainly no rush.  I only wanted to make sure it wasn't forgotten.

Any chance of the glibc-2.34 fix being in there too?  We haven't switched, so 
not a rush directly for Debian, but some of our downstreams have, so it would 
be nice to see.

Scott K

Re: postconf outputs 2 bounce_notice_recipient lines

[Scott Kitterman]

On Monday, November 15, 2021 9:03:32 AM EST  wrote:
> Vincent Lefevre:
> > Under Debian, after the postfix upgrade from 3.5.6 to 3.5.13,
> > postconf now outputs duplicate bounce_notice_recipient lines:
> > 
> > zira:~> postconf | grep '^bounce_notice_recipient'
> > bounce_notice_recipient = postmaster
> > bounce_notice_recipient = postmaster
> > 
> > Can you reproduce this?
> 
> Yes. It was introduced with postfix-3.3-patch19, postfix-3.4-patch22,
> postfix-3.5-patch12, and postfix-3.6-patch02.
> 
> 20210708
> 
> Bugfix (introduced: 1999): the Postfix SMTP server was
> sending all session transcripts to the error_notice_recipient,
> instead of sending transcripts of bounced mail to the
> bounce_notice_recipient. File: smtpd/smtpd_chat.c.
> 
> The above replaced error_notice_recipient with bounce_notice_recipient,
> but did not update the default setting. The fix for the fix is
> below.
> 
>   Wietse
> 
> 2025
> 
>   Bugfix (introduced: 20210708): duplicate bounce_notice_recipient
>   entries in postconf output. The fix to send SMTP session
>   transcripts to bounce_notice_recipient was incomplete.
>   Reported by Vincent Lefevre. File: smtpd/smtpd.c.
> 
> The same fix applies to postfix-3.3.19, postfix-3.4.22, postfix-3.5.12,
> postfix-3.6.2, and later.
> 
> --- /var/tmp/postfix/src/smtpd/smtpd.c2021-07-24 18:20:43.0 
> -0400
> +++ src/smtpd/smtpd.c 2021-11-15 08:42:43.088958256 -0500
> @@ -6419,7 +6419,7 @@
>   VAR_EOD_CHECKS, DEF_EOD_CHECKS, _eod_checks, 0, 0,
>   VAR_MAPS_RBL_DOMAINS, DEF_MAPS_RBL_DOMAINS, _maps_rbl_domains, 0, 0,
>   VAR_RBL_REPLY_MAPS, DEF_RBL_REPLY_MAPS, _rbl_reply_maps, 0, 0,
> - VAR_BOUNCE_RCPT, DEF_ERROR_RCPT, _bounce_rcpt, 1, 0,
> + VAR_BOUNCE_RCPT, DEF_BOUNCE_RCPT, _bounce_rcpt, 1, 0,
>   VAR_ERROR_RCPT, DEF_ERROR_RCPT, _error_rcpt, 1, 0,
>   VAR_REST_CLASSES, DEF_REST_CLASSES, _rest_classes, 0, 0,
>   VAR_CANONICAL_MAPS, DEF_CANONICAL_MAPS, _canonical_maps, 0, 0,

I was just reviewing the 3.7 development changelog and didn't see 2025 
listed.  Is this fix still planned?

Scott K

Re: what's best guess record for SPF

[Scott Kitterman]

On December 10, 2021 4:32:50 AM UTC, raf  wrote:
>On Tue, Dec 07, 2021 at 07:55:54PM +0800, Piper H  wrote:
>
>> I sent an email from my t-online.de account to gmail.
>> Gmail shows SPF pass by best guessing:
>> 
>> Received-SPF: pass (google.com: best guess record for domain of
>> x...@t-online.de designates 194.25.134.18 as permitted sender)
>> client-ip=194.25.134.18;
>> 
>> And t-online.de has no SPF setup for which you can check from their domain.
>> So what's the best guess record by google?
>> 
>> Thanks in advance.
>> Piper
>
>Just guessing of course, but it's probably the fact that
>the host name of 194.25.134.18 is mailout04.t-online.de
>whose parent domain (t-online.de) matches sender domain.
>They might also accept the sender domain's MX hosts, regardless
>of their domain name.
>
>cheers,
>raf

Pyspf still has the original best guess record hidden in the code from when it 
was first written in 2004:

https://github.com/sdgathman/pyspf/blob/0858adb6cf529e696a42318b7938e0b9e8a86c1c/spf.py#L245

No one should be using this anymore, but some still do.  It's relatively safe 
to use for finding pass results, but should never be used in any negative way.  
It's also, formally, not an SPF result because it's not part of the RFC 
4408/7208 definition of SPF.

Pyspf is the only first generation SPF library that's still maintained, so it's 
got some very old pre-IETF bits laying around still.

Scott K

Re: Newbie question - main.cf.proto

[Scott Kitterman]

On December 6, 2021 8:18:11 PM UTC, Herndon Elliott  
wrote:
>I am just getting started with trying to install postifx and get it running
>on a single Ubuntu 18.04 server.  The documentation talks at length about
>changes to be made in "/etc/postfix/main.cf" file, but there is no such
>file in my install.  I have a main.cf.proto, but no main.cf  The only
>mention I can find the documentation of these files is " multi-instance
>template files "
>
>So am I supposed to rename (or better yet, copy) main.cf.proto as main.cf
>before making the changes to it??
>
>The installation instructions certainly could be a bit more explicit about
>this for a beginner

When you installed the package you selected "No configuration", so it's not 
particularly surprising you have no configuration.  Use dpkg-reconfigure 
postfix and pick a different option for configuration and you will have a 
main.cf.  Internet Site is probably the most useful for a starting place.

Scott K

Re: mail-to-script messages id and from lines

[Scott Kitterman]

On Tuesday, November 23, 2021 6:16:43 PM EST Wietse Venema wrote:
> J?rgen Weber:
> > From webe...@host.my.tld  Sun Nov 21 19:11:19 2021
> > Return-Path: 
> > X-Original-To: maild@my.virtual
> > Delivered-To: ma...@host.my.tld
> > Received: by host.my.tld (Postfix, from userid 1001)
> > id D3DFD783; Sun, 21 Nov 2021 19:11:19 +0100 (CET)
> 
> The "id" line should start with tab or space. That's how
> Postfix creates the line.
> 
> > To: maild@my.virtual
> > Subject: s1
> > Message-Id: <20211121181119.d3dfd...@host.my.tld>
> > Date: Sun, 21 Nov 2021 19:11:19 +0100 (CET)
> > From: J?rgen Weber 
> 
> Non-ASCII header text should be encoded with RFC 2o47.
> 
> > Can you prevent Postfix from adding these lines?
> 
> Use egrep.
> 
> If Python's email.Parser can't handle non-ASCII headers, then you
> should not use it for real email management.

It can.  It has trouble with non-UTF-8 if you use the string type internally.  
You have to use byte strings and not everyone does.  I think it's generally 
fine, but there are foot guns to watch out for.

Scott K

Re: PCRE2 Support

[Scott Kitterman]

On November 21, 2021 10:50:24 PM UTC, Wietse Venema  
wrote:
>Wietse Venema:
>> Scott Kitterman:
>> > The original PCRE library that Postfix uses is no longer maintained:
>> > 
>> > https://pcre.org/
>> > 
>> > It's been replaced by PCRE2, which has a notably different API, so Postfix 
>> > PCRE 
>> > support would need porting.  I've looked and it's beyond my limited 
>> > skills.  
>> > Is there any chance of getting this updated for Postfix 3.7?
>> > 
>> > PCRE2 was released 6 years ago, so I would imagine support is reasonably 
>> > widespread.
>> 
>> Thanks for the reminder. Now is the time to start planning
>> the annual stable release.
>
>I have an implementation based on PCRE2 that passes the existing
>Postfix tests for PCRE (which are ASCII based), without triggering
>complaints from Valgrind. I'll release this code first in Postfix
>3.7. After that we can discuss if it makes sense to merge this
>change back into earlier stable Postfix versions.
>
>One visible difference is that the obscure 'X' pattern flag is no
>longer supported, because the underlying PCRE_EXTRA feature no
>longer exists in the PCRE2 library. Postfix ignores the flag and
>logs a warning.
>
>There may be other visible differences in the way that the PCRE2
>library handles malformed UTF8, or content that happens to be using
>a different 8-bit encoding.
>
>I updated the PCRE auto-detection code in the makedefs script. It
>will try to use PCRE2, and if that is not installed, it will try
>to use PCRE. If we merge this back into earlier stable Postfix
>versions, then maybe PCRE should be the default, because breaking
>changes in a stable release are unwelcome.
>
>   Wietse

Great news, thanks.  For Debian's purposes we won't need support for PCRE2 
before 3.7.  I don't know about anyone else.

Scott K

PCRE2 Support

[Scott Kitterman]

The original PCRE library that Postfix uses is no longer maintained:

https://pcre.org/

It's been replaced by PCRE2, which has a notably different API, so Postfix PCRE 
support would need porting.  I've looked and it's beyond my limited skills.  
Is there any chance of getting this updated for Postfix 3.7?

PCRE2 was released 6 years ago, so I would imagine support is reasonably 
widespread.

Scott K

Re: heads up: dkimpy-milter signing breaks w/ python 3.10 (e.g., @ fedora 45 -> 35 upgrade)

[Scott Kitterman]

On November 2, 2021 8:18:54 PM UTC, PGNet Dev  wrote:
>
>i've reported the bug here,
>
>  python 3.10 incompat, exec FAILs @ "SystemError: PY_SSIZE_T_CLEAN macro must 
> be defined for '#' formats"
>   https://bugs.launchpad.net/dkimpy-milter/+bug/1949520
>
>fwiw, python 3.9 still works as expected
>
>now to poke at it ...
>

Thanks.  From the error message, that looks like something from the Python C 
API, so it's almost certainly in the pymilter Python binding for libmilter, not 
in dkimpy-milter itself.

Scott K

Re: will this break DMARC?

[Scott Kitterman]

On August 13, 2021 12:05:44 PM UTC, post...@ptld.com wrote:
>Raf,
>Im confused by this, i thought as long as either dkim or spf passes then 
>dmarc passes. But i still see dmarc fails.
>
>   Envelope-From: dovecot-boun...@dovecot.org
>   Header From: some...@netcourrier.com
>
>   DKIM: bad signature data
>   DMARC: SPF(mailfrom): dovecot.org pass
>   DMARC: netcourrier.com fail
>
>Shouldn't dmarc pass with the good SPF?

It has to pass and align.  Mail from domain and From domain aren't aligned.

Scott K

Re: postfix error shown in mail.log

[Scott Kitterman]

On July 28, 2021 2:58:21 PM UTC, Viktor Dukhovni  
wrote:
>If the postfix-files file does not reflect the content delivered by
>the package, you would typically see errors running "postfix check".
>Either the package should deliver all the files expected upstream,
>or the "postfix-files" file should be updated to match the package
>content.
>

I think it matches.  Last year I went through and checked.  I'll check it again.

Scott K

Re: postfix error shown in mail.log

[Scott Kitterman]

On July 26, 2021 8:59:00 AM UTC, Vincent Lefevre  wrote:
>On 2021-07-24 09:29:04 +1000, raf wrote:
>> On Fri, Jul 23, 2021 at 04:13:00PM +0200, Jean-François Bachelet 
>>  wrote:
>> 
>> > Hello ^^)
>> > 
>> > I found that error in mail.log, at each start postfix issue that error :
>> > 
>> > 'Jul 23 15:36:57 discovery postfix/postfix-script[1170]: warning: symlink
>> > leaves directory: /etc/postfix/./makedefs.out'
>> > 
>> > is that warning harmless or not ?
>> > 
>> > Jeff
>> 
>> I'm pretty sure that that file is put there as part of
>> the debian package (even though it doesn't show up in
>> dpkg-query -L postfix). I had it too.
>
>It is not part of the Debian package, but installed by the
>postfix.postinst script:
>
># we want it out of /etc to not be a conffile, but users might expect it there
># so leave a symlink at the expected place in /etc
>if [ -f "/usr/share/postfix/makedefs.out" ]; then
>if [ ! -e "/etc/postfix/makedefs.out" ]; then
>ln -s /usr/share/postfix/makedefs.out /etc/postfix/makedefs.out
>fi
>fi
>
>If I understand correctly, it is a normal file in postfix
>(it is listed in the postfix 3.6.1 tarball in conf/postfix-files:
>"$meta_directory/makedefs.out:f:root:-:644"), but Debian chose
>to move it into /usr/share/postfix and added a symlink to this
>file. The probable reason is that this file is not a configuration
>file and should not be modified.
>

Close.  

The Debian package management system tracks system induced changes in /etc and 
notifies users about them during package upgrade.  Before I moved the file to 
/usr/share/postfix, there were alerts during package upgrade every time if 
makedefs.out changed (i.e. every time).

I agree with the warning since permissions in the target directory might be 
inappropriate.  In this case I've checked it before I put the symlink in place 
and it's fine.

There are a limited number of options:

1. Don't install makedefs.out, which means the standard postfix installation is 
incomplete (this is what Debian used to do).

2.  Put it in /etc, which means the admin gets notified about changes in the 
file on package upgrade (which made no one happy).

3.  Put it elsewhere and provide a symlink, which means the warning.

4.  Put it elsewhere and patch away the warning.

None of those are ideal.

Scott K 

Re: Postfix - Check SPF for outgoing email

[Scott Kitterman]

On Monday, February 1, 2021 4:32:21 AM EST Jonathan Sélea wrote:
> Hi everyone,
> 
> We currently have a webhosting-environment with many websites. Those
> websites is capable of sending email (obviously) via the local SMTP
> function.
> But sometimes, some of the websites is compromised and used to send
> quite alot of spam from the websites - often using random domains.
> 
> So, one of the "solution" would be to implmement some kind of filter,
> that check the SPF of the domains on outgoing emails and check if they
> include or contain the IP or network of our environment and if not, the
> emails is just discarded.
> Ofcourse, we would employ more anti-spam features, but this would be
> only one of them and could probably save us from blacklisting in some
> cases.
> 
> Thankful for your answers!

You can use the policy server interface with SPF Engine (formerly known as 
pypolicyd-spf) [1] to do a "Prospective SPF Check" (see policyd-spf.conf (5)).  
This checks if an email would pass SPF when received if it were sent from the 
current host. 

If I understand your question correctly, this is what you are asking for.  
This can be installed from source, via pypi, or via you system package manager 
(in many cases).

Scott K


[1] https://launchpad.net/spf-engine

Re: lmd support -- available as an 'add on', or just 'compiled in'?

[Scott Kitterman]

On July 6, 2020 6:01:28 PM UTC, Viktor Dukhovni  
wrote:
>On Mon, Jul 06, 2020 at 10:13:11AM -0700, PGNet Dev wrote:
>
>> I build/use Postfix with LMDB.  Works great.
>> 
>> Looking at distro packages, don't alway find LMDB support compiled
>in.
>> 
>> I can certainly rebuild my own, but wanted to check first:
>
>Various OS distributions build separate packages for the Postfix
>database table drivers.  For example, in Fedora 31:
>
>$ rpm -qf /usr/lib64/postfix/postfix-cdb.so
>postfix-cdb-3.4.13-1.fc31.x86_64
>
>I don't see a similar package for lmdb in Fedora 31, but there is
>for example:
>
>https://centos.pkgs.org/7/ghettoforge-testing-x86_64/postfix3-lmdb-3.5.4-1.gf.el7.x86_64.rpm.html
>
>So depending on your OS distribution, LMDB may be available as a
>separate package.

It's available in Debian and derivatives for some time as postfix-lmdb (Debian 
9 and later).

Scott K

Re: setup issue -- debian /ubuntu 16.04.1 "bad string length 0 < 1: setgid_group ="

[Scott Kitterman]

On Wednesday, June 17, 2020 12:39:06 AM EDT Bob Proulx wrote:
> It resulted in this configuration entry.
> 
> root@turmoil:~# postconf relayhost
> relayhost = smtp.proulx.com:587
> 
> And so it is possible to use that Debian specific installation
> option.  Any more details here should be on a Debian specific mailing
> list.

Those are both good points, but it's also worth noting that typically 
submission requires SMTP Auth which you will have to configure manually after 
doing the above.

Scott K

Re: setup issue -- debian /ubuntu 16.04.1 "bad string length 0 < 1: setgid_group ="

[Scott Kitterman]

On Tuesday, June 16, 2020 11:36:27 PM EDT Gary Aitken wrote:
> It is using default mail port, 25; I need port 465 or 587 because it's my
> understanding google blocks everything on port 25.
> During the setup, I was not (I don't think) given the option of specifying
> smtps or the port.

There's no preconfigured option for that setup.  The satellite system option 
does relay on port 25.  If you want Postfix to do submission, you need to set 
that up manually.

Scott K

Re: The historical roots of our computer terms

[Scott Kitterman]

On Sunday, June 7, 2020 2:03:18 PM EDT vi...@vheuser.com wrote:
> Why not take it off this list and contact the developers?
> Users can't make small changes.
> Enough already.

This list is the appropriate place for users to contact Postfix developers.  
You may not have noticed but the creator of Postfix and it's primary developer 
has been active in this thread.

Scott K

Re: setup issue -- debian /ubuntu 16.04.1 "bad string length 0 < 1: setgid_group ="

[Scott Kitterman]

On Sunday, May 31, 2020 4:31:23 PM EDT Gary Aitken wrote:
> On 5/31/20 11:34 AM, Matus UHLAR - fantomas wrote:
> >> I'm new to postfix and trying to administer a debian
> >> google-compute box, also new to me (coming from fbsd).  So lots of
> >> opportunities for learning...
> >> 
> >> I modified /etc/crontable to fire off some backup stuff (a shell
> >> script that does a "gcloud compute disks snapshot ...".  Cron logs
> >> attempting to start the script, then logs: cron[1214]: sendmail:
> >> fatal: bad string length 0 < 1: setgid_group =
> >> postfix/sendmail[8628]: fatal: bad string length 0 < 1:
> >> setgid_group =
> >> 
> >> As I did not set this system up, it's not clear to me what has
> >> been properly installed and what came as a result of other stuff.
> >> Initially, I was getting a "/etc/postfix/main.cf: No such file or
> >> directory" error.  I copied main.cf.proto to main.cf without
> >> change, as it seemed to be ok as is.
> >> 
> >> It appears postfix was installed as a result of a mysql
> >> installation:
> >> 
> >> aptitude why postfix: i   automysqlbackup Depends  bsd-mailx |
> >> mailx i A bsd-mailx   Depends  default-mta |
> >> mail-transport-agent i A postfix Provides
> >> mail-transport-agent
> >> 
> >> but the setup not completed?  This machine is not intended to
> >> serve as a mail server; I only need it to post mail appropriately.
> >> 
> >> I modified /etc/aliases to forward root, then tried sudo
> >> newaliases but I get the same error: newaliases: fatal: bad string
> >> length 0 < 1: setgid_group =
> > 
> > you should try to run:
> > 
> > dpkg --configure -a to configure all packages that aren't configured
> > yet.
> > 
> > however, so far this problem looks more like ubuntu than postfix
> > problem.
> 
> On 5/31/20 10:59 AM, Wietse Venema wrote:
> > Please DO follow a proper Postfix installation procedure.
> > 
> > - Either install from package.
> > 
> > - Or install from source code.
> > 
> > This is not something that you should be fixing by hand.
> 
> Thank you both.  Before doing something stupid...
> This system has been running in a production environment for
> some time, although what the mail situation has been I'm not sure.
> The production environment involves a redmine installation.
> 
> The postfix package was already installed, which is what troubles
> me; it was apparently not properly configured.  Will an attempt to
> reconfigure an already installed and configured package screw
> things up?  Perhaps it was configured automatically by the
> mysqlbackup install?

> debconf-show shows the one item which *has* been configured is
>postfix/main_mailer_type: No configuration

The Debian configuration that Ubuntu inherits does have an option to not 
configure postfix when installed.  This is intended to  be used by an admin 
that 
intends to do their own configuration from scratch.  It is not intended to be 
left that way indefinitely.

Unfortunately, when postfix is installed as a package dependency of some 
package that wants a local MTA installed, people don't always configure it.  
Since postfix is the default MTA in Ubuntu (it's not in Debian), that means it 
is not unusual to find Ubuntu installations with postfix that are not well 
configured because it was only installed as a side effect of installing some 
other package.

The advice to use dpkg-reconfigure to set up the basic postfix installation 
(that you may then further configure) is the correct approach here.

Scott K

Re: Uninstalling postgrey

[Scott Kitterman]

On Monday, May 25, 2020 10:26:56 PM EDT Ian Evans wrote:
> On Mon, May 25, 2020 at 3:35 PM Ian Evans  wrote:
> > On Mon, May 25, 2020 at 4:09 AM Matus UHLAR - fantomas 
> > 
> > wrote:
> >> On 24.05.20 21:04, 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'd set up postscreen before postgrey, that requires editing master.cf
> >> too.
> >> however, it's quite easy if you follow the docs.
> > 
> > Thanks everyone for the tips. I'll get working on it.
> 
> Just being purposefully thick here so I don't mess anything up. :-)
> 
> In the Postfix docs it says, for example, to uncomment out this line in
> master.cf:
> 
> smtpd   pass-   -  n  -  -  smtpd
> 
> The commented line in my master.cf says:
> 
> #smtpd  pass  -  -  -  -  -  smtpd
> 
> So I'm assuming I not only uncomment the line but also change the third
> hyphen to an 'n'? And so on with the other lines that might be different
> between the docs and the current master.cf?

Assuming postfix version > 3, it doesn't matter.  The third hyphen is for the 
chroot value.  In postfix << 3 the default was y, so an explicit n was needed.  
In postfix >= 3 the default is n, so leaving the '-' is the same as 'n'.

Scott K

Re: "SSL_Shutdown:shutdown while in init" while sending and receiving

[Scott Kitterman]

On Thursday, May 14, 2020 1:40:38 AM EDT Viktor Dukhovni wrote:
> On Wed, May 13, 2020 at 10:01:24PM -0700, Alexander Vasarab wrote:
> > May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio:
> > hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(36) = 0
> > May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success
> > May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: AEF2F102C03E:
> > client=[], sasl_method=LOGIN,
> > sasl_username= May 13 21:56:38 vasaconsulting
> > postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=(nil),
> > wfunc=0x7f310ef37090, SSL_get_error(14) = 0 May 13 21:56:38
> > vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56:38
> > vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil),
> > rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(-1) = 1 May 13 21:56:38
> > vasaconsulting postfix/smtpd[25599]: tls_bio: TLS layer error
> This proves Postfix attempting to call SSL_read, and had not called
> SSL_shutdown(), which is also only called via the tls_bio() function,
> and would have shown up as a non-nil (NULL pointer) value of "hsfunc".
> 
> With a bit of luck Kurt might have something to say some time soon.  I'm
> out of ideas on the Postfix side, and while I'm also an OpenSSL
> committer, I don't know of anything in OpenSSL that would account for
> the symptoms you're reporting.
> 
> Somehow a call to SSL_read() is returning SSL_ERROR_SSL, with reportedly
> untimely calls to SSL_shutdown() on the error stack.
> 
> I'f you're comfortable with gdb, and willing to build both Postfix and
> OpenSSL from source with debugging symbols, then you could add a "-D"
> flag to the "smtpd" entry in the /opt/postfix/etc/master.cf file, and
> attach to a "screen" running a debugger on smtpd, setting a breakpoint
> in SSL_shutdown, and continue.  Then report a stack trace...
> 
> http://www.postfix.org/DEBUG_README.html#screen
> 
> I can't expect you're that curious, but if you are, go for it.  This is
> rather a weird case.  You may be able to install the debian debug symbol
> package for at least OpenSSL, saving the hassle of building the package
> yourself.  Don't know whether there is also a debug symbol package for
> Postfix.

Debian automatically builds debug symbol packages for ~all packages.  They are 
located in a separate package repository.  For instructions on how to enable 
it and install them, see:

https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Scott K

Re: why DMARC PASS even SPF got failed

[Scott Kitterman]

On Tuesday, April 28, 2020 8:17:54 AM EDT Matus UHLAR - fantomas wrote:
> >>Scott Kitterman wrote:
> >>> Yes.  If either passes and the relevant identifier is aligned, DMARC
> >>> passes.
> >
> >On April 28, 2020 9:29:59 AM UTC, Philip  wrote:
> >>Scott, I have another question.
> >>Given the case there is no DKIM signed in original message, when
> >>forwarding MTA implement a SRS in the outgoing forwarded email, the
> >>receiving MTA will think the envelop domain was not matched with From:
> >>domain in message header.
> >>
> >>In this case will DMARC fail?
> 
> On 28.04.20 10:17, Scott Kitterman wrote:
> >Yes.  That fails the "if aligned" part of the test.
> 
> however, SPF will not fail here.  So, sender using DKIM and forwarder using
> SRS fill make both SPF and DMARC pass.

True, but not the OP's question (assuming the DKIM signature verifies and 
aligns).  

Scott K

Re: why DMARC PASS even SPF got failed

[Scott Kitterman]

On April 28, 2020 9:29:59 AM UTC, Philip  wrote:
>Scott Kitterman wrote:
>> Yes.  If either passes and the relevant identifier is aligned, DMARC
>passes.
>
>Scott, I have another question.
>Given the case there is no DKIM signed in original message, when 
>forwarding MTA implement a SRS in the outgoing forwarded email, the 
>receiving MTA will think the envelop domain was not matched with From: 
>domain in message header.
>
>In this case will DMARC fail?

Yes.  That fails the "if aligned" part of the test.

Scott K

Re: why DMARC PASS even SPF got failed

[Scott Kitterman]

On April 28, 2020 9:20:01 AM UTC, Philip  wrote:
>Scott Kitterman wrote:
>> I predict you won't find this a satisfying answer, but the rest of
>RFC 7489.
>> 
>> Instead of quoting bits of various web sites and how-to's back and
>forth, l think it makes sense to read the actual specification if you
>want to understand the protocol.
>
>OK I read that. does it mean, either DKIM domain is passed, or SPF 
>domain is passed, this DMARC setting for the domain could be passed?

Yes.  If either passes and the relevant identifier is aligned, DMARC passes.

Scott K

Re: why DMARC PASS even SPF got failed

[Scott Kitterman]

On April 28, 2020 8:58:28 AM UTC, Philip  wrote:
>Scott Kitterman wrote:
>>> My question is, since SPF got SOFTFAIL by gmail, why it still says
>>> DMARC
>>> PASS?  Shouldn't SPF failed cause DMARC failure?
>> No.  See RFC 7489, Section 4.2, last paragraph.
>
>what's the background knowledge?
>
I predict you won't find this a satisfying answer, but the rest of RFC 7489.

Instead of quoting bits of various web sites and how-to's back and forth, l 
think it makes sense to read the actual specification if you want to understand 
the protocol.

Scott K

Re: why DMARC PASS even SPF got failed

[Scott Kitterman]

On April 28, 2020 8:42:20 AM UTC, Philip  wrote:
>Hello
>
>I sent a message from mail.ru, who has p=reject setting in their DMARC 
>record, to an email account at OVH.
>
>OVH forwards this email to gmail, as we know during the forwarding OVH 
>doesn't implement SRS. So after receiving the email, gmail shows SPF
>failed.
>
>This is the message header in gmail:
>
>Subject:DMARC testing
>SPF:SOFTFAIL with IP 178.32.228.79 Learn more
>DKIM:'PASS' with domain mail.ru Learn more
>DMARC:'PASS' Learn more
>
>
>My question is, since SPF got SOFTFAIL by gmail, why it still says
>DMARC 
>PASS?  Shouldn't SPF failed cause DMARC failure?

No.  See RFC 7489, Section 4.2, last paragraph.

Scott K

Re: PATCH: Glibc-2.31 DNSSEC and GCC 10

[Scott Kitterman]

On Thursday, April 16, 2020 10:31:56 AM EDT Wietse Venema wrote:
> With the minnimal patch below, it looks like Postfix DANE support
> will continue to work after a breaking change in Glibc 2.31. Tested
> on Fedora 32 beta.
> 
> This patch also deals with the 'multiple definition' errors caused
> by a breaking change in GCC 10. Also tested on Fedora 32 beta.
> 
> Plan is to release this in Postfix 3.6 (development release)
> and then update the stable releases.

Thank you for this.

The Debian bug report about Postfix failing to build with GCC-10 arrived today, 
so your timing was excellent for me.

Scott K

Re: MTA-STS?

[Scott Kitterman]

On Tuesday, April 7, 2020 11:15:27 AM EDT David Mehler wrote:
> Hello,
> 
> I just heard about this and started reading on it. Is MTA-STS
> something Postfix works with?

You need https://github.com/Snawoot/postfix-mta-sts-resolver and then yes.

Scott K

Re: delaying postfix until/unless VPN is up/connected

[Scott Kitterman]

On Monday, March 23, 2020 7:47:25 PM EDT Bob Proulx wrote:
> On my Debian (and therefore Ubuntu, Mint, other derivatives) I would
> add a script /etc/network/if-up.d/postfix-local (in addition to the
> already existing "postfix" script there) that does this when the VPN
> interface comes up, and a script /etc/network/if-down.d/postfix-local
> for the other end.

if-up and if-down are Debian (and derivative) specific.  I don't believe it is 
shared with distros from any other lineage.

Scott K

Re: Postfix stable release 3.5.0

[Scott Kitterman]

On March 16, 2020 10:49:26 PM UTC, Viktor Dukhovni  
wrote:
>On Mon, Mar 16, 2020 at 10:16:13AM -0400, Wietse Venema wrote:
>
>> [An on-line version of this announcement will be available at
>> http://www.postfix.org/announcements/postfix-3.5.0.html]
>> 
>> Postfix stable release 3.5.0 is available. Support has ended for
>> legacy release Postfix 3.1.
>
>Congratulations and thanks for the continued support!
>
>This is roughly (I am surely missing some early snapshots) number 1145
>in a linear sequence of public snapshots starting with beta-19990122 (I
>don't have a copy of anything earlier).
>
>Including stable release updates and non-prod snapshots the total
>tarball count rises to 1653.  A daunting volume of work over more than
>21 years.  Much appreciated.


Absolutely.

I've uploaded 3.5.0 to Debian Unstable and it's built on all 19 Linux 
architectures we build for.  That seems like a lot to me.  Cross-platform 
support doesn't happen by accident.

I'd also like to take special note of the long support for existing releases.  
Because of the consistently high quality of postfix updates, we do post-Debian 
release updates for our stable users.  We've been able to provide them with a 
continuously improving experience through delivering these updates (a Debian 
oldstable user can install 3.1.15 from our repositories and 3.4.10 should be 
available for stable in a few days).  I really appreciate your continuing 
commitment to quality.

Scott K

Re: How to match From as MAILFROM

[Scott Kitterman]

On Monday, March 16, 2020 5:54:02 AM EDT Burn Zero wrote:
> Hi,
> 
> I have configured an internal postfix server where users will use that as
> relay servers to relay emails to outside and internal users.
> 
> I have restricted postfix to allow only one domain as MAILFROM and deny
> rest all. But how to restrict From address like this? Is there any way in
> postfix?

It's out of scope for postfix itself to do that, but vrfydmn [1] does exactly 
that and can be added to your postfix configuration.

Scott K

[1] https://github.com/croessner/vrfydmn

Re: tls stopped working after update from 3.1.14 to 3.4.8

[Scott Kitterman]

On February 24, 2020 8:47:49 AM UTC, Viktor Dukhovni 
 wrote:
>> 
>> On Feb 24, 2020, at 2:27 AM, Michael  wrote:
>> 
>> Feb 22 08:50:07 mail postfix/smtpd[12952]: connect from
>bendel.debian.org[82.195.75.100]
>> Feb 22 08:50:07 mail postfix/smtpd[12952]: setting up TLS connection
>from bendel.debian.org[82.195.75.100]
>> Feb 22 08:50:07 mail postfix/smtpd[12952]:
>bendel.debian.org[82.195.75.100]: TLS cipher list
>"aNULL:-aNULL:HIGH:MEDIUM:LOW:+RC4:@STRENGTH:!aNULL"
>> Feb 22 08:50:07 mail postfix/smtpd[12952]: SSL_accept:before SSL
>initialization
>> Feb 22 08:50:07 mail postfix/smtpd[12952]: SSL_accept:before SSL
>initialization
>> Feb 22 08:50:07 mail postfix/smtpd[12952]: SSL_accept:SSLv3/TLS read
>client hello
>> Feb 22 08:50:07 mail postfix/smtpd[12952]: SSL_accept:SSLv3/TLS write
>server hello
>> Feb 22 08:50:07 mail postfix/smtpd[12952]: SSL_accept:SSLv3/TLS write
>change cipher spec
>> Feb 22 08:50:07 mail postfix/smtpd[12952]: SSL_accept:TLSv1.3 write
>encrypted extensions
>> Feb 22 08:50:07 mail postfix/smtpd[12952]: SSL_accept:SSLv3/TLS write
>certificate request
>> Feb 22 08:50:07 mail postfix/smtpd[12952]: SSL_accept:SSLv3/TLS write
>certificate
>> Feb 22 08:50:07 mail postfix/smtpd[12952]: SSL_accept:TLSv1.3 write
>server certificate verify
>> Feb 22 08:50:07 mail postfix/smtpd[12952]: SSL_accept:SSLv3/TLS write
>finished
>> Feb 22 08:50:07 mail postfix/smtpd[12952]: SSL_accept:TLSv1.3 early
>data
>> Feb 22 08:55:07 mail postfix/smtpd[12952]: SSL_accept:error in
>TLSv1.3 early data
>> Feb 22 08:55:07 mail postfix/smtpd[12952]: SSL_accept error from
>bendel.debian.org[82.195.75.100]: lost connection
>> Feb 22 08:55:08 mail postfix/smtpd[12952]: lost connection after
>STARTTLS from bendel.debian.org[82.195.75.100]
>> Feb 22 08:55:08 mail postfix/smtpd[12952]: disconnect from
>bendel.debian.org[82.195.75.100] ehlo=1 starttls=0/1 commands=1/2
>
>This looks like a client (or firewall, etc. in between) that does not
>correctly support TLS 1.3.  What's new on your system is not Postfix
>3.4,
>but a sufficiently recent version of OpenSSL that has TLS 1.3 support.
>
>The client appears to have just disconnected after the server's
>"finished"
>message, with no TLS alert sent to indicate the nature of the problem.
>
>You could try getting a PCAP file, and decode that, but with TLS 1.3,
>a large fraction of the handshake is encrypted, debugging can be
>more difficult.
>
>Were TLS sessions failing from all senders or just particular systems?

Since the host in the example is a Debian mail server (it hosts the project 
mailing lists), I checked.  It's running Debian 10 (same as the OP) using 
Postfix 3.4 (.6, .7, or .8 depending on when it was last updated), so it should 
support TLS 1.3 with no problem (I don't have access to the Postfix or Openssl 
configuration, so in theory it could have been manually disabled).  That points 
to your "or something in between" theory.  Since it appears to be all hosts, 
I'd guess something very nearby the OP's system.

Scott K

Re: SPF IP addresses limit question

[Scott Kitterman]

On February 24, 2020 4:30:37 AM UTC, Mohamed Lrhazi  wrote:
>Thanks all,
>
>My question still was: Suppose I comply with all the recommendations
>and
>best practices in composing my SPF records... Do I still need to worry
>about the number of IP addresses (v4/v6/ciders) that I put in each
>record?
>
>I guess if I could really stick with sub 512 bytes records, I could not
>put
>more than 20ish ip4 mechanisms and even less if including ip6 ones. And
>using includes I could not have more than 10 of such records.

I think if Google can manage to describe their outgoing mail architecture 
within those limits, most everyone else can too.  In the cases I've 
investigated where providers weren't it's always been a matter of poor record 
maintenance, not inherent limits being a problem.

That said, the spf-discuss mailing list is probably a better place to argue 
details of SPF protocol design.

Scott K

Re: SPF IP addresses limit question

[Scott Kitterman]

On Sunday, February 23, 2020 6:44:34 PM EST Mohamed Lrhazi wrote:
> On Sun, Feb 23, 2020 at 3:23 PM Benny
> 
> > https://dmarcian.com/spf-survey/?domain=spf.255.cuaemail.org
> > 
> > see Record flattening
> 
> record flattening is the process of replacing include, and other lookup
> generating mechanisms, with their resulting ip addresses.
> My question is how many IPs can one put in a single spf record?
> 
> It appears the RFC does not touch on this, so I guess it’s left to the
> implementors to decide, and from my limited tests it seems to vary a lot.

The limits are a function of DNS, not SPF, which is why RFC 7208 Section 3.4.
 was written.

Scott K

Re: SPF IP addresses limit question

[Scott Kitterman]

On Sunday, February 23, 2020 3:26:07 PM EST Benny Pedersen wrote:
> Scott Kitterman skrev den 2020-02-23 21:03:
> > There is no hard limit.  See RFC 7208 Section 3.4.
> 
> sadly :(
> 
> even ip4:0.0.0.0/0 is valid
> 
> could pypolicyd-spf break rfc so only domains under 255 ipv4 is valid
> results ?, imho its insane that its supported unlimited

It is what it is, so no.  People ignore Section 3.4 at their own peril 
(although EDNS0 is better supported, so it's possibly too strict for 2020).  I 
think it's a self-limiting problem.

Also, pypolicyd-spf was renamed spf-engine when I added a milter interface 
option for it, so please switch to that.  No more updates to the old 
pypolicyd-spf code.

Scott K

Re: SPF IP addresses limit question

[Scott Kitterman]

On Sunday, February 23, 2020 2:53:28 PM EST Mohamed Lrhazi wrote:
> Hello all,
> 
> Sorry for a non-postfix specific question.
> 
> I am running into an issue with a big SPF record I had been maintaining. I
> went ahead a broke it up using the include: mechanism, but am still trying
> to figure out the limit I did hit.
> 
> For testing purposes, I send emails from this addr...@spf.255.cuaemail.org
> to gmail, yahoo.com, and outlook.com
> 
> The SPF record for that domain is made up of 255 ip4 addresses, the last of
> which is my true client IP. Please check it out with dig.
> 
> gmail and yahoo fail the SPF test. outlook passes.
> 
> Using addr...@spf.101.cuaemail.org, gmail also passes. The SPF for this
> domain has 101 addresses.
> 
> Using addr...@spf.63.cuaemail.org, yahoo also passes.
> 
> So am concluding these vendors have these limits for the number of IPs in a
> single SPF record... would that be correct conclusion? anyone knows if this
> is documented by these vendors?
> 
> I opened a case with Google and so far they have been insisting there is no
> such limit!

There is no hard limit.  See RFC 7208 Section 3.4.

Scott K

Re: Disable function "said: 550 Blocked by SPF () (in reply to MAIL FROM command))"

[Scott Kitterman]

On Tuesday, January 14, 2020 7:39:05 AM EST Emanuel wrote:
> Hello everyone.!
> 
> I see this error in the postfix logs:
> 
> said: 550 Blocked by SPF () (in reply to MAIL FROM command))
> 
> Jan 14 09:31:46 antartida postfix/smtpd[16086]: 9248680010:
> client=a48-146.smtp-out.amazonses.com[54.240.48.146]
> Jan 14 09:31:46 antartida postfix/cleanup[16162]: 9248680010:
> message-id=<0100016fa4095ae5-d7ad3acb-ae83-4ec5-98b7-2caf1aa89dda-00@ema
> il.amazonses.com> Jan 14 09:31:47 antartida postfix/qmgr[16065]: 9248680010:
> from=<0100016fa4095ae5-d7ad3acb-ae83-4ec5-98b7-2caf1aa89dda-00@amazonses
> .com>, size=18774, nrcpt=1 (queue active)
> Jan 14 09:31:47 antartida postfix/smtp[16067]: 9248680010:
> to=,
> relay=mail.aylendepartamentos.com.ar[200.58.120.110]:25, delay=1.8,
> delays=1.6/0/0.17/0, dsn=4.0.0, status=SOFTBOUNCE (host
> mail.aylendepartamentos.com.ar[200.58.120.110] said: 550 Blocked by SPF
> () (in reply to MAIL FROM command))
> 
> Postifix does not use any spf policy, the configuration is here:
> 
> https://pastebin.com/kK6yCnFM
> 
> any ideas? I'm losing emails because of this
> 
> Regards,

The error message comes from the remote server.  Based on a quick Google 
Search, it's hmailserver [1], nothing to do with Postfix.  Since it's SPF 
specific, the spf-help mailing list [2] would be a good place to ask for help.

Scott K

[1] https://www.hmailserver.com/
[2] https://spf.topicbox.com/groups/spf-help/subscription

New dkimpy-milter release with multiple domain support

[Scott Kitterman]

There's been more than once that someone asked here when I'd have multiple 
domain support available for dkimpy-milter.  Now.  I've released 1.2.0.  It 
can be installed via pip or you can download the source from pypi or https://
launchpad.net/dkimpy-milter/1.2/1.2.0 .

I don't intend to make a habit of such announcements.

Scott K

Re: smtpd_policy_service_timeout question

[Scott Kitterman]

On Sunday, December 29, 2019 9:01:12 AM EST Wietse Venema wrote:
> Scott Kitterman:
> > If Postfix smtpd is waiting for a response to an in progress request
> 
> An SMTP client request or policy request?

Policy request.

> > and the smtpd_policy_service_timeout is reached, does Postfix keep
> > the pipe open until that request completes or does it close it
> > right away?
> 
> smtpd_policy_service_timeout is the limit for connecting to, writing
> to, or receiving from a policy server.
> 
> - If this expires while the Postfix SMTP server is waiting for an
> SMTP client request, nothing happens.
> 
> - If this expires while writing to, or receiving from a policy
> server, the Postfix SMTP server will disconnect from the policy
> server, and new connection, and retry the policy request.
> 
> > Is it sufficient to set it to slightly higher than the maximum
> > time the policy service is supposed to run for a single request
> > are should it be substantially higher than that?
> 
> I would not recommend to set timeouts just a little higher than
> needed. If, not when, some system becomes overloaded, having 'tight'
> timeouts will just make things worse.
> 
>   Wietse

For the policy server in question, the 100s default should be more than 2x the 
maximum time the policy request can take, even if DNS is very slow, but there 
are configuration options users might select that could make it a much closer 
thing.  That clarifies it for me enough that I believe I can get my 
documentation correct.

Thanks,

Scott K

smtpd_policy_service_timeout question

[Scott Kitterman]

If Postfix smtpd is waiting for a response to an in progress request and the 
smtpd_policy_service_timeout is reached, does Postfix keep the pipe open until 
that request completes or does it close it right away?

Is it sufficient to set it to slightly higher than the maximum time the policy 
service is supposed to run for a single request are should it be substantially 
higher than that?

Scott K