[pfx] Re: PATCH: using Milter to change a PREPENDed header
On 13. 12. 23 22:54, Wietse Venema via Postfix-users wrote: Jiri Bourek via Postfix-users: My response was quoting the message that mentions the patch changing behaviour of PREPEND - message from 10 Dec 2023 19:04:55 -0500 (EST). I now spotted the "With this, no change is needed to the Postfix SMTP daemon" sentence in message from 12 Dec 2023 19:59:46 -0500 (EST) May I assume that the previous patch is therefore superseded by the later one and header order is not changing for headers added by policy service? Indeed. The final fix does not change the message layout. It fixes some 18-year old code that updated or deleted a header with the right name but in the wrong location. Alright, thanks for the reply. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Exposing the Postfix-generated Received: header to Milters
Wietse Venema via Postfix-users wrote in <4srcnm0d3jzj...@spike.porcupine.org>: |Steffen Nurpmeso via Postfix-users: |> Wietse Venema via Postfix-users wrote in |> <4sr8hc44p7zj...@spike.porcupine.org>: |>|Currently, Postfix does not send the Postfix-generated Received: |>|header to Milters, because that is how Sendmail works, that is what |> ... |>|This information would improve the Milter's analysis. Untrusted |> ... |>|The path forward is for MTAs and Milters to negotiate. Manual-only |> ... |>|What would be a good contact to add a new flag to ? |>|I was thinking of something like this: ... |> The only occurrancence of libmilter i have ever encountered is in |> the sendmail source as shipped with FreeBSD. Some FreeBSD members |> are pretty much related with sendmail, also historically. 'Seems |> to me, and *if* i were *you*, i would try contacting gshapiro at |> FreeBSD.org, it be worth a try for this. | |Claus Assmann has been a long-time postfix-users member and has also |worked for Sendmail. Wonderful opportunity for him to speak up. (I really do not know, "it" is only from what flies by via the FreeBSD commits that i track. But it seems to me he is still working there, now that i look.) --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) | | Only in December: lightful Dubai COP28 Narendra Modi quote: | A small part of humanity has ruthlessly exploited nature. | But the entire humanity is bearing the cost of it, | especially the inhabitants of the Global South. | The selfishness of a few will lead the world into darkness, | not just for themselves but for the entire world. | [Christians might think of Revelation 11:18 |The nations were angry, and your wrath has come[.] |[.]for destroying those who destroy the earth. | But i find the above more kind, and much friendlier] ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Exposing the Postfix-generated Received: header to Milters
Steffen Nurpmeso via Postfix-users: > Wietse Venema via Postfix-users wrote in > <4sr8hc44p7zj...@spike.porcupine.org>: > |Currently, Postfix does not send the Postfix-generated Received: > |header to Milters, because that is how Sendmail works, that is what > ... > |This information would improve the Milter's analysis. Untrusted > ... > |The path forward is for MTAs and Milters to negotiate. Manual-only > ... > |What would be a good contact to add a new flag to ? > |I was thinking of something like this: > | > | #define SMFIP_HDR_LEADSPC 0x0010L /* header value leading space */ > |+#define SMFIP_HDR_RECEIVED 0x0020L/* Send MTA's Received: \ > |header */ > | #define SMFIP_MDS_256K 0x1000L /* MILTER_MAX_DATA_SIZE=256K */ > | > |Flag 0x0020L appears to be unused. > > The only occurrancence of libmilter i have ever encountered is in > the sendmail source as shipped with FreeBSD. Some FreeBSD members > are pretty much related with sendmail, also historically. 'Seems > to me, and *if* i were *you*, i would try contacting gshapiro at > FreeBSD.org, it be worth a try for this. Claus Assmann has been a long-time postfix-users member and has also worked for Sendmail. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Exposing the Postfix-generated Received: header to Milters
Wietse Venema via Postfix-users wrote in <4sr8hc44p7zj...@spike.porcupine.org>: |Currently, Postfix does not send the Postfix-generated Received: |header to Milters, because that is how Sendmail works, that is what ... |This information would improve the Milter's analysis. Untrusted ... |The path forward is for MTAs and Milters to negotiate. Manual-only ... |What would be a good contact to add a new flag to ? |I was thinking of something like this: | | #define SMFIP_HDR_LEADSPC 0x0010L /* header value leading space */ |+#define SMFIP_HDR_RECEIVED 0x0020L/* Send MTA's Received: \ |header */ | #define SMFIP_MDS_256K 0x1000L /* MILTER_MAX_DATA_SIZE=256K */ | |Flag 0x0020L appears to be unused. The only occurrancence of libmilter i have ever encountered is in the sendmail source as shipped with FreeBSD. Some FreeBSD members are pretty much related with sendmail, also historically. 'Seems to me, and *if* i were *you*, i would try contacting gshapiro at FreeBSD.org, it be worth a try for this. --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) | | Only in December: lightful Dubai COP28 Narendra Modi quote: | A small part of humanity has ruthlessly exploited nature. | But the entire humanity is bearing the cost of it, | especially the inhabitants of the Global South. | The selfishness of a few will lead the world into darkness, | not just for themselves but for the entire world. | [Christians might think of Revelation 11:18 |The nations were angry, and your wrath has come[.] |[.]for destroying those who destroy the earth. | But i find the above more kind, and much friendlier] ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: PATCH: using Milter to change a PREPENDed header
Jiri Bourek via Postfix-users: > My response was quoting the message that mentions the patch changing > behaviour of PREPEND - message from 10 Dec 2023 19:04:55 -0500 (EST). I > now spotted the "With this, no change is needed to the Postfix SMTP > daemon" sentence in message from 12 Dec 2023 19:59:46 -0500 (EST) > > May I assume that the previous patch is therefore superseded by the > later one and header order is not changing for headers added by policy > service? Indeed. The final fix does not change the message layout. It fixes some 18-year old code that updated or deleted a header with the right name but in the wrong location. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Exposing the Postfix-generated Received: header to Milters
Currently, Postfix does not send the Postfix-generated Received: header to Milters, because that is how Sendmail works, that is what Milters expect, and changing the behavior unilaterally would break compatibility with a large installed base. This information would improve the Milter's analysis. Untrusted headers from an SMTP client will appear after the Postfix-generated Received: header, and trusted headers that were added locally can be prepended before. Without that header, the Milter would have to guess. And guessing is not good. The path forward is for MTAs and Milters to negotiate. Manual-only configuration (with configuration flags for MTAs and Milters that need to be in sync) would be too bothersome. How the Milter protocol is negotiated: (1) An MTA connects to a Milter over a TCP socket or UNIX-domain socket. (2) The Milter accpts the connection. (3) The MTA sends a list of actions that a Milter may request. For example, SMFIF_ADDHDRS = Milter can request to add headers, and SMFIF_CHGBODY = Milter can request to replace a messaage body. The MTA also sends a list of protocol features that the Milter can turn on or off. For example, SMFIP_NOHDRS = MTA should not send SMFIC_HEADER events, SMFIP_NR_HDR = Milter will not reply to SMFIC_HEADER events, and SMFIP_HDR_LEADSPC = MTA can prepend the space (between header name and header value) to the header value when it sends an SMFIC_HEADER event to a Milter. Without this information, the Milter has to guess how much and what kind of whitespace was in the message header. (4) The Milter replies with the subsets of the actions and protocol features that it supports. To make "expose MTA-generated Received: header" negotiable, the MTA has to announce in (3) that it can make the header available, for example with a protocol feature SMFIP_HDR_RECEIVED. If the Milter supports this, then it can reply in (4) that it does. Only if both MTA and the Milter both agree to use SMFIP_HDR_RECEIVED, then the MTA can send the MTA-generated Received: header. What would be a good contact to add a new flag to ? I was thinking of something like this: #define SMFIP_HDR_LEADSPC 0x0010L /* header value leading space */ +#define SMFIP_HDR_RECEIVED 0x0020L /* Send MTA's Received: header */ #define SMFIP_MDS_256K 0x1000L /* MILTER_MAX_DATA_SIZE=256K */ Flag 0x0020L appears to be unused. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: PATCH: using Milter to change a PREPENDed header
On 13. 12. 23 19:41, Wietse Venema via Postfix-users wrote: Jiri Bourek via Postfix-users: Example for current behaviour: Received-SPF: Pass *<-- only we could've add this* Received: from some.server by this.server With the new one: Received: from some.server by this.server Received-SPF: Pass *<-- did scammer add it or did we?* Once again, the behavior of header ADD or INSERT requests has NOT changed. The bug was with some header UPDATE or DELETE requests hitting the wrong header, or not finding the one that was intended. Wietse My response was quoting the message that mentions the patch changing behaviour of PREPEND - message from 10 Dec 2023 19:04:55 -0500 (EST). I now spotted the "With this, no change is needed to the Postfix SMTP daemon" sentence in message from 12 Dec 2023 19:59:46 -0500 (EST) May I assume that the previous patch is therefore superseded by the later one and header order is not changing for headers added by policy service? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: PATCH: using Milter to change a PREPENDed header
On 2023-12-13 at 13:06:36 UTC-0500 (Wed, 13 Dec 2023 19:06:36 +0100) Jiri Bourek via Postfix-users is rumored to have said: > On 11. 12. 23 1:04, Wietse Venema via Postfix-users wrote: >> >> Confirmed. A premiminary fix is below. This will prepend the >> Received-SPF from the policy service after the Postfix-generated >> Received: header and before the received message. >> >> With this fix, a Milter can replace a PREMENDed Received-SPF: header >> as one would expect. >> >> This change is a bit invasive as it changes the message layout, >> which is not needed if a configuration does not use Milters. >> > > Will this not cause breakages in other programs though? With the current > behaviour, you can easily determine that a header was added by some local > (own) program and consider it trustworthy. Any header below own Received: is > controlled by the sender and can contain fake information. > > SpamAssasin comes to mind as an example. I would need to re-check but I think > it only considers Received-SPF to be trustworthy, if it's above own Received > header (trusted/internal network relays come into play here but let's stick > with the simple case) [dons SA contributor hat...] Generally speaking, correct. Technically it needs to be above/before the last trusted Received header. It should be possible to construct rules to identify one's own authentication headers and score appropriately, if you feel that necessary. In my opinion that's not worthwhile because SA will do its own SPF check and if something else has just done the needed DNS queries, they'll still be in cache. Very fast. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: PATCH: using Milter to change a PREPENDed header
Jiri Bourek via Postfix-users: > Example for current behaviour: > > Received-SPF: Pass *<-- only we could've add this* > Received: from some.server by this.server > > With the new one: > > Received: from some.server by this.server > Received-SPF: Pass *<-- did scammer add it or did we?* Once again, the behavior of header ADD or INSERT requests has NOT changed. The bug was with some header UPDATE or DELETE requests hitting the wrong header, or not finding the one that was intended. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: PATCH: using Milter to change a PREPENDed header
On 11. 12. 23 1:04, Wietse Venema via Postfix-users wrote: Confirmed. A premiminary fix is below. This will prepend the Received-SPF from the policy service after the Postfix-generated Received: header and before the received message. With this fix, a Milter can replace a PREMENDed Received-SPF: header as one would expect. This change is a bit invasive as it changes the message layout, which is not needed if a configuration does not use Milters. Will this not cause breakages in other programs though? With the current behaviour, you can easily determine that a header was added by some local (own) program and consider it trustworthy. Any header below own Received: is controlled by the sender and can contain fake information. SpamAssasin comes to mind as an example. I would need to re-check but I think it only considers Received-SPF to be trustworthy, if it's above own Received header (trusted/internal network relays come into play here but let's stick with the simple case) Example for current behaviour: Received-SPF: Pass *<-- only we could've add this* Received: from some.server by this.server With the new one: Received: from some.server by this.server Received-SPF: Pass *<-- did scammer add it or did we?* ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: printer ip SMTP AUTH / mynetworks question
lists--- via Postfix-users:
> I have a user with an 'old' printer/scanner who wants to scan/email scans
> from the home located device
>
> printer offers:
> machine email address:
> SMTP server:
> SMTP server port:
>
> send authentication: PoPb4SMTP/SMTP AUTH: Plain/Login/CRAM-MD5/Auto
If the printer is connecting over the Internet in plaintext, then
one option is don't bother with TLS and SASL auth. Instead configure
an smtpd in master.cf on a TCP port for use by that customer.
/etc/postfix/master.cf:
12345 inet n - n - - smtpd
-o {mynetworks = 1.2.3.4}
-o {smtpd_recipient_restrictions = permit_mynetworks, reject}
Either way, having AUTH on port 25 is wasteful (many dictionary
attack bots).
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: printer ip SMTP AUTH / mynetworks question
Dnia 13.12.2023 o godz. 09:15:52 Bill Cole via Postfix-users pisze: > > No AUTH offered. Which is fine, because one should not offer AUTH > over an unencrypted session. However, your printer saw that and > instead of using STARTTLS, it hung up. That's bad. It should have > used STARTTLS to get a useful session. I'd bet the printer does not support TLS. > TLS. If you cannot use TLS, you should either get a modern printer > or don't ask your printer to email you. You certainly COULD work > around that by compromising the security of your MTA, but why? The user in question probably doesn't use the printer without having a computer turned on? :) Then the possible solution is to install stunnel on the user's computer, point the printer to the local IP of user's computer (other parameters unchanged), and make stunnel forward the connection (encrypted) to port 465 (not 587, as 465 is TLS-wrapped submission and 587 is STARTTLS) on your mail server. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: printer ip SMTP AUTH / mynetworks question
On 2023-12-13 at 04:27:24 UTC-0500 (Wed, 13 Dec 2023 20:27:24 +1100)
lists--- via Postfix-users
is rumored to have said:
I have a user with an 'old' printer/scanner who wants to scan/email
scans
from the home located device
printer offers:
machine email address:
SMTP server:
SMTP server port:
send authentication: PoPb4SMTP/SMTP AUTH: Plain/Login/CRAM-MD5/Auto
login name:
passwd:
I would also expect a session encryption option for using TLS on the
connection, which may be labeled as SSL because it is old.
If your printer has no such option, I'd junk it.
tried 587 with each of the 4 AUTH options, keeps failing
added printer IP to mynetworks, changed to port 25, working
any suggestion what it might need to use port 587 / AUTH ?
Correct daemon configuration. That is site-specific and you've not
included your configuration, so any suggestion would be a pure guess.
postconf -nf
postconf -Mf
Thew fix is probably in master.cf, where you should have something
*similar* to this for port 587:
submission inet n - n - - smtpd
-o syslog_name=postfix/submit
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
any undesired side effects of allowing printer IP in main.cf
mynetworks ?
*Assuming* that you have 'permit_my_networks' in your
smtpd.*restrictions lists, anything on your network that could grab that
IP could spam at will through your MTA.
Dec 13 17:52:13 geko postfix/submission/smtpd[22180]: connect from
111-222-333-444.tpgi.com.au[111.222.333.444]
Dec 13 17:52:13 geko postfix/submission/smtpd[22180]: lost connection
after EHLO from 111-222-333-444.tpgi.com.au[111.222.333.444]
Dec 13 17:52:13 geko postfix/submission/smtpd[22180]: disconnect from
111-222-333-444.tpgi.com.au[111.222.333.444] ehlo=1 commands=1
Dec 13 17:47:20 geko postfix/submission/smtpd[15098]: disconnect from
111-222-333-444.tpgi.com.au[111.222.333.444] ehlo=1 commands=1
Those both indicate that the device at the impossible IP connected,
provided an acceptable EHLO command, and unceremoniously dropped the
connection.
Dec 13 17:48:12 geko postfix/anvil[15001]: statistics: max connection
rate
6/3600s for (submission:111.222.333.444) at Dec 13 17:47:20
Irrelevant
Dec 13 17:48:26 geko postfix/postscreen[14984]: CONNECT from
[111.222.333.444]:50694 to [103.106.168.106]:25
Dec 13 17:48:26 geko postfix/postscreen[14984]: WHITELISTED
[111.222.333.444]:50694
Dec 13 17:48:26 geko postfix/smtpd[15061]: connect from
111-222-333-444.tpgi.com.au[111.222.333.444]
Dec 13 17:48:26 geko postfix/smtpd[15061]: CB67D20BBA9:
client=111-222-333-444.tpgi.com.au[111.222.333.444],
sasl_method=LOGIN,
sasl_username=u...@tld.com.au
Dec 13 17:48:30 geko amavis[15129]: (15129-15) Checking: P4rpqg2X2xgz
[111.222.333.444] ->
Dec 13 17:48:31 geko postfix/smtpd[15061]: disconnect from
111-222-333-444.tpgi.com.au[111.222.333.444] ehlo=1 auth=1 mail=1
rcpt=1
data=1 quit=1 commands=6
You seem to have the classical Amavis config, using it as a SMTP proxy.
And it seems to basically work.
Dec 13 17:48:31 geko amavis[15129]: (15129-15) Passed CLEAN
{RelayedInbound}, [111.222.333.444]:50694 [111.222.333.444]
ESMTP/ESMTP
-> ,
(ESMTPA://[111.222.333.444]:50694), Queue-ID: CB67D20BBA9, mail_id:
P4rpqg2X2xgz, b: cNaGQKTr-, Hits: 0.436, size: 525554, queued_as:
C064E20A5CB, Subject: "ScanFrom Printer (raw:
=?utf-8?B?U2NhbkZy2NhbkZyb20gW50ZXI=?=)", From:
,
helo=iptarget, Tests:
[ALL_TRUSTED=-1,BAYES_00=-1.9,DATE_IN_PAST_06_12=1.543,DKIM_INVALID=0.1,DKIM_SIGNED=0.1,INVALID_DATE=1.096,MISSING_MID=0.497],
autolearn=no autolearn_force=no, autolearnscore=1.875, 1715 ms
And there is Amavis (using SpamAssassin) giving it the thumbs up.
The command summary above from smtpd as it closed the session indicates
that you have a working authentication system set up to work on port 25
(where it isn't useful) but for some reason the printer never bothers
trying. It receives something in the EHLO response that tells it that it
cannot send...
I made a guess based on your mail's transit path and found the issue, I
THINK. This is a manual SMTP check of what geko is saying on those 2
ports:
shiny:~ root# telnet geko.sbt.net.au 587
Trying 103.106.168.106...
Connected to geko.sbt.net.au.
Escape character is '^]'.
220 geko.sbt.net.au ESMTP Postfix
EHLO dynnat.scconsult.com
250-geko.sbt.net.au
250-PIPELINING
250-SIZE 30971520
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
quit
221 2.0.0 Bye
Connection closed by foreign host.
No AUTH offered. Which is fine, because one should not offer AUTH over
an unencrypted session. However, your printer saw that and instead of
using
[pfx] printer ip SMTP AUTH / mynetworks question
I have a user with an 'old' printer/scanner who wants to scan/email scans
from the home located device
printer offers:
machine email address:
SMTP server:
SMTP server port:
send authentication: PoPb4SMTP/SMTP AUTH: Plain/Login/CRAM-MD5/Auto
login name:
passwd:
tried 587 with each of the 4 AUTH options, keeps failing
added printer IP to mynetworks, changed to port 25, working
any suggestion what it might need to use port 587 / AUTH ?
any undesired side effects of allowing printer IP in main.cf mynetworks ?
Dec 13 17:52:13 geko postfix/submission/smtpd[22180]: connect from
111-222-333-444.tpgi.com.au[111.222.333.444]
Dec 13 17:52:13 geko postfix/submission/smtpd[22180]: lost connection
after EHLO from 111-222-333-444.tpgi.com.au[111.222.333.444]
Dec 13 17:52:13 geko postfix/submission/smtpd[22180]: disconnect from
111-222-333-444.tpgi.com.au[111.222.333.444] ehlo=1 commands=1
Dec 13 17:47:20 geko postfix/submission/smtpd[15098]: disconnect from
111-222-333-444.tpgi.com.au[111.222.333.444] ehlo=1 commands=1
Dec 13 17:48:12 geko postfix/anvil[15001]: statistics: max connection rate
6/3600s for (submission:111.222.333.444) at Dec 13 17:47:20
Dec 13 17:48:26 geko postfix/postscreen[14984]: CONNECT from
[111.222.333.444]:50694 to [103.106.168.106]:25
Dec 13 17:48:26 geko postfix/postscreen[14984]: WHITELISTED
[111.222.333.444]:50694
Dec 13 17:48:26 geko postfix/smtpd[15061]: connect from
111-222-333-444.tpgi.com.au[111.222.333.444]
Dec 13 17:48:26 geko postfix/smtpd[15061]: CB67D20BBA9:
client=111-222-333-444.tpgi.com.au[111.222.333.444], sasl_method=LOGIN,
sasl_username=u...@tld.com.au
Dec 13 17:48:30 geko amavis[15129]: (15129-15) Checking: P4rpqg2X2xgz
[111.222.333.444] ->
Dec 13 17:48:31 geko postfix/smtpd[15061]: disconnect from
111-222-333-444.tpgi.com.au[111.222.333.444] ehlo=1 auth=1 mail=1 rcpt=1
data=1 quit=1 commands=6
Dec 13 17:48:31 geko amavis[15129]: (15129-15) Passed CLEAN
{RelayedInbound}, [111.222.333.444]:50694 [111.222.333.444] ESMTP/ESMTP
-> ,
(ESMTPA://[111.222.333.444]:50694), Queue-ID: CB67D20BBA9, mail_id:
P4rpqg2X2xgz, b: cNaGQKTr-, Hits: 0.436, size: 525554, queued_as:
C064E20A5CB, Subject: "ScanFrom Printer (raw:
=?utf-8?B?U2NhbkZy2NhbkZyb20gW50ZXI=?=)", From: ,
helo=iptarget, Tests:
[ALL_TRUSTED=-1,BAYES_00=-1.9,DATE_IN_PAST_06_12=1.543,DKIM_INVALID=0.1,DKIM_SIGNED=0.1,INVALID_DATE=1.096,MISSING_MID=0.497],
autolearn=no autolearn_force=no, autolearnscore=1.875, 1715 ms
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix Milter, the gift that keeps on giving (was: PATCH: using Milter to change a PREPENDed header)
Wietse Venema via Postfix-users escribió el 13/12/2023 a las 1:59: Carlos Velasco via Postfix-users: Thus, the Postfix code that handles header update/delete requests was still naively skipping the first header, making calls to delete the prepended Received-SPF: header ineffective, and mis-directing calls to delete the first Milter-visible Received: header, instead deleting the invisible Postfix-generated Received: header (wtf). To maintain protocol compatibility, the Postfix code that handles header update/delete requests will need to skip the Postfix-generated Received: header, instead of the first message header. Once that mess is handled with, we can consider adding a flag to expose Postfix-generated Received: headers to Milters. I think you are absolutely correct in your analysis. I've been looking over the code and, although there is a lot I still don't understand, your yesterday patch seems more a (good) workaround to the real problem. Below is a fix that does not break any of the already existng tests :-) and that passes some new tests that I added for this specific case. There is no difference when adding or inserting a header, only when updating or deleting. With this, no change is needed to the Postfix SMTP daemon. It is safe to prepend headers with a Postfix access table or with header/body_checks. They can be deleted or updated as expected. The patch does not include changes to Postfix tests. It works perfectly. Tested in 3.8.3. Milter sees: Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2620:137:e000::1:20; helo=out1.vger.email; envelope-from=linux-kernel-ow...@vger.kernel.org; receiver= *<-- Prepend* Received: (majord...@vger.kernel.org) by vger.kernel.org via listexpand *<-- First Received. Not own/auto header* id S232053AbjLMJED (ORCPT ); Wed, 13 Dec 2023 04:04:03 -0500 ... Final email: Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) * <-- Own/auto header* by server.domain.com (ESMTP Server) with ESMTP id 58781C00A2 for ; Wed, 13 Dec 2023 10:04:28 +0100 (CET) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2620:137:e000::1:20; helo=out1.vger.email; envelope-from=linux-kernel-ow...@vger.kernel.org; receiver= *<-- Prepend* Received: (majord...@vger.kernel.org) by vger.kernel.org via listexpand *<-- First Received. Not own/auto header* id S232053AbjLMJED (ORCPT ); Wed, 13 Dec 2023 04:04:03 -0500 ... Regards, Carlos Velasco ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
