On 2025-04-17 at 20:49:12 UTC-0400 (Fri, 18 Apr 2025 02:49:12 +0200)
Ralph Seichter via Postfix-users
is rumored to have said:
> * Alex via Postfix-users:
>
>> It looks like this is the place to start?
>> https://github.com/milter-regex/milter-regex/tree/main
>
> I recommend starting at http://be
Paul Enlund via Postfix-users:
> Hello
>
> Using postfx 3.6.4
>
> need help /guidance on how best to resolve the problem below. I am 100%
> sure the email arriving has looped many times and will have way to many
> Received headers this time.
>
> Is this deferral coming from 1 of the 3 milters
RBTC System Administrator via Postfix-users:
> macro after receiving a reject. It runs quickly and returns "continue"
> to close the connection. I don't believe
> that it would be appropriate to put a mutex around the block of code
> that returns the reject. The only
The Postfix milter client
Ok so i knew calling it a program wasn't right. A binary called only opendkim
doesn't exist. Not under /bin, /sbin or the same under /usr
There are only binaries called opendkim-x , so my thought now is to
reinstall opendkim cause something's off.
On January 22, 2025 3:36:50 PM PST, Jaro
Dnia 22.01.2025 o godz. 14:22:05 Curtis Vaughan via Postfix-users pisze:
>
> mv opendkim opendkim-real
>
> I'm moving /usr/sbin/opendkim to /usr/bin/opendkim-real ? Nope, there is no
> such prog there. Many starting with opendkim-.
That's absolutely correct that there is no such program. If
If you have difficulty following my command example, then
you should certainly not follow my old-school instructions.
Maybe there is some new-school tool to instrument systemd jobs
that I haven't heard about. systemd-gdb, anyone?
Wietse
___
Po
Just to be sure I'm doing this right.
mv opendkim opendkim-real
I'm moving /usr/sbin/opendkim to /usr/bin/opendkim-real ? Nope, there is no
such prog there. Many starting with opendkim-.
cat >opendkim ? What I'm cat-ing to a file opendkim?
#!/bin/sh ? this would be the beginning
Curtis Vaughan via Postfix-users:
> But doesn't this mean it is running?
>
> systemctl status opendkim
>
> Process: 2177789 ExecStart=/etc/init.d/opendkim start (code=exited,
> status=0/SUCCESS)
But doesn't this mean it has exited?
Maybe you can finally try the old-chool stuff.
Curtis Vaughan via Postfix-users:
I realize there have been a lot of posts about this issue, but in my
attempts so far, nothing has resolved this issue for me.
The postfix server in question is running on Ubuntu LTS 24.04 and has
been in operation for over a decade. But today while looking in
Curtis Vaughan via Postfix-users:
> I realize there have been a lot of posts about this issue, but in my
> attempts so far, nothing has resolved this issue for me.
>
> The postfix server in question is running on Ubuntu LTS 24.04 and has
> been in operation for over a decade. But today while loo
Gerd Hoerst via Postfix-users:
> Hi !
>
> i guess this is the line
>
> non_smtpd_milters = inet:localhost:8891, inet:localhost:8893,
> permit_mynetworks, permit_sasl_authenticated
Indeed. However, fixing this may expose other mistakes.
Wietse
___
Hi !
i guess this is the line
non_smtpd_milters = inet:localhost:8891, inet:localhost:8893,
permit_mynetworks, permit_sasl_authenticated
Am 29.12.2024 um 16:25 schrieb Wietse Venema via Postfix-users:
Gerd Hoerst via Postfix-users:
Hi !
as i wrote in a previous post im moving my mail serv
Gerd Hoerst via Postfix-users:
> Hi !
>
> as i wrote in a previous post im moving my mail server to another one
> with mostly copying the config..
>
> i made some tests before moving it...
>
> Now i have some warnings in my log which i cannot associate
>
> 2024-12-29T14:09:37.542057+01:00 virg
On Sun, Dec 29, 2024 at 02:16:31PM +0100, Gerd Hoerst via Postfix-users wrote:
> Hi !
>
> as i wrote in a previous post im moving my mail server to another one with
> mostly copying the config..
>
> i made some tests before moving it...
>
> Now i have some warnings in my log which i cannot assoc
Wietse Venema via Postfix-users:
> Laura Steynes via Postfix-users:
> > Hi,
> > I've noticed since implementing milter-regex that if there is an inbound
> > message addressed to two addresses, that if one is caught by a milter-regex
> > reject rule (stopping a html message to a system address which
Laura Steynes via Postfix-users:
> Hi,
> I've noticed since implementing milter-regex that if there is an inbound
> message addressed to two addresses, that if one is caught by a milter-regex
> reject rule (stopping a html message to a system address which does some
> automation), but the other rec
On Sat, Dec 14, 2024 at 04:20:26PM +1000, Laura Steynes via Postfix-users wrote:
> I've noticed since implementing milter-regex that if there is an inbound
> message addressed to two addresses, that if one is caught by a milter-regex
> reject rule (stopping a html message to a system address which
Hi
In process list I sow always milter
mailregx 42670 16.6 0.0 920172 6000 ? Ssl 11:19 2:54
/usr/bin/milter-regex -c /etc/postfix/milter-regex.conf -u mailregx -G
postfix -p /var/run/milter/milter-regex.sock
W dniu 5.12.2024 o 11:34, natan via Postfix-users pisze:
Hi
Today i run
Thank you very much indeed for the quick response. I appreciate it and
I understand that XFORWARD is for logging and reporting purposes only.
I am afraid that HAPROXY is not an option for me but I will look
further at XCLIENT.
I think that this milter would probably have been better as a content
f
Anton Hofland via Postfix-users:
> I have this milter that sits on a server which is not directly
> connected to the internet. Instead there is an internet facing firewall
> mail server in front of it which has all the usual defences. There are
> many reasons for this, some of which are just my pre
On Tue, Sep 10, 2024 at 01:44:39PM +0200, Anton Hofland via Postfix-users wrote:
> I have this milter that sits on a server which is not directly
> connected to the internet. Instead there is an internet facing firewall
> mail server in front of it which has all the usual defences. There are
> many
Christian Zoffoli via Postfix-users:
> Using a load balancer like HAProxy for MySQL connections allows
> balancing only on servers that are synchronized. Direct use of multiple
> MySQL hosts in Postfix does not allow for any checks.
If you want to load balance N mysql servers behind 1 load balan
Using a load balancer like HAProxy for MySQL connections allows
balancing only on servers that are synchronized. Direct use of multiple
MySQL hosts in Postfix does not allow for any checks. Given this, the
example of MySQL, which could also be the balancing of multiple LMTP
connections to IMAP
Christian Zoffoli via Postfix-users:
> I'm asking because I was using it with HAProxy, and with the load
> balancer between Postfix and the two Rspamd machines, I often have
> unexplainable timeouts. In general, I see that Postfix does not like
> interacting with load balancers; I've had similar
I'm a long-time sendmail users about to deploy my first Postfix server
and will be moving my MIMEDefang/MailMunge milter to it. They provide
their own multiplexor. (MailMunge is a fork of MIMEDefang. Both allow
one to write filters in Perl and provide a sample filter script that
invokes ClamD,
I'm asking because I was using it with HAProxy, and with the load
balancer between Postfix and the two Rspamd machines, I often have
unexplainable timeouts. In general, I see that Postfix does not like
interacting with load balancers; I've had similar issues with MySQL
connections always balanc
Christian Zoffoli via Postfix-users:
> Hello,
> is there a way to use multiple milters in round-robin without using a
> load balancer? From what I can see in version 3.9, using multiple
> milters separated by commas results in them being used in sequence.
This is not built into Postfix.
If you
Wietse Venema via Postfix-users wrote in
<4vvgyx1yynzj...@spike.porcupine.org>:
|Wietse Venema via Postfix-users:
|> Looks like there is sufficient basis to make SMTPD_QUIT_NC rerquests
|> thts from Postfix. Just need to figure out how to enable/disable
|> this particular command based on the
Wietse Venema via Postfix-users:
> Looks like there is sufficient basis to make SMTPD_QUIT_NC rerquests
> thts from Postfix. Just need to figure out how to enable/disable
> this particular command based on the Postfix and Milter protocol
> versions. There is already some 'set' intersection code for
Wietse Venema via Postfix-users wrote in
<4vqwxx2jpbzj...@spike.porcupine.org>:
|> * For smfi_chgheader, filter order is important. Later
|>filters will see the header changes made by earlier ones.
|
|Yes, that is fundamental to the way that the Milter API works. Each
|Milter "in
> * For smfi_chgheader, filter order is important. Later
>filters will see the header changes made by earlier ones.
Yes, that is fundamental to the way that the Milter API works. Each
Milter "inspects" the header and body content that exists after
Postfix and previous Milters have mad
Wietse Venema via Postfix-users wrote in
<4tqsmy5jfczj...@spike.porcupine.org>:
|Wietse Venema via Postfix-users:
|> 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.
|>
|
Claus Assmann via Postfix-users wrote in
<20240307053606.ga48...@veps.esmtp.org>:
|On Wed, Mar 06, 2024, Wietse Venema via Postfix-users wrote:
|
|>> Again, Postfix does not store line terminators, not when email comes
|>> from UNIX tool with \n, via SMTP with \r\n, or encapsulated as
|>> net
Wietse Venema via Postfix-users wrote in
<4tqsmy5jfczj...@spike.porcupine.org>:
|Wietse Venema via Postfix-users:
|> 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.
|>
|
Claus Assmann via Postfix-users:
> On Wed, Mar 06, 2024, Wietse Venema via Postfix-users wrote:
>
> > > 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.
>
> > In headers
On Wed, Mar 06, 2024, Wietse Venema via Postfix-users wrote:
> > 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.
> In headers that Postfix sends to a milter. I may want to c
Wietse Venema via Postfix-users:
> 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.
>
> Instead, Postfix generates line terminators upon output, and until
> now they are always \n
Hello Scott Kitterman.
Scott Kitterman via Postfix-users wrote in
:
..
|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 \
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...@sp
Steffen Nurpmeso via Postfix-users wrote in
<20240306193747.mAtzRjYs@steffen%sdaoden.eu>:
...
|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).
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 messa
Wietse Venema via Postfix-users wrote in
<4tqkyr4p2zzj...@spike.porcupine.org>:
|Looks like there is sufficient basis to make SMTPD_QUIT_NC rerquests
|thts from Postfix. Just need to figure out how to enable/disable
|this particular command based on the Postfix and Milter protocol
|versions. T
FYI: the libmilter interface is an internal communication protocol.
It is NOT publically documented on purpose (hence complaining about
missing documentation is somehow annoying).
--
Please don't Cc: me, use only the list for replies.
___
Postfix-users
Looks like there is sufficient basis to make SMTPD_QUIT_NC rerquests
thts from Postfix. Just need to figure out how to enable/disable
this particular command based on the Postfix and Milter protocol
versions. There is already some 'set' intersection code for doing
such things on the Postfix side.
Wietse Venema via Postfix-users wrote in
<4tqfyk4qzqzj...@spike.porcupine.org>:
|Steffen Nurpmeso via Postfix-users:
|> Wietse Venema via Postfix-users wrote in
|> <4tqc213rcwzj...@spike.porcupine.org>:
|>|So you're suggesting that as long as an MTA-to Milter connection
|>|is not in an error
Steffen Nurpmeso via Postfix-users:
> Wietse Venema via Postfix-users wrote in
> <4tqc213rcwzj...@spike.porcupine.org>:
> |So you're suggesting that as long as an MTA-to Milter connection
> |is not in an error state, sending
> |
> |SMFIC_QUIT_NC
> |
> |and later sending
> |
> |SM
Steffen Nurpmeso wrote in
<20240131203248.XtHi_6Do@steffen%sdaoden.eu>:
|Wietse Venema via Postfix-users wrote in
| <4tqc213rcwzj...@spike.porcupine.org>:
||So you're suggesting that as long as an MTA-to Milter connection
||is not in an error state, sending
||
||SMFIC_QUIT_NC
||
||and
Wietse Venema via Postfix-users wrote in
<4tqc213rcwzj...@spike.porcupine.org>:
|So you're suggesting that as long as an MTA-to Milter connection
|is not in an error state, sending
|
|SMFIC_QUIT_NC
|
|and later sending
|
|SMTIC_CONNECT
|
|are sufficient to make a Milter fully f
So you're suggesting that as long as an MTA-to Milter connection
is not in an error state, sending
SMFIC_QUIT_NC
and later sending
SMTIC_CONNECT
are sufficient to make a Milter fully forget a past SMTP session and
to make it ready to handle events from a new SMTP session?
I'd like to
Wietse Venema via Postfix-users wrote in
<4tq7t76ypkzj...@spike.porcupine.org>:
|Claus Assmann via Postfix-users:
|>> SMFIP_NOQUIT would
|>> be a good protocol extension in general
|>
|> "Use the source, Luke."
|>
|> You mean something like
|> SMFIC_QUIT_NC
|> ?
|
|And... Postfix 'kn
On Wed, Jan 31, 2024 at 12:13:51PM -0500, Wietse Venema via Postfix-users wrote:
> - The MTA then needs to keep the Milter connection open while watting
> for new work. Once there is work, the MTA sends SMFIC_CONNECT and
> so on.
>
> - This sounds like the MTA needs a Milter connection cache that
Claus Assmann via Postfix-users:
> > SMFIP_NOQUIT would
> > be a good protocol extension in general
>
> "Use the source, Luke."
>
> You mean something like
> SMFIC_QUIT_NC
> ?
And... Postfix 'knows' that constant since postfix-2.5.0, but there
is no code to negotiate or send it.
What would it
> SMFIP_NOQUIT would
> be a good protocol extension in general
"Use the source, Luke."
You mean something like
SMFIC_QUIT_NC
?
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
Wietse Venema via Postfix-users wrote in
<4tpmnz1dqyzj...@spike.porcupine.org>:
|Postfix has to be compatible with libmilter, the reference
|implementation from Sendmail. It absolutely makes no sends for me
|to unilaterally add features. If you wish to propose libmilter API
|changes, such as c
Postfix has to be compatible with libmilter, the reference
implementation from Sendmail. It absolutely makes no sends for me
to unilaterally add features. If you wish to propose libmilter API
changes, such as claimng a code, then this mailing list is not the
place to do that.
Claus Assmann is on t
Matus UHLAR - fantomas via Postfix-users:
> >> > Bill Cole via Postfix-users escribi? el 11/12/2023 a las 15:31:
> >> >> On 2023-12-10 at 16:37:16 UTC-0500 (Sun, 10 Dec 2023 22:37:16 +0100)
> >> >> Carlos Velasco via Postfix-users
> >> >> is rumored to have said:
> >> >> [...]
> >> >>> And doing t
> Bill Cole via Postfix-users escribi? el 11/12/2023 a las 15:31:
>> On 2023-12-10 at 16:37:16 UTC-0500 (Sun, 10 Dec 2023 22:37:16 +0100)
>> Carlos Velasco via Postfix-users
>> is rumored to have said:
>> [...]
>>> And doing the same work in 2 different places can be called software
>>> efficienc
On 2023-12-10 at 16:37:16 UTC-0500 (Sun, 10 Dec 2023 22:37:16 +0100)
Carlos Velasco via Postfix-users
is rumored to have said:
And doing the same work in 2 different places can be called software
efficiency?
Bill Cole via Postfix-users escribió el 11/12/2023 a las 15:31:
since it was created
Bill Cole via Postfix-users:
> On 2023-12-11 at 09:37:39 UTC-0500 (Mon, 11 Dec 2023 15:37:39 +0100)
> Carlos Velasco via Postfix-users
> is rumored to have said:
>
> > Bill Cole via Postfix-users escribi? el 11/12/2023 a las 15:31:
> >> On 2023-12-10 at 16:37:16 UTC-0500 (Sun, 10 Dec 2023 22:37:1
On 2023-12-11 at 09:37:39 UTC-0500 (Mon, 11 Dec 2023 15:37:39 +0100)
Carlos Velasco via Postfix-users
is rumored to have said:
Bill Cole via Postfix-users escribió el 11/12/2023 a las 15:31:
On 2023-12-10 at 16:37:16 UTC-0500 (Sun, 10 Dec 2023 22:37:16 +0100)
Carlos Velasco via Postfix-users
Bill Cole via Postfix-users escribió el 11/12/2023 a las 15:31:
On 2023-12-10 at 16:37:16 UTC-0500 (Sun, 10 Dec 2023 22:37:16 +0100)
Carlos Velasco via Postfix-users
is rumored to have said:
[...]
And doing the same work in 2 different places can be called software
efficiency?
No, but the "fi
On 2023-12-10 at 16:37:16 UTC-0500 (Sun, 10 Dec 2023 22:37:16 +0100)
Carlos Velasco via Postfix-users
is rumored to have said:
[...]
And doing the same work in 2 different places can be called software
efficiency?
No, but the "fix" here would be a divergence from how Milter has worked
since i
On 2023-12-10 at 16:16:27 UTC-0500 (Sun, 10 Dec 2023 22:16:27 +0100)
Carlos Velasco via Postfix-users
is rumored to have said:
Wietse Venema via Postfix-users escribió el 10/12/2023 a las 21:53:
2. the "own Received" header not being passed to milter. I
understand
it works as expected, but co
Wietse:
> I asked for a copy of the (headers of the) resulting message that
> Postfix delivers.
> - Does it have a Received-SPF header?
> - Does it have two?
Carlos Velasco:
> 1. Deleting the header in the milter or doing nothing in the milter
> has the same result: final email has only 1 Received
Wietse Venema via Postfix-users escribió el 10/12/2023 a las 22:54:
Carlos Velasco via Postfix-users:
Wietse Venema via Postfix-users escribi? el 10/12/2023 a las 21:53:
Carlos Velasco via Postfix-users:
Wietse Venema via Postfix-users escribi? el 10/12/2023 a las 19:44:
Carlos Velasco via P
Carlos Velasco via Postfix-users:
>
> Wietse Venema via Postfix-users escribi? el 10/12/2023 a las 21:53:
> > Carlos Velasco via Postfix-users:
> >> Wietse Venema via Postfix-users escribi? el 10/12/2023 a las 19:44:
> >>> Carlos Velasco via Postfix-users:
> *** And there is the milter, is cu
Jaroslaw Rafa via Postfix-users escribió el 10/12/2023 a las 22:32:
Dnia 10.12.2023 o godz. 22:16:27 Carlos Velasco via Postfix-users pisze:
That is because every Milter in the real world gets the client info
>from the smfi_connect() callback function and from Milter macros,
instead of parsing
Dnia 10.12.2023 o godz. 22:16:27 Carlos Velasco via Postfix-users pisze:
>
> >That is because every Milter in the real world gets the client info
> >from the smfi_connect() callback function and from Milter macros,
> >instead of parsing Received: headers.
> That statement is absolutely false.
> Ma
Wietse Venema via Postfix-users escribió el 10/12/2023 a las 21:53:
Carlos Velasco via Postfix-users:
Wietse Venema via Postfix-users escribi? el 10/12/2023 a las 19:44:
Carlos Velasco via Postfix-users:
*** And there is the milter, is custom made ***
You need to reduce complexity.
- If you
Carlos Velasco via Postfix-users:
> Wietse Venema via Postfix-users escribi? el 10/12/2023 a las 19:44:
> > Carlos Velasco via Postfix-users:
> >> *** And there is the milter, is custom made ***
> > You need to reduce complexity.
> >
> > - If you remove the Milter, is the header still duplicated?
>
Wietse Venema via Postfix-users escribió el 10/12/2023 a las 19:44:
Carlos Velasco via Postfix-users:
*** And there is the milter, is custom made ***
You need to reduce complexity.
- If you remove the Milter, is the header still duplicated?
No.
Duplication only happens when, in milter, I dele
Carlos Velasco via Postfix-users:
> *** And there is the milter, is custom made ***
You need to reduce complexity.
- If you remove the Milter, is the header still duplicated?
- If you keep the milter and rmeove the polocy lookup, is eom other
header duplicated?
Wietse
__
Wietse Venema via Postfix-users escribió el 10/12/2023 a las 18:49:
Carlos Velasco via Postfix-users:
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
Carlos Velasco via Postfix-users:
> > 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
Scott Kitterman via Postfix-users escribió el 10/12/2023 a las 18:09:
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
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 pypoli
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.
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
Hi,
Things have gotten stranger for case 1.
If milter "chgheader" is used, the Index 1 is the hidden (prepended) header of
postfix. So, you must start in index = 2 to delete the first header received in header
callback.
Regards,
Carlos Velasco
Carlos Velasco via Postfix-users escribió el 10/1
thank you for the explanation, I'll adjust my code accordingly :)
On Tue, 17 Oct 2023 10:02:33 -0400 (EDT) Wietse Venema via Postfix-users
wrote:
> mailmary--- via Postfix-users:
> >
> > Hello everyone,
> >
> > I'm coding a milter and I noticed an issue with postfix. Once postfix is
> >
mailmary--- via Postfix-users:
>
> Hello everyone,
>
> I'm coding a milter and I noticed an issue with postfix. Once postfix is done
> communicating with the milters, instead of sending a SMFIC_QUIT, it sends
> SMFIC_ABORT.
>
> abort all milters
> milter8_abort: abort milter inet:127.0.0.1:889
On 2023-09-24 06:16, Wietse Venema via Postfix-users wrote:
Stanislav via Postfix-users:
Greetings,
After upgrading from postfix 3.7.3 to postfix 3.8.2, I've noticed my
email is not signed with DKIM anymore. After further investigation,
I've
found that Postfix ignores milter on outgoing email
Stanislav via Postfix-users:
> Greetings,
>
> After upgrading from postfix 3.7.3 to postfix 3.8.2, I've noticed my
> email is not signed with DKIM anymore. After further investigation, I've
> found that Postfix ignores milter on outgoing emails (incoming goes
> through milter ok).
This has not
On 24.09.23 04:39, Stanislav via Postfix-users wrote:
After upgrading from postfix 3.7.3 to postfix 3.8.2, I've noticed my
email is not signed with DKIM anymore. After further investigation,
I've found that Postfix ignores milter on outgoing emails (incoming
goes through milter ok).
do you me
Gary Aitken via Postfix-users:
> New install of postfix on a freebsd 12.4 system.
> I have milter-greylist installed, set up in main.cf as:
>
>milter_protocol = 6
>milter_default_action = accept
>smtpd_milters = local:/var/milter-greylist/milter-greylist.sock
>
> The socket to milter-
Scott Kitterman wrote in
<4d53bd64-1672-49c5-adca-487f320f8...@kitterman.com>:
..
|>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 .
Maybe a
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
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 rec
On Sat, Mar 11, 2023 at 01:54:01AM +0100, Steffen Nurpmeso via Postfix-users
wrote:
> - sign the entire message as for now,
You're confusing the message and the envelope.
> - but include a "cramped=1" tag that signals that all receivers
> are actually covered by the DKIM signature, so
The en
Gerald Galster wrote in
:
In my postgray thing i have "allow .dhl.de" (surely for a reason).
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
__
> 2023-03-10 11:54:43 #31829(rspamd_proxy) <71bd42>; proxy;
> rspamd_task_write_log: id: , qid: <3129536A7A2>, ip: 165.72.200.209,
> from: , (default: F (soft reject): [5.31/15.00]
> [BAYES_HAM(-2.99){99.97%;},DCC_BULK(2.00){bulk Body=1 Fuz1=4
> Fuz2=many;},MIME_HEADER_CTYPE_ONLY(2.00){},MISSIN
On 2023-03-10 at 05:59:00 UTC-0500 (Fri, 10 Mar 2023 11:59:00 +0100)
Adrian Huryn via Postfix-users
is rumored to have said:
Thanks for reply.
Logs from rspamd
[...]
2023-03-10 11:54:43 #31829(rspamd_proxy) <71bd42>; lua;
greylist.lua:348: greylisted until "Fri, 10 Mar 2023 10:59:43 GMT",
ne
92 matches
Mail list logo
