[pfx] Re: Value of client certificates, was: Re: Re: [ext] list.sys4.de fails with starttls
On Mon, Sep 25, 2023 at 05:51:05PM -0400, Viktor Dukhovni via Postfix-users wrote: > Not, dangerous, just largely pointless, with *potential* complications, > unless there are servers that can actually make use of said > certificates. Can a case be made for promoting anonymous ciphers? I feel they are under appreciated and under used. In a lot of use cases, authentication is done via another channel or even if there is a problem with the cert, you go ahead anyway. Only encryption is used and not authentication but we maintain the bits for auth anyway potentially causing problems. -- Eray ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Exporting environment to specific pipe service
I'd like to export a single var to a set of pipe processes without wrapping with env or setting export_environment in main.cf. This works in main.cf, export_environment=TZ MAIL_CONFIG LANG X=Y On the other hand, adding -o export_environment="TZ MAIL_CONFIG LANG X=Y" in master.cf results in a parser error, "fatal: unknown attribute name: TZ" vmaildrop unix - n n - 20 pipe -o export_environment="LANG TZ MAIL_CONFIG X=Y" flags=XODRhu user=mail argv=/usr/bin/maildrop This works as well but clunky: vmaildrop unix - n n - 20 pipe flags=XODRhu user=mail argv=/usr/bin/env X=Y /usr/bin/maildrop Is there a better approach? - Matt ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Exporting environment to specific pipe service
Matt Saladna via Postfix-users:
> I'd like to export a single var to a set of pipe processes without
> wrapping with env or setting export_environment in main.cf.
>
> This works in main.cf,
>
> export_environment=TZ MAIL_CONFIG LANG X=Y
>
> On the other hand, adding -o export_environment="TZ MAIL_CONFIG LANG
> X=Y" in master.cf results in a parser error, "fatal: unknown attribute
> name: TZ"
Did you reaad "man 5 master"? You should.
> vmaildrop unix - n n - 20 pipe
> -o export_environment="LANG TZ MAIL_CONFIG X=Y"
> flags=XODRhu user=mail argv=/usr/bin/maildrop
Use: -o { export_environment = LANG TZ MAIL_CONFIG ... }
And RTFM.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Value of client certificates, was: Re: Re: [ext] list.sys4.de fails with starttls
On Tue, Sep 26, 2023 at 10:49:30AM +0200, Eray Aslan via Postfix-users wrote: > On Mon, Sep 25, 2023 at 05:51:05PM -0400, Viktor Dukhovni via Postfix-users > wrote: > > Not, dangerous, just largely pointless, with *potential* complications, > > unless there are servers that can actually make use of said > > certificates. > > Can a case be made for promoting anonymous ciphers? I feel they are > under appreciated and under used. In a lot of use cases, authentication > is done via another channel or even if there is a problem with the cert, > you go ahead anyway. Only encryption is used and not authentication but > we maintain the bits for auth anyway potentially causing problems. Sure: https://datatracker.ietf.org/doc/html/rfc7672#section-8.2 Sadly, AFAIK, none have yet been specified for TLS 1.3. And the choices for TLS 1.2 are somewhat limited (none with both AECDH and either GCM or SHA-2 for example): https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 $ openssl ciphers -s -tls1_2 -v 'ALL:!aRSA:!aECDSA:!aDSS:!SEED:!SRP:!PSK:@SECLEVEL=0' ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD ADH-AES256-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(256) Mac=SHA256 ADH-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=None Enc=Camellia(256) Mac=SHA256 ADH-AES128-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(128) Mac=SHA256 ADH-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=None Enc=Camellia(128) Mac=SHA256 AECDH-AES256-SHATLSv1 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1 ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1 ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1 AECDH-AES128-SHATLSv1 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1 ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1 ADH-CAMELLIA128-SHA SSLv3 Kx=DH Au=None Enc=Camellia(128) Mac=SHA1 So the opportunity to use anonymous ciphers is slipping away. With TLS 1.2, Postfix does use anon-ECDH or anon-DH ciphers when mutually supported (e.g. Postfix client to Postfix server at security levels "may" or "encrypt"). An example from my logs: Sep 25 18:09:58 amnesiac postfix/smtpd[66854]: Anonymous TLS connection established from mailer2.gandi.net[217.70.182.74]: TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits) Sep 25 20:15:27 straasha postfix/smtpd[16441]: Anonymous TLS connection established from mail70-4z9c.e2ma.net[139.60.2.70]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) "Anonymous" here just means no *client* cert, but the cipher name "ADH-..." or "AECDH-..." is one that is certificate-free in both directions. There is typically little support in the IETF TLS working group for adding more anonymous ciphers. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
> Sadly, I need smtp_address_preference = ipv4 because some > reputation systems (spamhaus, I think) don't realise > that an entity might only have a single ipv6 address. Then you should disable IPv6, in the PostfiX SMTP client (master.cf: smtp -o inet_protocols=ipv4) or globally (main.cf:inet_protocols=ipv4). Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
On 26.09.23 10:45, Polarian via Postfix-users wrote: The complaint and the reason why some email providers intentionally do not support IPv6 is that the IPv4 exhaustion can be used as a benefit for lazy security. Due to the number of IPv6, email server spam is a lot harder to block, there is more addresses. I have seen this complained about a lot. Blocking spam senders is nearly as important as blocking spam. Otherwise, there is no reason for senders to avoid sending spam from their networks/servers. So I think it is intentional the fact that some spam checkers intentionally flag IPv6 emails simply because the number of addresses and the ease of just using a different IP address. Personally I argue IP banning is not an effective method of security, but yet it is what most companies employ for their application and it is why every site on the internet (well almost) will log your IP addresses for weeks to try to spot suspicious patterns. Scoring (instead of simply banning) mail sender is quite effective, because you don't have to receive and parse whole e-mail. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux - It's now safe to turn on your computer. Linux - Teraz mozete pocitac bez obav zapnut. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
On Tue, Sep 26, 2023 at 05:55:59PM +0200, Matus UHLAR - fantomas via Postfix-users wrote: > Scoring (instead of simply banning) mail sender is quite effective, because > you don't have to receive and parse whole e-mail. This is drifting off-topic for Postfix. Perhaps continue the discussion on mailop or similar, if there's interest in ongoing discussion? -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
Wietse Venema via Postfix-users: > Wietse Venema via Postfix-users: > > It's a rather long explanation for "why not do X". like several > > times longer than the text that explains what protocol preferences > > do. And this is the only place where adding that text would help. > > I updated the text a little: I'm adding a section to smtp_address_preferences, about when not to use this setting. Wietse Notes for mail delivery between sites that have both IPv4 and IPv6 connectivity: * Some remote SMTP servers will flag messages received over IPv6 as more 'spammy' than messages received over IPv4. This may be because the Postfix SMTP client's IPv6 address lacks a proper PTR record, or because the client shares an IPv6 address block with bad users. To achieve consistent delivery performance, don't tweak the smtp_address_preference setting; instead, receive mail over both IPv4 and IPv6, and deliver mail only over IPv4. /etc/postfix/main.cf: inet_protocols = all /etc/postfix/master.cf smtp ...other fields... smtp -o inet_protocols=ipv4 * The setting "smtp_address_preference = ipv6" is unsafe. [Existing text omitted for brevity] ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Exporting environment to specific pipe service
Thanks, I misunderstood the format as -o export_environment = {TZ
MAIL_CONFIG X=Y} from postconf(5) => export_environment. For the sake of
completeness, -o { export_environment = LANG TZ X=${y} } in master.cf
and defining y=z in main.cf does exactly what I want.
- Matt
On 9/26/2023 7:51 AM, Wietse Venema via Postfix-users wrote:
Matt Saladna via Postfix-users:
I'd like to export a single var to a set of pipe processes without
wrapping with env or setting export_environment in main.cf.
This works in main.cf,
export_environment=TZ MAIL_CONFIG LANG X=Y
On the other hand, adding -o export_environment="TZ MAIL_CONFIG LANG
X=Y" in master.cf results in a parser error, "fatal: unknown attribute
name: TZ"
Did you reaad "man 5 master"? You should.
vmaildrop unix - n n - 20 pipe
-o export_environment="LANG TZ MAIL_CONFIG X=Y"
flags=XODRhu user=mail argv=/usr/bin/maildrop
Use: -o { export_environment = LANG TZ MAIL_CONFIG ... }
And RTFM.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
On Tue, Sep 26, 2023 at 10:35:39AM -0400, Wietse Venema via Postfix-users wrote: > > Sadly, I need smtp_address_preference = ipv4 because some > > reputation systems (spamhaus, I think) don't realise > > that an entity might only have a single ipv6 address. > > Then you should disable IPv6, in the PostfiX SMTP client > (master.cf: smtp -o inet_protocols=ipv4) or globally > (main.cf:inet_protocols=ipv4). > > Wietse Yes, I'm sure you're right, but I want to be able to receive mail via ipv6, and if sending via ipv4 is ever impossible, I'd rather attempt ipv6 and risk a rejection. I haven't gotten any bounce messages since favouring ipv4 in the client, but if I do I'll make this change for the client. Thanks. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
On Tue, Sep 26, 2023 at 02:01:24PM -0400, Wietse Venema via Postfix-users wrote: > Wietse Venema via Postfix-users: > > Wietse Venema via Postfix-users: > > > It's a rather long explanation for "why not do X". like several > > > times longer than the text that explains what protocol preferences > > > do. And this is the only place where adding that text would help. > > > > I updated the text a little: > > I'm adding a section to smtp_address_preferences, about when not > to use this setting. > > Wietse > > Notes for mail delivery between sites that have both IPv4 and IPv6 > connectivity: > > * Some remote SMTP servers will flag messages received over IPv6 > as more 'spammy' than messages received over IPv4. This may be > because the Postfix SMTP client's IPv6 address lacks a proper > PTR record, or because the client shares an IPv6 address block > with bad users. > > To achieve consistent delivery performance, don't tweak the > smtp_address_preference setting; instead, receive mail over > both IPv4 and IPv6, and deliver mail only over IPv4. > > /etc/postfix/main.cf: > inet_protocols = all > > /etc/postfix/master.cf > smtp ...other fields... smtp -o inet_protocols=ipv4 > > * The setting "smtp_address_preference = ipv6" is unsafe. [Existing > text omitted for brevity] Should -o inet_protocols=ipv4 also be added to the relay directive? cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
raf via Postfix-users: > On Tue, Sep 26, 2023 at 02:01:24PM -0400, Wietse Venema via Postfix-users > wrote: > > > Wietse Venema via Postfix-users: > > > Wietse Venema via Postfix-users: > > > > It's a rather long explanation for "why not do X". like several > > > > times longer than the text that explains what protocol preferences > > > > do. And this is the only place where adding that text would help. > > > > > > I updated the text a little: > > > > I'm adding a section to smtp_address_preferences, about when not > > to use this setting. > > > > Wietse > > > > Notes for mail delivery between sites that have both IPv4 and IPv6 > > connectivity: > > > > * Some remote SMTP servers will flag messages received over IPv6 > > as more 'spammy' than messages received over IPv4. This may be > > because the Postfix SMTP client's IPv6 address lacks a proper > > PTR record, or because the client shares an IPv6 address block > > with bad users. > > > > To achieve consistent delivery performance, don't tweak the > > smtp_address_preference setting; instead, receive mail over > > both IPv4 and IPv6, and deliver mail only over IPv4. > > > > /etc/postfix/main.cf: > > inet_protocols = all > > > > /etc/postfix/master.cf > > smtp ...other fields... smtp -o inet_protocols=ipv4 > > > > * The setting "smtp_address_preference = ipv6" is unsafe. [Existing > > text omitted for brevity] > > Should -o inet_protocols=ipv4 also be added to the relay directive? The relay_transport is used for domains in main.cf:relay_domains. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: pipelining issue
Thanks everyone, it may be the filtering process as mentioned. This is a Proxmox Mail Gateway running Postfix. I do see these type of errors but will look at more details based on everyone's suggestions and then report back. 2023-09-26T21:34:00.391589-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:42906 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.399983-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:38040 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.404921-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:49176 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.406388-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:38052 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.411829-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:42922 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.417371-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:42928 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.470597-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:49186 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.477706-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:38056 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.492245-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:42932 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.519140-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:38062 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.525961-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:49188 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.537156-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:38072 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.550920-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:42942 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.560370-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:49196 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.580703-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:42946 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:00.586122-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:38082 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.522481-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:49228 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.526253-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:42970 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.538978-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:38146 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.558545-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:49236 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.562384-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:42976 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.571537-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:49248 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.577651-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:38162 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.579153-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:38160 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.584713-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:49258 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.585693-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:42980 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.667300-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:42986 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.671298-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:38164 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.683631-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:49268 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.695531-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:38172 after RCPT: DATA\r\nQUITE\r\n 2023-09-26T21:34:01.707382-04:00 mgw postfix/postscreen[469237]: COMMAND PIPELINING from [208.99.44.83]:49270 after RCPT: DATA\r\nQUITE\r\n On Wed, Sep 20, 2023 at 12:42 PM Wietse Venema wrote: > Joey J via Postfix-users: > > In: DATA > > Out: 354 End data with . > > Out: 451 4.3.0 Error: queue file write error > > Look in Postfix logs. > > https://www.postfix.org/DEBUG_README.html#logging > > Look for obvious signs of trouble Postfix logs all failed and > successful deliveries to a logfile. > > When Postfix uses syslog logging (the default), the file is usu
