[pfx] How to restrict relay domains for sendmail command ?

[Cowbay via Postfix-users]

Hi,

I installed a Postfix mail server in a Linux LXC container.

I want this mail server to relay mails for specific domains only and all 
the mails are relayed to another mail server ($relayhost configured in 
main.cf).


I found that there is no $sendmail_relay_restrictions configuration like 
what $smtpd_relay_restrictions does, so the $relay_domains is useless 
for sendmail.


And there is no filter available for sendmail either 
(https://www.postfix.org/FILTER_README.html).


How to reject the unwanted destination domains when users use the 
sendmail command ?

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

[pfx] Re: How to restrict relay domains for sendmail command ?

[Cowbay via Postfix-users]

On 2023/12/5 21:13, Jaroslaw Rafa via Postfix-users wrote:

Dnia  5.12.2023 o godz. 20:14:45 Cowbay via Postfix-users pisze:


I want this mail server to relay mails for specific domains only and
all the mails are relayed to another mail server ($relayhost
configured in main.cf).

I found that there is no $sendmail_relay_restrictions configuration
like what $smtpd_relay_restrictions does, so the $relay_domains is
useless for sendmail.


Relaying, by definition, occurs only when mail is coming in via SMTP and is
not delivered locally, but re-sent to another server.

When mail is generated locally via sendmail and sent out, there is no
relaying. Your server is the originating server for the message.

It's the other server, configured as $relayhost, that is doing the relaying.
So if you want to configure any relay restrictions, you should do it on that
other server, not on the originating one.


Thank you very much to correct me.


How to reject the unwanted destination domains when users use the
sendmail command ?


Use non_smtpd_milters= with a proper milter. You can use for example
milter-regex ( https://www.benzedrine.ch/milter-regex.html ) and specify
proper "accept envrcpt" rules in the configuration for domains you want to
accept as recipients, and "reject" anything else by default.

I downloaded and built the milter-regex. It's cool and it satisfy my needs.

Thank you very much.

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

[pfx] Postfix thinks smtp.gmail.com uses self-signed certificate

[Cowbay via Postfix-users]

Hi,

I'm using debian 10, an old debian distribution. The Postfix version is 
3.4.23.


I found below in the log, it says "certificate verification failed for 
smtp.gmail.com[64.233.189.109]:465: self-signed certificate"

8<8<8<
Mar 20 21:27:38 SERVER postfix/qmgr[12913]: DC7D0140531: 
from=, size=122883, nrcpt=1 (queue active)
Mar 20 21:27:38 SERVER postfix/smtp[15534]: certificate verification 
failed for smtp.gmail.com[64.233.189.109]:465: self-signed certificate
Mar 20 21:27:38 SERVER postfix/smtp[15534]: Untrusted TLS connection 
established to smtp.gmail.com[64.233.189.109]:465: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 
server-signature RSA-PSS (2048 bits) server-digest SHA256
Mar 20 21:27:38 SERVER postfix/smtp[15534]: DC7D0140531: 
to=, relay=smtp.gmail.com[64.233.189.109]:465, 
delay=2789, delays=2789/0.08/0.06/0, dsn=4.7.5, status=deferred (Server 
certificate not trusted)

8<8<8<

The openssl and curl have no problem to verify the smtp.gmail.com:465. 
Below is openssl example:

8<8<8<
$ openssl s_client -4 -connect smtp.gmail.com:465 -CAfile 
/etc/ssl/certs/ca-certificates.crt

CONNECTED(0003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
verify return:1
depth=0 CN = smtp.gmail.com
verify return:1
---
Certificate chain
 0 s:CN = smtp.gmail.com
   i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
 1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
---
Server certificate
-BEGIN CERTIFICATE-
MIIEhzCCA2+gAwIBAgIQCrASK3egcWgQSjqRjoQ8iDANBgkqhkiG9w0BAQsFADBG
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzETMBEGA1UEAxMKR1RTIENBIDFDMzAeFw0yNDAyMTkwODE4MTVaFw0yNDA1MTMw
ODE4MTRaMBkxFzAVBgNVBAMTDnNtdHAuZ21haWwuY29tMFkwEwYHKoZIzj0CAQYI
KoZIzj0DAQcDQgAEzMkkeWMHpTkBU1wI2rgLq8jtzauypsQYFrc52brXD+yH50u3
0cVzi6ejSjhGni0d7fWxo+A4R91kOrCSsYDwYqOCAmcwggJjMA4GA1UdDwEB/wQE
AwIHgDATBgNVHSUEDDAKBggrBgEFBQcDATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQW
BBRaOURu5t91CGymCb0ym2q68LcxVzAfBgNVHSMEGDAWgBSKdH+vhc3ulc09nNDi
RhTzcTUdJzBqBggrBgEFBQcBAQReMFwwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3Nw
LnBraS5nb29nL2d0czFjMzAxBggrBgEFBQcwAoYlaHR0cDovL3BraS5nb29nL3Jl
cG8vY2VydHMvZ3RzMWMzLmRlcjAZBgNVHREEEjAQgg5zbXRwLmdtYWlsLmNvbTAh
BgNVHSAEGjAYMAgGBmeBDAECATAMBgorBgEEAdZ5AgUDMDwGA1UdHwQ1MDMwMaAv
oC2GK2h0dHA6Ly9jcmxzLnBraS5nb29nL2d0czFjMy9mVkp4YlYtS3Rtay5jcmww
ggEEBgorBgEEAdZ5AgQCBIH1BIHyAPAAdgDuzdBk1dsazsVct520zROiModGfLzs
3sNRSFlGcR+1mwAAAY3AqKz3AAAEAwBHMEUCIQDODj3d6tB3O52F9JGeHcoQHvHa
slsfd24LzJkh4vaT8QIgRYpJ5/KtmHRedvtIMpk5cphz7YQtNR9xCJqS/HZp+RkA
dgDatr9rP7W2Ip+bwrtca+hwkXFsu1GEhTS9pD0wSNf7qwAAAY3AqK5zAAAEAwBH
MEUCIGnYz1wq87LoxyEFmfNJMUpu3tbe+SoXEICpiSMb0QT2AiEA6RfPUZfe+KL4
d+1tNrMI7JcbS/7i1iluGfg7i7qvAzQwDQYJKoZIhvcNAQELBQADggEBAAedT7Wd
Wf65c+210Rukhm/D3Gpku3QsYzo0fnAgGP4pTaH1w9DZN9YUSOoxlsfxBdldDdjy
OBTOyf/anQCZGyTb6RTJcCDq39xRiDBxp/S5p/hOhSMqezjQkj4r+dNg3yBMQ9vM
YVXjxQMNkEnBuaqF6gmymJITZ96cEiY7csPUemQp2qvBpwwkTlk09r36tg2llyN8
H2sGfiI+aMP+zTcCl96kBWh4W+dT+C90bjbZQvhzzuUT+sInPtUqcsCQ8ZNUeaY1
cwZlzV1fHFnDfHaMZN+3PO2eVHlbxR97v7FO6wLZYCPmcqlB2sj1uxucMT4tXaE7
pV0EwxaTDEzCaUs=
-END CERTIFICATE-
subject=CN = smtp.gmail.com

issuer=C = US, O = Google Trust Services LLC, CN = GTS CA 1C3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4295 bytes and written 386 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol  : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID: 
BF3720957764F292088B747CAB9764DC744CF9D40FD60FBB743AFADE7B74D5F6

Session-ID-ctx:
Resumption PSK: 
52E8D459E26A5E1C0005DEAA70BFEAE44CDFA2E884A26709BD4FF34DF08639F74A4AE17B2C400C3EFBC0BD19164458B4

PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 172800 (seconds)
TLS session ticket:
 - 02 c4 7d 37 12 90 68 40-1e 21 95 25 51 12 e3 10 
..}7..h@.!.%Q...
0010 - 40 19 02 72 c3 8c 08 cd-bf dd d0 43 95 8f d0 d3 
@..r...C
0020 - 42 2f d3 20 a8 56 03 24-74 3e a6 90 bc ac 3c 34   B/. 
.V.$t><4
0030 - f2 54 d5 69 7a 30 88 cb-6d c0 e9 a6 95 56 05 1e 
.T.iz0..mV..
0040 - 94 57 e7 46 b8 36 8a fc-19 1e c3 a2 13 9b 52 b8 
.W.F.6R.
0050 - 1c b1 2a b1 5e a0 24 f1-64 5f 43 f2 d8 eb 00 6e 
..*.^.$.d_Cn
0060 - f1 93 e3 d3 05 ea 27 f

[pfx] Re: Postfix thinks smtp.gmail.com uses self-signed certificate

[Cowbay via Postfix-users]

On 2024/3/20 22:25, Cowbay via Postfix-users wrote:

Below is openssl example:
8<8<8<
$ openssl s_client -4 -connect smtp.gmail.com:465 -CAfile 
/etc/ssl/certs/ca-certificates.crt

CONNECTED(0003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
verify return:1
depth=0 CN = smtp.gmail.com
verify return:1
---
Certificate chain
  0 s:CN = smtp.gmail.com
    i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
  1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
    i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
  2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
    i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
---
Server certificate
-BEGIN CERTIFICATE-
MIIEhzCCA2+gAwIBAgIQCrASK3egcWgQSjqRjoQ8iDANBgkqhkiG9w0BAQsFADBG
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzETMBEGA1UEAxMKR1RTIENBIDFDMzAeFw0yNDAyMTkwODE4MTVaFw0yNDA1MTMw
ODE4MTRaMBkxFzAVBgNVBAMTDnNtdHAuZ21haWwuY29tMFkwEwYHKoZIzj0CAQYI
KoZIzj0DAQcDQgAEzMkkeWMHpTkBU1wI2rgLq8jtzauypsQYFrc52brXD+yH50u3
0cVzi6ejSjhGni0d7fWxo+A4R91kOrCSsYDwYqOCAmcwggJjMA4GA1UdDwEB/wQE
AwIHgDATBgNVHSUEDDAKBggrBgEFBQcDATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQW
BBRaOURu5t91CGymCb0ym2q68LcxVzAfBgNVHSMEGDAWgBSKdH+vhc3ulc09nNDi
RhTzcTUdJzBqBggrBgEFBQcBAQReMFwwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3Nw
LnBraS5nb29nL2d0czFjMzAxBggrBgEFBQcwAoYlaHR0cDovL3BraS5nb29nL3Jl
cG8vY2VydHMvZ3RzMWMzLmRlcjAZBgNVHREEEjAQgg5zbXRwLmdtYWlsLmNvbTAh
BgNVHSAEGjAYMAgGBmeBDAECATAMBgorBgEEAdZ5AgUDMDwGA1UdHwQ1MDMwMaAv
oC2GK2h0dHA6Ly9jcmxzLnBraS5nb29nL2d0czFjMy9mVkp4YlYtS3Rtay5jcmww
ggEEBgorBgEEAdZ5AgQCBIH1BIHyAPAAdgDuzdBk1dsazsVct520zROiModGfLzs
3sNRSFlGcR+1mwAAAY3AqKz3AAAEAwBHMEUCIQDODj3d6tB3O52F9JGeHcoQHvHa
slsfd24LzJkh4vaT8QIgRYpJ5/KtmHRedvtIMpk5cphz7YQtNR9xCJqS/HZp+RkA
dgDatr9rP7W2Ip+bwrtca+hwkXFsu1GEhTS9pD0wSNf7qwAAAY3AqK5zAAAEAwBH
MEUCIGnYz1wq87LoxyEFmfNJMUpu3tbe+SoXEICpiSMb0QT2AiEA6RfPUZfe+KL4
d+1tNrMI7JcbS/7i1iluGfg7i7qvAzQwDQYJKoZIhvcNAQELBQADggEBAAedT7Wd
Wf65c+210Rukhm/D3Gpku3QsYzo0fnAgGP4pTaH1w9DZN9YUSOoxlsfxBdldDdjy
OBTOyf/anQCZGyTb6RTJcCDq39xRiDBxp/S5p/hOhSMqezjQkj4r+dNg3yBMQ9vM
YVXjxQMNkEnBuaqF6gmymJITZ96cEiY7csPUemQp2qvBpwwkTlk09r36tg2llyN8
H2sGfiI+aMP+zTcCl96kBWh4W+dT+C90bjbZQvhzzuUT+sInPtUqcsCQ8ZNUeaY1
cwZlzV1fHFnDfHaMZN+3PO2eVHlbxR97v7FO6wLZYCPmcqlB2sj1uxucMT4tXaE7
pV0EwxaTDEzCaUs=
-END CERTIFICATE-
subject=CN = smtp.gmail.com

issuer=C = US, O = Google Trust Services LLC, CN = GTS CA 1C3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4295 bytes and written 386 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
     Protocol  : TLSv1.3
     Cipher    : TLS_AES_256_GCM_SHA384
     Session-ID: 
BF3720957764F292088B747CAB9764DC744CF9D40FD60FBB743AFADE7B74D5F6

     Session-ID-ctx:
     Resumption PSK: 
52E8D459E26A5E1C0005DEAA70BFEAE44CDFA2E884A26709BD4FF34DF08639F74A4AE17B2C400C3EFBC0BD19164458B4

     PSK identity: None
     PSK identity hint: None
     SRP username: None
     TLS session ticket lifetime hint: 172800 (seconds)
     TLS session ticket:
      - 02 c4 7d 37 12 90 68 40-1e 21 95 25 51 12 e3 10 
..}7..h@.!.%Q...
     0010 - 40 19 02 72 c3 8c 08 cd-bf dd d0 43 95 8f d0 d3 
@..r...C
     0020 - 42 2f d3 20 a8 56 03 24-74 3e a6 90 bc ac 3c 34   B/. 
.V.$t><4
     0030 - f2 54 d5 69 7a 30 88 cb-6d c0 e9 a6 95 56 05 1e 
.T.iz0..mV..
     0040 - 94 57 e7 46 b8 36 8a fc-19 1e c3 a2 13 9b 52 b8 
.W.F.6R.
     0050 - 1c b1 2a b1 5e a0 24 f1-64 5f 43 f2 d8 eb 00 6e 
..*.^.$.d_Cn
     0060 - f1 93 e3 d3 05 ea 27 fb-e0 77 8d 85 0a 44 09 cb 
..'..w...D..
     0070 - c2 7a 3b c5 86 40 03 98-eb 60 53 79 1b db 37 90 
.z;..@...`Sy..7.
     0080 - df 9b 39 5c bf 00 65 ba-09 5e a0 78 f6 f3 0c 44 
..9\..e..^.x...D
     0090 - a6 fb c5 86 57 7f 66 11-db 42 6f ba df c5 04 cd 
W.f..Bo.
     00a0 - 88 f5 3b 85 49 f0 89 6e-14 39 72 e1 64 7f e5 26 
..;.I..n.9r.d..&
     00b0 - ec da 76 cd 8e c6 22 ea-49 8a 95 0e 50 82 d8 ec 
..v...".I...P...
     00c0 - ae 79 81 fb 43 e7 88 dd-dd 15 4d 66 c2 b0 6a 3a 
.y..C.Mf..j:
     00d0 - 12 1f fb cd b9 dc 15 35-49 bd b4 f6 5c 2a 99 1a 
...5I...\*..

     00e0 - 7f df 1b ae 54 50 45 4c-cd 6a 25 b7 c3 6e 58 TPEL.j%..nX

     Start Time: 1710942237
     Timeout   : 7200 (sec)
     Verify return code: 0 (ok)
     Extended master secret: no
     Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
     Protocol  : TLSv1.3
     Cipher    : TLS_AES_2

[pfx] Re: Postfix thinks smtp.gmail.com uses self-signed certificate

[Cowbay via Postfix-users]

On 2024/3/23 04:57, Wietse Venema via Postfix-users wrote:

Unleess you can hand over the certificate that Postfix complained
about, you have not proven that Postfix was in error.
You are right, I can't guarantee if the certificate openssl dumped was 
the one Postfix encountered.




Specifically, yout tests with curl and openssl s_client may have
used a different IP address than Postfix, because the smtp.gmail.com
IP address changes frequently.

The smtp.gmail.com A record has a TTL of 300s, but it changes every
few seconds (it not only depends on when you ask, it also depends
on where you are). Here is a small sample, asked from an IP address
near New York city:

 Fri Mar 22 04:54:12 PM EDT 2024 172.253.62.109
 Fri Mar 22 04:54:13 PM EDT 2024 172.253.62.109
 Fri Mar 22 04:54:14 PM EDT 2024 172.253.62.108
 Fri Mar 22 04:54:16 PM EDT 2024 172.253.62.109
 Fri Mar 22 04:54:17 PM EDT 2024 172.253.62.108
 Fri Mar 22 04:54:18 PM EDT 2024 172.253.62.108
 Fri Mar 22 04:54:19 PM EDT 2024 172.253.62.108
 Fri Mar 22 04:54:20 PM EDT 2024 172.253.62.109
 Fri Mar 22 04:54:21 PM EDT 2024 172.253.62.109
 Fri Mar 22 04:54:22 PM EDT 2024 172.253.62.108
 Fri Mar 22 04:54:23 PM EDT 2024 172.253.62.108

Even if your tests did use the same IP address as Postfix, each
connection may be serviced by a different backend behind a load
balancer.

Even if you connected to the same backend, its configuration may
have changed. Like other providers, Google rolls out (SMTP) server
updates frequently. It updates a few servers and if the error rate
remains small it updates more servers, otherwise it rolls back the
change.

Wietse
Yes, make sense. It's possible that the backend of smtp.gmail.com 
produced self-signed certificates in certain period.


I grep the logs last time the problem happened, smtp.gmail.com resolved 
to "64.233.189.108" and "64.233.189.109" but all were out of luck to me.

8<8<8<
$ grep -i self-signed /var/log/mail.log
Mar 20 20:41:09 s6 postfix/smtp[1097]: certificate verification failed 
for smtp.gmail.com[64.233.189.108]:465: self-signed certificate
Mar 20 20:50:54 s6 postfix/smtp[3661]: certificate verification failed 
for smtp.gmail.com[64.233.189.109]:465: self-signed certificate
Mar 20 21:03:59 s6 postfix/smtp[6635]: certificate verification failed 
for smtp.gmail.com[64.233.189.109]:465: self-signed certificate
Mar 20 21:27:38 s6 postfix/smtp[15534]: certificate verification failed 
for smtp.gmail.com[64.233.189.109]:465: self-signed certificate

8<8<8<
Then I deleted this mail from the queue by using the postsuper.

On 2024/3/23 04:26, Viktor Dukhovni via Postfix-users wrote:
> On Wed, Mar 20, 2024 at 10:25:26PM +0800, Cowbay via Postfix-users wrote:
>
>> I'm using debian 10, an old debian distribution. The Postfix version is
>> 3.4.23.
>
> The base 4.0 release is ~5 years old, but not materially different in
> its core TLS functionality.  You'd see the same results with the latest
> Postfix 3.9.0.
>
Happy to know this.

>
> What is the "security level"?  You must have something in
> "smtp_tls_policy_maps" to require TLS for this destination.  What is the
> relevant entry there?  What is the main.cf value of
> "smtp_tls_security_level"?
>
My smtp_tls_policy_maps points to a hash table and the relevant entry is
  [smtp.gmail.com]:465secure

The smtp_tls_security_level in main.cf is
  smtp_tls_security_level = may

>> I believe my transport and sasl configurations are well since the
>> problem is postfix thinks smtp.gmail.com:465 uses self-signed
>> certificate.
>
> No, the self-signed certificate might have been some root CA that isn't
> listed in your CAfile.  Or perhaps the Gmail load-balancer did present
> a self-signed certificate for some reason.
>
Ok, you should be correct. The more precise statement from the Wikipedia 
is "self-signed certificates are public key certificates that are not 
issued by a certificate authority (CA)." So maybe that once the CA isn't 
listed in the CAfile the Postfix or the ssl library treats it as a 
self-signed certificate.


>> Do you have idea to solve this problem?
>
> If it isn't reproducible, it is unlikely that much can be determined
> long after the fact.
>
> Please share your TLS policy table entry, and when comparing Postfix
> against openssl sclient, specify the same IP address as the target host,
> at most minutes after observing any failure to verify the chain from
> Postfix. For example:
>
>  openssl s_client ... -verify_hostname smtp.gmail.com -connect 
64.233.189.109:465

>
> You should try with each of "-servername smtp.google.com" and
> "-noservername" options.
>
I wi

[pfx] Re: Postfix thinks smtp.gmail.com uses self-signed certificate

[Cowbay via Postfix-users]

On 2024/3/23 20:04, Wietse Venema via Postfix-users wrote:

Cowbay via Postfix-users:

So, I will collect necessary information next time I encounter this
issue as what Viktor suggested.


Please note that Postfix does not automatically use the "system"
root CA store that openssl s_client and curl may use. That could
result in verification differences between Postfix and other tools.

https://www.postfix.org/postconf.5.html#tls_append_default_CA

tls_append_default_CA (default: no)
 Append the system-supplied default Certification Authority
 certificates to the ones specified with *_tls_CApath or
 *_tls_CAfile. The default is "no"; this prevents Postfix from
 trusting third-party certificates and giving them relay permission
 with permit_tls_all_clientcerts.

Wietse

Thanks to this reminder and I will take care of this.

As my situation, I didn't explicitly assign this 
"tls_append_default_CA", so it should be default to "no".


And I specified "-o smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt" 
to "smtp.gmail" from the master.cf, specified "-CAfile 
/etc/ssl/certs/ca-certificates.crt" to "openssl s_client", and specify 
"--cacert /etc/ssl/certs/ca-certificates.crt" to "curl". I wish these 
would make sure Postfix, openssl and curl use the same CAfile to verify 
the certificate.


Cowbay

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

[pfx] Re: Postfix thinks smtp.gmail.com uses self-signed certificate

[Cowbay via Postfix-users]

On 2024/3/24 00:49, Viktor Dukhovni via Postfix-users wrote:


and also "posttls-finger" as in the example I posted.





You might not get to observe the problem for quite some time (if ever
again).


I'm quite seldom sending mail by gmail via my postfix server.

If the "posttls-finger" has the identical behavior as postfix, then I could write a 
simple cronjob script to "finger" the smtp.gmail.com:465.

OT: I just tried that my version of "posttls-finger" has no ipv6 support though 
the man page says it supports. And it always returns 0 even failed.
8<-8<-
$ host smtp.gmail.com
smtp.gmail.com has address 142.251.8.109
smtp.gmail.com has IPv6 address 2404:6800:4008:c15::6d

$ posttls-finger -wc -F /etc/ssl/certs/ca-certificates.crt -a ipv6 
[smtp.gmail.com]:465
posttls-finger: smtp.gmail.com[142.251.8.109]:465: matched peername: 
smtp.gmail.com
posttls-finger: smtp.gmail.com[142.251.8.109]:465: subject_CN=smtp.gmail.com, 
issuer_CN=GTS CA 1C3, 
fingerprint=F7:5F:AA:8D:B5:7A:A7:A4:8A:34:0C:C3:12:18:D8:77:3B:A9:F7:75:E1:EC:76:25:76:79:41:B2:AB:46:34:E1,
 
pkey_fingerprint=E9:BB:66:2D:A5:7C:05:FD:C4:EE:2D:CD:33:9C:32:6D:F7:99:7E:66:29:1F:F0:A4:5E:42:05:57:32:10:7C:96
posttls-finger: Verified TLS connection established to 
smtp.gmail.com[142.251.8.109]:465: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 
(256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) 
server-digest SHA256

$ posttls-finger -wc -F /etc/ssl/certs/ca-certificates.crt 
"[ipv6:2404:6800:4008:c15::6d]:465" smtp.gmail.com
posttls-finger: Destination address lookup failed: Name service error for 
2404:6800:4008:c15::6d: invalid host or domain name
8<-8<-
But this is no problem. It's enough to use ipv4.

I plan to use below script per hour.
8<-8<-
#!/bin/bash
FGR_SMTP_HOST="smtp.gmail.com"
FGR_SMTP_PORT=465
FGR_SMTP_IP=""
FGR_ERR_FOUND=0
FGR_FINGER_TMP="/tmp/posttls-finger-output-$$.tmp"
FGR_OPENSSL_TMP="/tmp/openssl-s-client-output-$$.tmp"
FGR_REPORT_EMAIL="b...@domain.tld"

posttls-finger -wc -F /etc/ssl/certs/ca-certificates.crt "[${FGR_SMTP_HOST}]:$FGR_SMTP_PORT" 
> "$FGR_FINGER_TMP"
grep -q -i fail "$FGR_FINGER_TMP" && FGR_ERR_FOUND=1
if [ $FGR_ERR_FOUND -eq 1 ]; then
  FGR_SMTP_IP="$(sed -n -E 's/^posttls-finger:.+\[([0-9.]+)\].*$/\1/p; T; q' 
"$FGR_FINGER_TMP")"
  openssl s_client -servername "$FGR_SMTP_HOST" -connect "${FGR_SMTP_IP}:$FGR_SMTP_IP" < 
/dev/null > "$FGR_OPENSSL_TMP"
  while true; do
echo "From: worker "
echo "To: boss <${FGR_REPORT_EMAIL}>"
echo "Date: $(date -R)"
echo "Subject: [posttls-finger] bad finger to $FGR_SMTP_HOST"
echo "MIME-Version: 1.0"
echo "Content-Type: text/plain; charset=utf-8"
echo "Content-Transfer-Encoding: 8bit"
echo "Message-Id: <$(date +%s)-${RANDOM}${RANDOM}@domain.tld>"
echo
echo "===> $FGR_FINGER_TMP"
cat "$FGR_FINGER_TMP"
echo
echo "===> $FGR_OPENSSL_TMP"
cat "$FGR_OPENSSL_TMP"
echo
break
  done | sendmail -i "$FGR_REPORT_EMAIL"
fi
rm -f "$FGR_FINGER_TMP" "$FGR_OPENSSL_TMP"
8<-8<-

If the "posttls-finger" has the identical behavior as postfix about verifying 
the certificate, then I can start to launch this cronjob.

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

[pfx] Re: Postfix thinks smtp.gmail.com uses self-signed certificate

[Cowbay via Postfix-users]

On 2024/3/25 01:12, Viktor Dukhovni via Postfix-users wrote:

If the "posttls-finger" has the identical behavior as postfix, then I
could write a simple cronjob script to "finger" the
smtp.gmail.com:465.


Not necessarily 100% identical, but quite close.

It seems not perfect. :(


$ posttls-finger -wc -F /etc/ssl/certs/ca-certificates.crt -a ipv6 
[smtp.gmail.com]:465


You neglected to specify "-lsecure", and just in case an explicit match
pattern:

My bad, I will add this "-lsecure" to "posttls-finger" and add "-CAfile" to the 
openssl command.


posttls-finger: Verified TLS connection established to 
smtp.gmail.com[142.251.8.109]:465: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 
(256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) 
server-digest SHA256


It does indeed look like IPv6 is not available on your end.

Actually, I was afraid that my postfix is too old to have this problem or the 
build mistake from old debian. I checked posttls-finger on my another container 
which is Ubuntu 22.04.4, posttls-finger still doesn't support ipv6, weird.


If the "posttls-finger" has the identical behavior as postfix about
verifying the certificate, then I can start to launch this cronjob.


Certificate verification should be identical, but if the presented chain
subtly depends on the client's TLS HELLO message, there could perhaps be
a difference if main.cf has "smtp_tls_..." settings that cause the HELLO
message to differ between smtp(8) and posttls-finger(1).

Since they are different, my idea to use posttls-finger seems unnecessary. I 
decide to cancel this idea.
But modify my script to monitor the postfix log for keyword "self-signed" every 
minute. I can expect that we cannot see any result in a short time.



The cipher grade will default to "medium", and (as in the Postfix
smtp(8) client) an SNI name won't be sent unless you specify one ("-s
smtp.gmail.com").

Thanks to remind me. I will add another posttls-finger with "-s" and add another openssl 
with "-noservername" to my modified script.

On 2024/3/24 00:49, Viktor Dukhovni via Postfix-users wrote:

One possible factor is the handling of TLS connections that don't set
the SNI name (Postfix default, see
).

I recall your remind as above. I didn't use "smtp_tls_servername" in my postfix.
For debug purpose, I should not modify my postfix configurations.
For formal usage, I should use DANE or specify "servername" attribute to the 
tls_policy.

mit seems that we prefer to believe postfix really got a self-signed 
certificate from smtp.gmail.com last time and maybe one of the cause is no SNI 
name sent.

I still decide to add the "servername" attribute to my tls_policy while also 
monitor the postfix log with my modified script. Maybe I will never have a result. :)

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

[pfx] Re: Postfix thinks smtp.gmail.com uses self-signed certificate

[Cowbay via Postfix-users]

On 2024/3/25 10:55, Viktor Dukhovni via Postfix-users wrote:

I checked posttls-finger on my another container which is Ubuntu
22.04.4, posttls-finger still doesn't support ipv6, weird.


It isn't posttls-finger that does not support "ipv6", but rather your
network stack.


It's still weird because I have ipv6 network stack and I can ping 
smtp.gmail.com's ipv6 address. See below:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 22.04.4 LTS
Release:22.04
Codename:   jammy

$ host smtp.gmail.com
smtp.gmail.com has address 173.194.174.108
smtp.gmail.com has IPv6 address 2404:6800:4008:c1b::6c

$ posttls-finger -wc -lsecure -F /etc/ssl/certs/ca-certificates.crt -a ipv6 
"[smtp.gmail.com]:465" smtp.gmail.com
posttls-finger: smtp.gmail.com[173.194.174.108]:465: matched peername: 
smtp.gmail.com
posttls-finger: smtp.gmail.com[173.194.174.108]:465: subject_CN=smtp.gmail.com, 
issuer_CN=GTS CA 1C3, 
fingerprint=F7:5F:AA:8D:B5:7A:A7:A4:8A:34:0C:C3:12:18:D8:77:3B:A9:F7:75:E1:EC:76:25:76:79:41:B2:AB:46:34:E1,
 
pkey_fingerprint=E9:BB:66:2D:A5:7C:05:FD:C4:EE:2D:CD:33:9C:32:6D:F7:99:7E:66:29:1F:F0:A4:5E:42:05:57:32:10:7C:96
posttls-finger: Verified TLS connection established to 
smtp.gmail.com[173.194.174.108]:465: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 
(256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) 
server-digest SHA256

$ ping -6 -c1 2404:6800:4008:c1b::6c
PING 2404:6800:4008:c1b::6c(2404:6800:4008:c1b::6c) 56 data bytes
64 bytes from 2404:6800:4008:c1b::6c: icmp_seq=1 ttl=58 time=9.21 ms

--- 2404:6800:4008:c1b::6c ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.210/9.210/9.210/0.000 ms

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

[pfx] Re: Postfix thinks smtp.gmail.com uses self-signed certificate

[Cowbay via Postfix-users]

On 2024/3/25 12:05, Viktor Dukhovni via Postfix-users wrote:

On Mon, Mar 25, 2024 at 12:00:12PM +0800, Cowbay via Postfix-users wrote:

On 2024/3/25 10:55, Viktor Dukhovni via Postfix-users wrote:

I checked posttls-finger on my another container which is Ubuntu
22.04.4, posttls-finger still doesn't support ipv6, weird.


It isn't posttls-finger that does not support "ipv6", but rather your
network stack.


It's still weird because I have ipv6 network stack and I can ping 
smtp.gmail.com's ipv6 address. See below:

$ host smtp.gmail.com
smtp.gmail.com has address 173.194.174.108
smtp.gmail.com has IPv6 address 2404:6800:4008:c1b::6c

$ posttls-finger -wc -lsecure -F /etc/ssl/certs/ca-certificates.crt -a ipv6 
"[smtp.gmail.com]:465" smtp.gmail.com
posttls-finger: smtp.gmail.com[173.194.174.108]:465: matched peername: 
smtp.gmail.com
posttls-finger: smtp.gmail.com[173.194.174.108]:465: subject_CN=smtp.gmail.com, 
issuer_CN=GTS CA 1C3, 
fingerprint=F7:5F:AA:8D:B5:7A:A7:A4:8A:34:0C:C3:12:18:D8:77:3B:A9:F7:75:E1:EC:76:25:76:79:41:B2:AB:46:34:E1,
 
pkey_fingerprint=E9:BB:66:2D:A5:7C:05:FD:C4:EE:2D:CD:33:9C:32:6D:F7:99:7E:66:29:1F:F0:A4:5E:42:05:57:32:10:7C:96
posttls-finger: Verified TLS connection established to 
smtp.gmail.com[173.194.174.108]:465: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 
(256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) 
server-digest SHA256


The "-a" option is a "preference", but perhaps you have separately
disabled IPv6 via "inet_protocols = ipv4" in main.cf?


Yes, you are right, THANKS.  ^_^

While my "inet_protocols = ipv4" in main.cf both "-a ipv6" and "[ipv6:address]" 
always no ipv6 function.
When "inet_protocols = all", posttls-finger works fine with ipv6.

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

[pfx] Re: Setting up another "smarthost" with Postfix

[Cowbay via Postfix-users]

On 2024/3/28 00:25, Samuel Goodies via Postfix-users wrote:

Hi guys. I'm inheriting a job that has an email server hosting several domains, 
and I'm wanting to move them behind our firewall and route mail from the main 
mail server to an offsite postfix server that will in turn send them out to 
wherever they need to go, kind of like my own homemade smarthost. Because of 
security we need to keep it all in house, so a paid smarthost isn't an option. 
This postfix server will only take mail from the server and send it out, and 
return bounce/errors to the main host. It won't accept any  incoming mail.


I'm a postfix user and try to image your plan.
 
   ___

  (   )
 (  internet   )
  (___)
   ^
   |
   v
 __
| MAIN MAIL SERVER |
 ~~
   ^
   |
   v
_
//   FIREWALL ///
~
   ^
   |
   v
 
| OFFSITE POSTFIX SERVER |
 
  ^ ^
  | |    "send them out to wherever they need to go"
  v v
[DOMAIN1] [DOMAIN2]  "several domains"

If this is what you said, then the "OFFSITE POSTFIX SERVER" is a relay only mail server. 
The "several domains" are the destinations.

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

[pfx] Re: private/dovecot-lmtp]: Connection refused)

[Cowbay via Postfix-users]

On 2024/5/11 22:51, Jason Hirsh via Postfix-users wrote:

My nonrandom action for tho morning OK I bandaided  my going back to an older 
main.cf but updating the ssl/tls infoThat brought mail back on line

Sort of


Dovecot still not happy with me but this error seems more warning and best 
suited to be addressed else where

  status=sent (delivered via dovecot service (lda(ja...@theoceanwindow.com  
): Error: 
net_connect_unix(/var/run/dovecot/stats-writer) failed: Permis))

Maybe Postfix has no permission to open /var/run/dovecot/stats-writer.
Check the file permission attributes of "/var/run/dovecot/stats-writer" and 
check Postfix's privilege.


May 11 09:33:00 triggerfish postfix/qmgr[52364]: 136046542A08: removed


Remember entropy can not be avoided



On May 11, 2024, at 8:50 AM, Viktor Dukhovni via Postfix-users 
mailto:postfix-users@postfix.org>> wrote:

On Sat, May 11, 2024 at 11:11:30AM +0200, Benny Pedersen via Postfix-users 
wrote:


I am running Postfix/Dovecot/MySQL mail server.   It was doing ok
until I tried to improve it., I


maybe just reboot ? :)


Unlikely to help.  Just restarting dovecot would be about the most
that's needed, but more likely, configuring dovecot correctly, and
then a "systemctl reload dovecot".  There's nothing to suggest the
kernel needs a restart.


I am pretty sure I did something wromnhg with TLS/SSL.   Ai was
working in certificates,   I have been at the so long my eye are
crossed


in most cases postfix have sanitises settings pr default, so when you add
unsanitises settings in main.cf you asking for knowledge why its changed


This makes no sense.


smtpd_sasl_auth_enable = yes


remove this in main.cf


Irrelevant.


Any ideas or pointers or random thoughts would be appreciated


world is not random


But one does sometimes run into random advice...

--
   Viktor.
___
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: Troubleshooting roundcube connections to postfix

[Cowbay via Postfix-users]

On 2024/6/18 10:43, Paul Schmehl via Postfix-users wrote:

On Jun 17, 2024, at 6:30 PM, Peter via Postfix-users 
 wrote:


On 17/06/2024 17:28, Paul Schmehl wrote:

How do you set up roundcube to not use authentication? I really don’t need it 
since it’s on the same machine as the mail server. What config options do I 
need to use?


To be honest, you still likely want authentication.  Keep in mind that you 
don't need to authenticate as a single user for roundcube but rather you can 
have roundcube pass authentication through from it's own user login and 
therefore support multiple users while also allowing postfix to support those 
same multiple users and see their individual logins. The point of this is that 
you can then use settings such as smtpd_sender_login_maps and 
reject_sender_login_mismatch in postfix to control individual users from 
roundcube.

http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps
http://www.postfix.org/postconf.5.html#reject_sender_login_mismatch


The problem is neither tls nor ssl worked. No matter what config I used, 
roundcube would always through an error. If I used $config['smtp_host'] = 
‘tls;//www.stovebolt.com'; or I used $config['smtp_host'] = 
’ssl;//www.stovebolt.com'; roundcube would error out saying it couldn’t connect 
to the server. If I removed them and used only the FQHN, it errored out saying 
the postfix doesn’t support authentication.

I thought maybe it might be a cert issue (I was using a self-signed cert), so I 
switched to a letsencrypt cert, but that made no difference. No matter what I 
did, roundcube refused to send mail.


I learned a tool to check this problem. You can try below command and check the 
output:

posttls-finger -w -lsecure -C "www.stovebolt.com:465" "www.stovebolt.com"



Paul Schmehl
paul.schm...@gmail.com



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

[pfx] Re: cleanup(8) not prepend Resent- headers but append

[Cowbay via Postfix-users]

On 2024/12/26 22:15, Wietse Venema via Postfix-users wrote:

Cowbay via Postfix-users:

Postfix adds a missing (Resent) Message-ID, Date, or From header
when a message is received as an original or resent submission, not
when it receives a message from a remote MTA (for some definition
of 'remote').

(Postfix detects that a message is resent when it contains a Resent-
header, including Resent-From, Resent-Message-Id, Resent-To,
Resent-Cc, Resent-Bcc, Resent-Reply-To, or Resent-Sender).


Okay. In my situation the mail should be from remote MTA (from port 25).

And since Postfix detected the Resent-Sender, then it adds the missing Resent- 
headers.


Postfix is not supposed to add or rewrite headers with mail from
remote MTAs, because doing so could break DKIM signatures.


This lets me know that I should remove the local_header_rewrite_clients 
parameter or just set as permit_inet_interfaces.


If you use a content_filter or smtpd_proxy_filter then the after-filter
Postfix sees a connedtion from localhost and needs to be told that
this is not a local submission.

COuld that be the problem?


No, I don't have problems.


The Postfix Resent- implementation is based on RFC 822 which in
section 4.1 syntax appears to suggest that 'originator' (From:,
Sender:) come before before 'resent' (Resent-From:, Resent-Sender).

Also, in RFC 822 the interpretation of multiple "Resent-" fields
of the same type was explicitly undefined. There were no multiple
Resent- blocks, let alone whether a newer Resent- block precedes
or follows an older one.

Thus, the Postfix implementation supports one Resent- block, and
its placement meets RFC 822 requirements.

(The implementation was done at a time that prepending would have
been technically impossible, because Postfix reads and writes out
headers one by one, and it would not have been able to prepend
something to a header that it had already written out.)

So yeah, you can blame me for not parsing RFC 5322 for changes
in Resent handling.


I post this issue just in case Postfix has unknown bugs. Now I
know that it's by design.

And actually I have no email clients that could send Resent- mails.
There is a feature "Redirect" in Thunderbird but the redirected
mails have new Date and To headers without any Resent- header, so
it's not Resent-.


Considering that RFC 5322 made a complex mess of Resent- headers,
it seems best for Postfix to stop adding "missing" Resent- headers
by default.

Wietse

Since the Resent- headers is not necessary Postfix's responsibility and the 
usages of the Resent- headers are rare, it appears fine to me to stop this 
feature.

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

[pfx] cleanup(8) not prepend Resent- headers but append

[Cowbay via Postfix-users]

Hello,

My Postfix is 3.4.23-0+deb10u2. It's old.

I got a rare mail with the Resent-Sender header and no other Resent- headers.

Since I configured the local_header_rewrite_clients, cleanup(8) insert the 
missing Resent- headers for this mail.

According to RFC 5322 Appendix A.3. 
(https://datatracker.ietf.org/doc/html/rfc5322#appendix-A.3)

resent fields are prepended to the message:
   
   Resent-From: Mary Smith 
   Resent-To: Jane Brown 
   Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
   Resent-Message-ID: <78...@example.net>
   From: John Doe 
   To: Mary Smith 
   Subject: Saying Hello
   Date: Fri, 21 Nov 1997 09:55:06 -0600
   Message-ID: <1234@local.machine.example>

   This is a message just to say hello.
   So, "Hello".
   

However cleanup(8) didn't prepend but append. It's like below:
   
   From: John Doe 
   To: Mary Smith 
   Subject: Saying Hello
   Date: Fri, 21 Nov 1997 09:55:06 -0600
   Message-ID: <1234@local.machine.example>
   Resent-From: Mary Smith 
   Resent-To: Jane Brown 
   Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
   Resent-Message-ID: <78...@example.net>

   This is a message just to say hello.
   So, "Hello".
   


There is another interesting behavior that if there is no Message-Id header, 
cleanup(8) won't insert the Message-Id header and append all missing Resent- 
headers.

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

[pfx] Re: cleanup(8) not prepend Resent- headers but append

[Cowbay via Postfix-users]

On 2024/12/26 06:04, Wietse Venema via Postfix-users wrote:

Cowbay via Postfix-users:

Hello,

My Postfix is 3.4.23-0+deb10u2. It's old.

I got a rare mail with the Resent-Sender header and no other Resent- headers.

Since I configured the local_header_rewrite_clients, cleanup(8) insert the 
missing Resent- headers for this mail.

According to RFC 5322 Appendix A.3. 
(https://datatracker.ietf.org/doc/html/rfc5322#appendix-A.3)

  resent fields are prepended to the message:
 
 Resent-From: Mary Smith 
 Resent-To: Jane Brown 
 Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
 Resent-Message-ID: <78...@example.net>
 From: John Doe 
 To: Mary Smith 
 Subject: Saying Hello
 Date: Fri, 21 Nov 1997 09:55:06 -0600
 Message-ID: <1234@local.machine.example>

 This is a message just to say hello.
 So, "Hello".
 

However cleanup(8) didn't prepend but append. It's like below:
 
 From: John Doe 
 To: Mary Smith 
 Subject: Saying Hello
 Date: Fri, 21 Nov 1997 09:55:06 -0600
 Message-ID: <1234@local.machine.example>
 Resent-From: Mary Smith 
 Resent-To: Jane Brown 
 Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
 Resent-Message-ID: <78...@example.net>

 This is a message just to say hello.
 So, "Hello".
 


There is another interesting behavior that if there is no Message-Id
header, cleanup(8) won't insert the Message-Id header and append
all missing Resent- headers.


Postfix adds a missing (Resent) Message-ID, Date, or From header
when a message is received as an original or resent submission, not
when it receives a message from a remote MTA (for some definition
of 'remote').

(Postfix detects that a message is resent when it contains a Resent-
header, including Resent-From, Resent-Message-Id, Resent-To,
Resent-Cc, Resent-Bcc, Resent-Reply-To, or Resent-Sender).


Okay. In my situation the mail should be from remote MTA (from port 25).

And since Postfix detected the Resent-Sender, then it adds the missing Resent- 
headers.


The Postfix Resent- implementation is based on RFC 822 which in
section 4.1 syntax appears to suggest that 'originator' (From:,
Sender:) come before before 'resent' (Resent-From:, Resent-Sender).

Also, in RFC 822 the interpretation of multiple "Resent-" fields
of the same type was explicitly undefined. There were no multiple
Resent- blocks, let alone whether a newer Resent- block precedes
or follows an older one.

Thus, the Postfix implementation supports one Resent- block, and
its placement meets RFC 822 requirements.

(The implementation was done at a time that prepending would have
been technically impossible, because Postfix reads and writes out
headers one by one, and it would not have been able to prepend
something to a header that it had already written out.)

So yeah, you can blame me for not parsing RFC 5322 for changes
in Resent handling.

Wietse

I post this issue just in case Postfix has unknown bugs. Now I know that it's 
by design.

And actually I have no email clients that could send Resent- mails. There is a feature 
"Redirect" in Thunderbird but the redirected mails have new Date and To headers 
without any Resent- header, so it's not Resent-.

Thank you for the details.

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