Re: Authenticated Receive Chain (ARC Sealing) in Postfix?
> On Jan 2, 2023, at 4:20 PM, raf wrote: > > On Mon, Jan 02, 2023 at 08:32:42PM +, "Cooper, Robert A" > wrote: > >> I have a request from my downstream Exchange admins to look into >> implementing ARC sealing in some postfix relay servers we use for >> address rewriting. From the bit of research I've done, it looks like >> this would require being implemented in an external milter. I had not >> even heard of ARC before today; it looks like it's an experimental RFC >> from 2019 that Microsoft and Google have implemented in their systems. >> Does anyone have experience with ARC or how to set it up with postfix? >> >> Thanks >> RobertC > > You could look into OpenARC (https://github.com/trusteddomainproject/OpenARC). > I was under the impression that it wasn't finished, but I think that's wrong. > I've heard of people using it. It's written by the same group that wrote > OpenDKIM. My dayjob is using openarc to seal our mailman mailing list traffic — and google at least seems to recognize that the seals are valid (this does not mean that they “trust” it more, just that it validates). There was some discussion on bind-users that starts here: https://lists.isc.org/pipermail/bind-users/2022-September/106612.html Although due to mailman’s archiving being dumb, there’s one more reply here: https://lists.isc.org/pipermail/bind-users/2022-October/106746.html I will note that we run our messages though openARC at both the point where mail enters our network (at our border MXes) as well as on our mailman machines, which applies a seal both as a message enters, and exits. This is the way the received chain is supposed to work. Hope it helps, or at least demystifies? -Dan
Re: Patch: cleanup log
Tuesday, January 3, 2023, 2:47:45 PM, Viktor Dukhovni wrote: > On Mon, Jan 02, 2023 at 07:32:51PM -0500, Wietse Venema wrote: >> > I was just curious what might cause that string of question marks. >> >> This is what a Postfix string looks like after its memory is freed. >> Something to look at in the train tomorrow. > Simple patch, the cache dictionary name is freed a bit too soon during > shutdown: > --- src/util/dict_cache.c > +++ src/util/dict_cache.c > @@ -659,8 +659,8 @@ voiddict_cache_close(DICT_CACHE *cp) > /* > * Destroy the DICT_CACHE object. > */ -myfree(cp->>name); > dict_cache_control(cp, DICT_CACHE_CTL_INTERVAL, 0, DICT_CACHE_CTL_END); +myfree(cp->>name); > dict_close(cp->db); > if (cp->saved_curr_key) > myfree(cp->saved_curr_key); Thank you, Victor. I hope you haven't deprived Wietse of something to do on the train. :) Cheers, Phil
Patch: cleanup log
On Mon, Jan 02, 2023 at 07:32:51PM -0500, Wietse Venema wrote: > > I was just curious what might cause that string of question marks. > > This is what a Postfix string looks like after its memory is freed. > Something to look at in the train tomorrow. Simple patch, the cache dictionary name is freed a bit too soon during shutdown: --- src/util/dict_cache.c +++ src/util/dict_cache.c @@ -659,8 +659,8 @@ voiddict_cache_close(DICT_CACHE *cp) /* * Destroy the DICT_CACHE object. */ -myfree(cp->name); dict_cache_control(cp, DICT_CACHE_CTL_INTERVAL, 0, DICT_CACHE_CTL_END); +myfree(cp->name); dict_close(cp->db); if (cp->saved_curr_key) myfree(cp->saved_curr_key); -- Viktor.
Re: [Devel] OpenSSL 3.0 + TLS 1.3 and FFDHE key exchange
On Mon, Jan 02, 2023 at 01:21:07PM -0500, Viktor Dukhovni wrote: > > Assuming that these finite fields are different than the finite > > fields that elliptic curve cryptography is based on, the proposed > > parameter structure seems sensble to me. > > Yes, indeed the underlying coefficient finite fields for the EC groups > are not based on the same primes as any of the FFDHE groups, and even > if some of the primes were the same, these are still independent code > points. > > I'll post a patch before too long. Attached. -- Viktor. 0001-FFDHE-support-for-TLS-1.3-w-OpenSSL-3.0.patch.gz Description: application/gzip
Re: cleanup log
Phil Biggs: > Hello and happy new year to all, > > My friend is currently running FreeBSD 13.1-RELEASE-p2 GENERIC with the > postfix-sasl-3.7.2_1,1 pkg. > > Today I noticed this in his log: > > 2023-01-02T20:07:39.385545+11:00 postfix.[redacted] postfix/verify 23191 - - > cache ??? partial cleanup: retained=1 > dropped=0 entries > > Searching back through some archived logs from the same host, I found these: > > 2020-01-17 00:03:3910.0.1.8<22>Jan 17 00:03:40 postfix/verify[33140]: > cache ??? partial cleanup: retained=1 > dropped=0 entries > 2020-09-02 19:44:5710.0.1.8<22>Sep 2 19:44:59 > postfix/postscreen[68217]: cache ??? > partial cleanup: retained=1 dropped=0 entries > > So this is very rare and doesn't seem to cause any other issues - > cleanups work fine the rest of the time. > > I was just curious what might cause that string of question marks. This is what a Postfix string looks like after its memory is freed. Something to look at in the train tomorrow. Wietse > My own logs, on a very similar server, don't seem to have any instances of > the > same. > > > Thanks, > Phil > >
Re: Authenticated Receive Chain (ARC Sealing) in Postfix?
On 1/2/23 15:32, Cooper, Robert A wrote: > I have a request from my downstream Exchange admins to look into implementing > ARC sealing in some postfix relay servers we use for address rewriting. From > the bit of research I've done, it looks like this would require being > implemented in an external milter. I had not even heard of ARC before today; > it looks like it's an experimental RFC from 2019 that Microsoft and Google > have implemented in their systems. Does anyone have experience with ARC or > how to set it up with postfix? Fastmail’s Authentication Milter? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Authenticated Receive Chain (ARC Sealing) in Postfix?
On Mon, Jan 02, 2023 at 08:32:42PM +, "Cooper, Robert A" wrote: > I have a request from my downstream Exchange admins to look into > implementing ARC sealing in some postfix relay servers we use for > address rewriting. From the bit of research I've done, it looks like > this would require being implemented in an external milter. I had not > even heard of ARC before today; it looks like it's an experimental RFC > from 2019 that Microsoft and Google have implemented in their systems. > Does anyone have experience with ARC or how to set it up with postfix? > > Thanks > RobertC You could look into OpenARC (https://github.com/trusteddomainproject/OpenARC). I was under the impression that it wasn't finished, but I think that's wrong. I've heard of people using it. It's written by the same group that wrote OpenDKIM. cheers, raf
cleanup log
Hello and happy new year to all, My friend is currently running FreeBSD 13.1-RELEASE-p2 GENERIC with the postfix-sasl-3.7.2_1,1 pkg. Today I noticed this in his log: 2023-01-02T20:07:39.385545+11:00 postfix.[redacted] postfix/verify 23191 - - cache ??? partial cleanup: retained=1 dropped=0 entries Searching back through some archived logs from the same host, I found these: 2020-01-17 00:03:3910.0.1.8<22>Jan 17 00:03:40 postfix/verify[33140]: cache ??? partial cleanup: retained=1 dropped=0 entries 2020-09-02 19:44:5710.0.1.8<22>Sep 2 19:44:59 postfix/postscreen[68217]: cache ??? partial cleanup: retained=1 dropped=0 entries So this is very rare and doesn't seem to cause any other issues - cleanups work fine the rest of the time. I was just curious what might cause that string of question marks. My own logs, on a very similar server, don't seem to have any instances of the same. Thanks, Phil
Re: Authenticated Receive Chain (ARC Sealing) in Postfix?
Cooper, Robert A skrev den 2023-01-02 21:32: I have a request from my downstream Exchange admins to look into implementing ARC sealing in some postfix relay servers we use for address rewriting. From the bit of research I've done, it looks like this would require being implemented in an external milter. I had not even heard of ARC before today; it looks like it's an experimental RFC from 2019 that Microsoft and Google have implemented in their systems. Does anyone have experience with ARC or how to set it up with postfix? https://fuglu.org/plugins-index.html#arc-sign dont know if it fits or not i will not advitice others, since there is so much good software out there, if one knows what to search for i use fuglu here, have not regretted it yet
Re: Authenticated Receive Chain (ARC Sealing) in Postfix?
On 1/2/23 15:32, Cooper, Robert A wrote: I have a request from my downstream Exchange admins to look into implementing ARC sealing in some postfix relay servers we use for address rewriting. From the bit of research I've done, it looks like this would require being implemented in an external milter. I had not even heard of ARC before today; it looks like it's an experimental RFC from 2019 that Microsoft and Google have implemented in their systems. Does anyone have experience with ARC or how to set it up with postfix? ARC is not really relevant to most MTAs as such. ARC exists to solve the problem of authenticating mail that contains remailed messages, i.e. principally mailing lists, which almost universally break DMARC just as a simple matter of the nature of the beast. Quoting Wikipedia, Authenticated Received Chain (ARC) is an email authentication system designed to allow an intermediate mail server like a mailing list or forwarding service to sign an email's original authentication results. This allows a receiving service to validate an email when the email's SPF and DKIM records are rendered invalid by an intermediate server's processing.[1] (https://en.wikipedia.org/wiki/Authenticated_Received_Chain) To the best of my knowledge, Postfix itself does not internally support ARC, because it doesn't need to in any normal Postfix use case. On the other hand, Sympa (the mailing list manager I use) needs to, and does. The most I can offer in the edge case you have is that I am aware of the existence of something called OpenARC. I've never tried it and can't give any advice about configuring it, but it does exist and is deployed as a milter. So maybe look at OpenARC. You'll find a host of links to other irrelevant things — companies, compilers, recruiting firms, second-hand frobnitz dealers — also called OpenArc, but this is probably a good place to start: https://github.com/trusteddomainproject/OpenARC -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
Authenticated Receive Chain (ARC Sealing) in Postfix?
I have a request from my downstream Exchange admins to look into implementing ARC sealing in some postfix relay servers we use for address rewriting. From the bit of research I've done, it looks like this would require being implemented in an external milter. I had not even heard of ARC before today; it looks like it's an experimental RFC from 2019 that Microsoft and Google have implemented in their systems. Does anyone have experience with ARC or how to set it up with postfix? Thanks RobertC
Re: parent_domain_matches_subdomains && smtpd_access_maps
Le 02/01/2023 à 20:38, Laurent Frigault a écrit : Hi, Is there any way to have some smtpd_access_maps with parent_domain_matches_subdomains and some other without it ? I have : smtpd_recipient_restrictions = permit_mynetworks reject_non_fqdn_sender reject_unknown_sender_domain reject_unauth_destination check_sender_access hash:$config_directory/sender_access check_recipient_access hash:$config_directory/rcpt_recipient_access I would like to have parent_domain_matches_subdomains in rcpt_recipient_access and not in sender_access Without parent_domain_matches_subdomains matching property, subdomains of mydomain.net are expressed as .mydomain.net. So in parent_domain_matches_subdomains put two lines for domains for witch you want subdomain matching. For sane behavior I always disable parent_domain_matches_subdomain matching and always use explicit subdomain matching where needed. That is a personal preference. Emmanuel.
Re: parent_domain_matches_subdomains && smtpd_access_maps
On 1/2/2023 1:38 PM, Laurent Frigault wrote: Is there any way to have some smtpd_access_maps with parent_domain_matches_subdomains and some other without it ? I have : smtpd_recipient_restrictions = permit_mynetworks reject_non_fqdn_sender reject_unknown_sender_domain reject_unauth_destination check_sender_access hash:$config_directory/sender_access check_recipient_access hash:$config_directory/rcpt_recipient_access I would like to have parent_domain_matches_subdomains in rcpt_recipient_access and not in sender_access The p_d_m_s setting is global per instance, but one thing you can do is unset it (remove smtpd_access_maps) and use the workaround to include subdomains of the parent as needed: example.com target .example.comtarget Yes, it means using 2 entries for each domain where you want inclusion of subdomains, but it's not hard to automate adding all these to your existing map. -- http://rob0.nodns4.us/
Re: parent_domain_matches_subdomains && smtpd_access_maps
Laurent Frigault: > Hi, > > Is there any way to have some smtpd_access_maps with > parent_domain_matches_subdomains and some other without it ? There currently is no syntax to force some lookups with and some without. However, parent_domain_matches_subdomains does not apply to pcre:, regexp:, tcp:, and socketmap: tables and check_policy lookups. These always get the full domain. Maybe you can handle check_sender_access that way. Wietse > I have : > smtpd_recipient_restrictions = > permit_mynetworks > reject_non_fqdn_sender > reject_unknown_sender_domain > reject_unauth_destination > check_sender_access hash:$config_directory/sender_access > check_recipient_access hash:$config_directory/rcpt_recipient_access > > > I would like to have parent_domain_matches_subdomains in > rcpt_recipient_access and not in sender_access > > Regards, > -- > Laurent Frigault | http://www.agneau.org/> >
parent_domain_matches_subdomains && smtpd_access_maps
Hi, Is there any way to have some smtpd_access_maps with parent_domain_matches_subdomains and some other without it ? I have : smtpd_recipient_restrictions = permit_mynetworks reject_non_fqdn_sender reject_unknown_sender_domain reject_unauth_destination check_sender_access hash:$config_directory/sender_access check_recipient_access hash:$config_directory/rcpt_recipient_access I would like to have parent_domain_matches_subdomains in rcpt_recipient_access and not in sender_access Regards, -- Laurent Frigault | http://www.agneau.org/>
Re: [Devel] OpenSSL 3.0 + TLS 1.3 and FFDHE key exchange
On Mon, Jan 02, 2023 at 12:57:05PM -0500, Wietse Venema wrote: > > But doing this in a backwards-compatible way, that still works for any > > users who were brave enough to set "tls_eecdh_auto_curves" expecting > > to just limit the EC groups, means that we'll need two parameters with > > the below defaults: > > > > tls_eecdh_auto_curves = X25519 X448 prime256v1 secp521r1 secp384r1 > > tls_ffdhe_auto_groups = ffdhe2048 ffdhe3072 > > > > When Postfix is linked with OpenSSL 3.0, the two lists will be merged > > together. > > > > Any comments or questions? > > Assuming that these finite fields are different than the finite > fields that elliptic curve cryptography is based on, the proposed > parameter structure seems sensble to me. Yes, indeed the underlying coefficient finite fields for the EC groups are not based on the same primes as any of the FFDHE groups, and even if some of the primes were the same, these are still independent code points. I'll post a patch before too long. -- Viktor.
Re: [Devel] OpenSSL 3.0 + TLS 1.3 and FFDHE key exchange
Viktor Dukhovni: > [ The devel list majordomo is not doing too well just now, so please > pardon my use of postfix-users instead. ] > > In TLS 1.3 the key exchange parameters, whether elliptic curve (ECDHE or > ECX, where ECX is one of X25519 or X448) or finite-field (FFDHE), are always > from a negotiated list of well-known groups (no ad-hoc key exchange > parameters). > > --- OpenSSL 1.1.1 > > In OpenSSL 1.1.1 the TLS 1.3 implementation supports only EC key exchange > (ECDHE and ECX), the finite-field (FFDHE) groups are available only for TLS > 1.0?1.2. The APIs for configuring FFDHE parameters and ECDHE curves are > separate and setting the supported EC curve list does not affect the choice > of or the availability of FFDHE groups (server-side only). > > When TLS 1.2 is negotiated and "auto" FFDHE group selection is not pre?mpted > by configuring an explicit set of DH parameters (in Postfix that would be > via smtpd_tls_dh1024_param_file), the server selects one of the "standard" > (https://www.rfc-editor.org/rfc/rfc7919#appendix-A) FFDHE groups based on > the configured security level, the strength of the certificate private key, > or else the symmetric cipher. > > --- OpenSSL 3.0 > > OpenSSL 3.0 adds support for FFDHE in TLS 1.3. An SSL_CTX or SSL handle now > has a single "groups" element that stores the combined list of supported EC > and FFDHE code points. The legacy API for setting the EC curve list is now > an alias for setting this combined list. > > This means that applications not tweaked for OpenSSL 3.0 that explicitly set > the EC curve list to just some list of EC curves end up disabling the newly > supported FFDHE groups in TLS 1.3. Whether this is a feature or a bug, it > is certainly not expected. > > --- Postfix > > The default list of EC groups compiled into Postfix 3.7 and later is: > > tls_eecdh_auto_curves = X25519 X448 prime256v1 secp521r1 secp384r1 > > this makes no mention of FFDHE groups, so they remain disabled in TLS > 1.3 even with OpenSSL 3.0 where they are by default supported. > > If we wish to interoperate with hypothetical SMTP servers or clients that > only support FFDHE (perhaps some emergency makes it necessary to disable the > EC groups), we need to ask OpenSSL to instead enable something along the > lines of: > > X25519 X448 prime256v1 secp521r1 secp384r1 ffdhe2048 ffdhe3072 > > [ I'm disinclined to by default enable FFDHE at 4096 bits and up, these > are CPU hogs with no clear security benefit. ] > > But doing this in a backwards-compatible way, that still works for any > users who were brave enough to set "tls_eecdh_auto_curves" expecting > to just limit the EC groups, means that we'll need two parameters with > the below defaults: > > tls_eecdh_auto_curves = X25519 X448 prime256v1 secp521r1 secp384r1 > tls_ffdhe_auto_groups = ffdhe2048 ffdhe3072 > > When Postfix is linked with OpenSSL 3.0, the two lists will be merged > together. > > Any comments or questions? Assuming that these finite fields are different than the finite fields that elliptic curve cryptography is based on, the proposed parameter structure seems sensble to me. [ and sorry about the postfix-devel mishap - we're overdue with the mailing list migration to a new host ] Wietse
[Devel] OpenSSL 3.0 + TLS 1.3 and FFDHE key exchange
[ The devel list majordomo is not doing too well just now, so please pardon my use of postfix-users instead. ] In TLS 1.3 the key exchange parameters, whether elliptic curve (ECDHE or ECX, where ECX is one of X25519 or X448) or finite-field (FFDHE), are always from a negotiated list of well-known groups (no ad-hoc key exchange parameters). --- OpenSSL 1.1.1 In OpenSSL 1.1.1 the TLS 1.3 implementation supports only EC key exchange (ECDHE and ECX), the finite-field (FFDHE) groups are available only for TLS 1.0–1.2. The APIs for configuring FFDHE parameters and ECDHE curves are separate and setting the supported EC curve list does not affect the choice of or the availability of FFDHE groups (server-side only). When TLS 1.2 is negotiated and "auto" FFDHE group selection is not preëmpted by configuring an explicit set of DH parameters (in Postfix that would be via smtpd_tls_dh1024_param_file), the server selects one of the "standard" (https://www.rfc-editor.org/rfc/rfc7919#appendix-A) FFDHE groups based on the configured security level, the strength of the certificate private key, or else the symmetric cipher. --- OpenSSL 3.0 OpenSSL 3.0 adds support for FFDHE in TLS 1.3. An SSL_CTX or SSL handle now has a single "groups" element that stores the combined list of supported EC and FFDHE code points. The legacy API for setting the EC curve list is now an alias for setting this combined list. This means that applications not tweaked for OpenSSL 3.0 that explicitly set the EC curve list to just some list of EC curves end up disabling the newly supported FFDHE groups in TLS 1.3. Whether this is a feature or a bug, it is certainly not expected. --- Postfix The default list of EC groups compiled into Postfix 3.7 and later is: tls_eecdh_auto_curves = X25519 X448 prime256v1 secp521r1 secp384r1 this makes no mention of FFDHE groups, so they remain disabled in TLS 1.3 even with OpenSSL 3.0 where they are by default supported. If we wish to interoperate with hypothetical SMTP servers or clients that only support FFDHE (perhaps some emergency makes it necessary to disable the EC groups), we need to ask OpenSSL to instead enable something along the lines of: X25519 X448 prime256v1 secp521r1 secp384r1 ffdhe2048 ffdhe3072 [ I'm disinclined to by default enable FFDHE at 4096 bits and up, these are CPU hogs with no clear security benefit. ] But doing this in a backwards-compatible way, that still works for any users who were brave enough to set "tls_eecdh_auto_curves" expecting to just limit the EC groups, means that we'll need two parameters with the below defaults: tls_eecdh_auto_curves = X25519 X448 prime256v1 secp521r1 secp384r1 tls_ffdhe_auto_groups = ffdhe2048 ffdhe3072 When Postfix is linked with OpenSSL 3.0, the two lists will be merged together. Any comments or questions? -- Viktor.
Re: Issue with Postfix
Hello, After checks I noticed that I had "1.1.1.1" in my resolv.conf. And that this DNS was specified in my dhcpcd.conf (certainly a mistake on my side). I deleted this entry in dhcpcd.conf and restarted the service. And no more "1.1.1.1" in resolv.conf. I tested to send an email from another server and it works now. GOOD !!! Thank's all for your help. Le 01/01/2023 à 21:38, Shawn Heisey a écrit : On 1/1/23 12:33, Bill Cole wrote: also, private IP ranges should be excluded from checking in DNS lists. Yes, but non sequitur... ... as your server connects to 192.168.1.160, I assume that servers sees your address to be from private range too. Nope, the connecting address is shown in the error message's Spamhaus URL: 172.71.117.8. A Cloudflare address (!) From what I can tell with a little bit of testing, spamhaus is reporting the IP address of the DNS server that contacted the spamhaus RBL. That RBL is not used with an IP address, it is a domain name lookup. Try one of the following commands out on a *NIX system with either "host" or "nslookup" installed. It looks up a TXT record for mehl-family.fr (the OP's sender address domain) on the same RBL the OP uses. The lookup is sent to 1.1.1.1, which is cloudflare's public DNS resolver: host -t TXT mehl-family.fr.dbl.spamhaus.org 1.1.1.1 nslookup -type=TXT mehl-family.fr.dbl.spamhaus.org 1.1.1.1 Unless the Raspberry Pi is located in cloudflare's network, which I suspect is not actually possible for most people, it means that 192.168.1.160 is using cloudflare for DNS. I tried the above commands to 8.8.8.8 instead of 1.1.1.1, and it didn't report "public resolver" which I found a little bit strange. So the OP could probably use 8.8.8.8 and 8.8.4.4 for DNS, but that's not a good idea long term. They really need to install unbound or bind9 on the mailserver and use 127.0.0.1 for DNS. Not sure if this applies or not: It is generally not a good idea to run a public mailserver on a typical home ISP or many small business ISP connections. These networks are very often on public blocklists used all over the Internet, which means that a large percentage of the mail that gets sent by a server in one of these ISP networks will be denied. Thanks, Shawn -- Ce message et toutes les pièces jointes (ci-après le "message") sont établis à l’intention exclusive des destinataires désignés. Il contient des informations confidentielles et pouvant être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de détruire le message. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse de l’émetteur. L'internet ne garantissant pas l'intégrité de ce message lors de son acheminement, l'expéditeur décline toute responsabilité au titre de son contenu. Bien que ce message ait fait l’objet d’un traitement anti-virus lors de son envoi, l’émetteur ne peut garantir l’absence totale de logiciels malveillants dans son contenu et ne pourrait être tenu pour responsable des dommages engendrés par la transmission de l’un d’eux. Pensez environnement ! N’imprimez cet email que si c’est nécessaire. This message and any attachments (the "message") are intended solely for the addressee(s). It contains confidential information, that may be privileged. If you receive this message in error, please notify the sender immediately and delete the message. Any use of the message in violation of its purpose, any dissemination or disclosure, either wholly or partially is strictly prohibited, unless it has been explicitly authorized by the sender. As its integrity cannot be secured on the internet, the sender decline any liability for the content of this message. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Think environment! Print this email only if necessary. --
