[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