Re: use of inet_protocols= option in policy maps?
On 2/3/22 9:28 AM, Viktor Dukhovni wrote:
Multiple transports can use the same policy table:
relay-test4 unix - - n - - smtp
...
-o inet_protocols=ipv4
-o
smtp_tls_policy_maps=${def_db_type}:${conf_dir}/test/relay_tls_policy
relay-test6 unix - - n - - smtp
...
-o inet_protocols=ipv6
-o
smtp_tls_policy_maps=${def_db_type}:${conf_dir}/test/relay_tls_policy
clean & simple. thx!
Re: Add a disclaimer for all senders
I checked the logs again and I can't see any error message "warning"
"error" "fatal" "panic".
For testing, my disclaimer script just write something in /tmp/file.
On master.cf I have this:
smtp inet n - y - 1 postscreen
-o content_filter=disclaimer:
[...]
disclaimer unix - n n - - pipe
flags=Rq user=filter argv=/etc/postfix/disclaimer -f ${sender} -d
${recipient}
When I send an email it looks like that disclaimer script is not running.
Le 03/02/2022 à 19:35, Wietse Venema a écrit :
Wietse Venema:
Look in your LOGS.
http://www.postfix.org/DEBUG_README.html#logging
In particular, logs that the message is handled by your filter,
to eliiminate basic mistakes.
Wietse
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 usually
called /var/log/maillog, /var/log/mail, or something similar; the
exact pathname is configured in a file called /etc/syslog.conf,
/etc/rsyslog.conf, or something similar.
When Postfix uses its own logging system (see MAILLOG_README), the
location of the logfile is configured with the Postfix maillog_file
parameter.
When Postfix does not receive or deliver mail, the first order of
business is to look for errors that prevent Postfix from working
properly:
% egrep '(warning|error|fatal|panic):' /some/log/file | more
Note: the most important message is near the BEGINNING of the output.
Error messages that come later are less useful.
The nature of each problem is indicated as follows:
- "panic" indicates a problem in the software itself that only a
programmer can fix. Postfix cannot proceed until this is fixed.
- "fatal" is the result of missing files, incorrect permissions,
incorrect configuration file settings that you can fix. Postfix
cannot proceed until this is fixed.
- "error" reports an error condition. For safety reasons, a Postfix
process will terminate when more than 13 of these happen.
- "warning" indicates a non-fatal error. These are problems that
you may not be able to fix (such as a broken DNS server elsewhere
on the network) but may also indicate local configuration errors
that could become a problem later.
--
Cordialement,
Philippe - Forums
Re: Add a disclaimer for all senders
> =On 4 Feb 2022, at 8:39 am, Forums wrote: > > smtp inet n - y - 1 postscreen > -o content_filter=disclaimer: The postscreen(8) program does not implement content filters. That setting should be for smtpd(8). -- Viktor.
Re: Add a disclaimer for all senders
Using "smtpd" instead of "postscreen" doesn't change issue. Le 04/02/2022 à 14:59, Viktor Dukhovni a écrit : =On 4 Feb 2022, at 8:39 am, Forums wrote: smtp inet n - y - 1 postscreen -o content_filter=disclaimer: The postscreen(8) program does not implement content filters. That setting should be for smtpd(8). -- Cordialement, Philippe - Forums
Re: Add a disclaimer for all senders
> On 4 Feb 2022, at 9:05 am, Forums wrote: > > Using "smtpd" instead of "postscreen" doesn't change issue. You'll have to back up that claim with: # postfix reload ... submission of a new message via TCP port 25 ... ... logs showing that message entering and leaving the queue ... ... unmangled (verbatim whitespace and newlines) output of: $ postconf -nf $ postconf -Mf When a content_filter is set for smtpd(8), it is used. Any observations to the contrary are user errors. -- Viktor.
Using pkcs11 instead of plaintext certificates
Hello list, Would anyone know if it is possible to configure pkcs11 as a signature source for TLS encryption in postfix? My concrete use-case would be to enable the use of Nitro Enclaves and native certificate management in AWS, but it would apply to just about any hardware security module as well. The benefits of not exposing the private key seem obvious, but I could not find anything related on the net. Thanks, Tobias
Re: Using pkcs11 instead of plaintext certificates
On Fri, Feb 04, 2022 at 03:10:41PM +0100, Tobias Meyer wrote: > Would anyone know if it is possible to configure pkcs11 as a signature > source for TLS encryption in postfix? Sorry, only PEM files are supported (for SNI the base64 encoded content the file may need to be copied into a database table via "postmap -F"). Support for PKCS#11 is not presently available. -- Viktor.
Re: Using pkcs11 instead of plaintext certificates
> > Sorry, only PEM files are supported (for SNI the base64 encoded content > the file may need to be copied into a database table via "postmap -F"). > > Support for PKCS#11 is not presently available. > > Hello Viktor, Thanks for your prompt reply. Since openssl already supports pkcs#11 and postfix uses openssl, do you think adding support might be a task someone with a little c/c++ background and a solid, but not expert, understanding of PKI could tackle, or would you recommend against that? Alternatively, would this be the place to ask for a feature request? :) -- Tobias
Re: Using pkcs11 instead of plaintext certificates
On Fri, Feb 04, 2022 at 04:06:10PM +0100, Tobias Meyer wrote: > > Sorry, only PEM files are supported (for SNI the base64 encoded content > > the file may need to be copied into a database table via "postmap -F"). > > > > Support for PKCS#11 is not presently available. > > Since OpenSSL already supports PKCS#11 and Postfix uses OpenSSL, do > you think adding support might be a task someone with a little C/C++ > background and a solid, but not expert, understanding of PKI could > tackle, or would you recommend against that? There are some non-obvious interface design obstacles. How does PKCS#11 work in chroot jails? In processes that drop privileges? What is the interface to SNI? How does PKCS#11 play with the new "chain_files" interface to specifying key+certs? Loading a PKCS#11 provider is different in OpenSSL 3.0 vs 1.1.1, and would probably require implementing a Postfix interface to loading custom "openssl.cnf" files, and perhaps delegating some additional configuration settings to OpenSSL that are presently managed explicitly in Postfix. So I don't think this is a straightforward project. > Alternatively, would this be the place to ask for a feature request? :) Sure, but this is unlikely to get immediate attention. For now just plan to rotate keys often enough for absence of an HSM to not matter. That is, avoid the traditional one year or longer certificates, and roll certificates every 90 days or less. A PEM key file is good enough in practice for all but the most valuable keys. Unless you're running a public CA, or a corporate CA issuing credentials with "keys to the kingdom", or must use the same key for years, an HSM is generally overkill. -- Viktor.
Re: Using pkcs11 instead of plaintext certificates
On Fri, Feb 4, 2022 at 4:57 PM Viktor Dukhovni wrote: > On Fri, Feb 04, 2022 at 04:06:10PM +0100, Tobias Meyer wrote: > > > Since OpenSSL already supports PKCS#11 and Postfix uses OpenSSL, do > > you think adding support might be a task someone with a little C/C++ > > background and a solid, but not expert, understanding of PKI could > > tackle, or would you recommend against that? > > There are some non-obvious interface design obstacles. How does PKCS#11 > work in chroot jails? In processes that drop privileges? What is the > interface to SNI? How does PKCS#11 play with the new "chain_files" > interface to specifying key+certs? > > Loading a PKCS#11 provider is different in OpenSSL 3.0 vs 1.1.1, and > would probably require implementing a Postfix interface to loading > custom "openssl.cnf" files, and perhaps delegating some additional > configuration settings to OpenSSL that are presently managed explicitly > in Postfix. > > So I don't think this is a straightforward project. > > Thank you, these were the kind of in-depth insights I am missing, but was sort of anticipating. > > Alternatively, would this be the place to ask for a feature request? :) > > Sure, but this is unlikely to get immediate attention. For now just > plan to rotate keys often enough for absence of an HSM to not matter. > > That is, avoid the traditional one year or longer certificates, and roll > certificates every 90 days or less. A PEM key file is good enough in > practice for all but the most valuable keys. > > Unless you're running a public CA, or a corporate CA issuing credentials > with "keys to the kingdom", or must use the same key for years, an HSM > is generally overkill. > I agree, a HSM ist possibly overkill for most applications, but with AWS you have the possibility to use automatic certificate renewal if you use their native services. And it behaves just as a HSM to your VM in my understanding. But of course that can be scripted in other ways as well, I guess I'll go that route. Thanks again for your insights, they were most helpful. Tobias
Re: Add a disclaimer for all senders
On 4 Feb 2022, at 9:05 am, Forums wrote: Using "smtpd" instead of "postscreen" doesn't change issue. On 04.02.22 09:09, Viktor Dukhovni wrote: You'll have to back up that claim with: # postfix reload ... submission of a new message via TCP port 25 ... ... logs showing that message entering and leaving the queue ... ... unmangled (verbatim whitespace and newlines) output of: $ postconf -nf $ postconf -Mf When a content_filter is set for smtpd(8), it is used. it may be overriden by other FILTER: directive in any of access lists. also, it may misbehave. Any observations to the contrary are user errors. -- 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. It's now safe to throw off your computer.
Multi-instance and outbound fails SPF
Hi, I have a multi-instance postfix config and am trying to figure out why Microsoft 365 is marking my email from the outbound instance as SPF softfail. I am trying to send mail from my gmail account to the multi-instance postfix system through to my Microsoft 365 account, where I've set up mail filters to accept mail from all postfix instances without blocking or filtering. All IPs involved are listed in the SPF record for the domain: example.org.978 IN TXT "v=spf1 ip4:209.222.90.0/24 include:spf.protection.outlook.com -all" There are two MX records set for this domain - relay1.example.com (209.222.90.118) and relay2.example.com (209.222.90.113). I believe the problem is that mail is leaving through the postfix-out instance (209.222.90.109), and although all IPs are listed in the SPF record, it appears Microsoft doesn't like that it's not being sent from the same IP as it was received? I suppose my question is why is SPF failing when the sending IP is included in the SPF record? Should I be thinking about a postfix config change here, or is this inherent to SPF? I've also set up DKIM and it is correctly signing the outgoing message, it appears. I believe this is the relevant info from the mail headers after it's received on my Microsoft 365 account: Received: from MW2NAM12FT043.eop-nam12.prod.protection.outlook.com (2603:10b6:300:81:cafe::10) by MWHPR14CA0068.outlook.office365.com (2603:10b6:300:81::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12 via Frontend Transport; Fri, 4 Feb 2022 18:18:44 + Authentication-Results: spf=softfail (sender IP is 209.222.90.109) smtp.mailfrom=gmail.com; dkim=pass (signature was verified) header.d=gmail.com;dmarc=pass action=none header.from=gmail.com;compauth=pass reason=100 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning gmail.com discourages use of 209.222.90.109 as permitted sender) Received: from armor.example.com (209.222.90.109) by MW2NAM12FT043.mail.protection.outlook.com (10.13.180.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.5 via Frontend Transport; Fri, 4 Feb 2022 18:18:43 + Received: from localhost (localhost [127.0.0.1]) by armor.example.com (Postfix) with ESMTP id AAF593A448A; Fri, 4 Feb 2022 13:18:42 -0500 (EST) Authentication-Results-Original: armor.example.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from iceman.example.com ([209.222.90.113]) by localhost (armor.example.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQI7eXvdPtSt; Fri, 4 Feb 2022 13:18:39 -0500 (EST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.218.50; helo=mail-ej1-f50.google.com; envelope-from=exam...@gmail.com; receiver= X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by iceman.example.com (Postfix) with ESMTPS id D5356600025CF for ; Fri, 4 Feb 2022 13:18:39 -0500 (EST) Received: by mail-ej1-f50.google.com with SMTP id j2so21487350ejk.6 for ; Fri, 04 Feb 2022 10:18:39 -0800 (PST)
Re: Multi-instance and outbound fails SPF
Alex: > Hi, > I have a multi-instance postfix config and am trying to figure out why > Microsoft 365 is marking my email from the outbound instance as SPF > softfail. > > I am trying to send mail from my gmail account to the multi-instance > postfix system through to my Microsoft 365 account, where I've set up > mail filters to accept mail from all postfix instances without > blocking or filtering. All IPs involved are listed in the SPF record > for the domain: > > example.org.978 IN TXT "v=spf1 > ip4:209.222.90.0/24 include:spf.protection.outlook.com -all" > > There are two MX records set for this domain - relay1.example.com > (209.222.90.118) and relay2.example.com (209.222.90.113). I believe > the problem is that mail is leaving through the postfix-out instance > (209.222.90.109), and although all IPs are listed in the SPF record, > it appears Microsoft doesn't like that it's not being sent from the > same IP as it was received? Random guess: what name does the MTA send in the EHLO command, and does that name match the IP address? The EHLO is not visible in the email headers that you included. Wietse
Re: Multi-instance and outbound fails SPF
On Friday, February 4, 2022 3:14:29 PM EST Wietse Venema wrote: > Alex: > > Hi, > > I have a multi-instance postfix config and am trying to figure out why > > Microsoft 365 is marking my email from the outbound instance as SPF > > softfail. > > > > I am trying to send mail from my gmail account to the multi-instance > > postfix system through to my Microsoft 365 account, where I've set up > > mail filters to accept mail from all postfix instances without > > blocking or filtering. All IPs involved are listed in the SPF record > > for the domain: > > > > example.org.978 IN TXT "v=spf1 > > ip4:209.222.90.0/24 include:spf.protection.outlook.com -all" > > > > There are two MX records set for this domain - relay1.example.com > > (209.222.90.118) and relay2.example.com (209.222.90.113). I believe > > the problem is that mail is leaving through the postfix-out instance > > (209.222.90.109), and although all IPs are listed in the SPF record, > > it appears Microsoft doesn't like that it's not being sent from the > > same IP as it was received? > > Random guess: what name does the MTA send in the EHLO command, and > does that name match the IP address? The EHLO is not visible in the > email headers that you included. Failed HELO check for SPF is indeed a possibility. Another one is that their check is buggy. I have seen cases of them checking SPF when receiving mail via an internal relay. I don't know how common that is. If it's on their end, there's not much you can do about it. Scott K
Re: Multi-instance and outbound fails SPF
On Fri, Feb 04, 2022 at 02:34:35PM -0500, Alex wrote: > I have a multi-instance postfix config and am trying to figure out why > Microsoft 365 is marking my email from the outbound instance as SPF > softfail. Because you're forwarding email received from an external domain, and it is *that* (envelope sender) domain's SPF records that count, not yours. > Authentication-Results: spf=softfail (sender IP is 209.222.90.109) > smtp.mailfrom=gmail.com; dkim=pass (signature was verified) > header.d=gmail.com;dmarc=pass action=none header.from=gmail.com;compauth=pass > reason=100 Unless you're "google.com", or "google.com" lists your IPs in its SPF records, SPF is *supposed* to fail. This is why DKIM was invented, it survives simple verbatim forwarding. -- Viktor.
ipv6 only postfix server
I have an ipv6 only server running postfix. Mailing to and from an ipv6 server is no problem. BUT: How to mail to an ipv4 only server? Which options do I have? Gr., Jack Raats
Re: ipv6 only postfix server
--- Original Message --- On Friday, February 4th, 2022 at 20:48, Jack Raats wrote: > > BUT: > > How to mail to an ipv4 only server? > > Which options do I have? > > Gr., > > Jack Raats That's really a question for your ISP to answer. ;-) Basically there needs to be a gateway somewhere, either locally (if you have some IPv4) or on your ISP side (if you don't). IPv6 and IPv4 are completely separate beasts, middleware "somewhere" to enable the two to talk is a requirement.
ADDRESS_VERIFICATION_README
If i missed this answer on the docs im sorry. In using address verification it is very clear that any "reject" from the remote mail server would result in the email triggering the verification to be rejected. But i do not see anything about 4xx defer responses. What if the remote server is doing gray listing and responds with a 4xx during the probe process? How does postfix handle this? Does it also give the email triggering the verification a 4xx or rejects it with a 5xx?
Re: ADDRESS_VERIFICATION_README
On Fri, Feb 04, 2022 at 04:16:47PM -0500, post...@ptld.com wrote: > In using address verification it is very clear that any "reject" from > the remote mail server would result in the email triggering the > verification to be rejected. But i do not see anything about 4xx defer > responses. What if the remote server is doing gray listing and > responds with a 4xx during the probe process? > > How does postfix handle this? Does it also give the email triggering > the verification a 4xx or rejects it with a 5xx? Postfix does the only right thing. -- Viktor.
Re: ADDRESS_VERIFICATION_README
On 02-04-2022 4:19 pm, Viktor Dukhovni wrote: > On Fri, Feb 04, 2022 at 04:16:47PM -0500, post...@ptld.com wrote: > >> In using address verification it is very clear that any "reject" from >> the remote mail server would result in the email triggering the >> verification to be rejected. But i do not see anything about 4xx defer >> responses. What if the remote server is doing gray listing and >> responds with a 4xx during the probe process? >> >> How does postfix handle this? Does it also give the email triggering >> the verification a 4xx or rejects it with a 5xx? > > Postfix does the only right thing. That is a confusing response. It almost reads like a joke but Viktor never jokes. Which is the "right thing"?
Re: ipv6 only postfix server
Op 04-02-2022 om 21:57 schreef Laura Smith: --- Original Message --- On Friday, February 4th, 2022 at 20:48, Jack Raats wrote: BUT: How to mail to an ipv4 only server? Which options do I have? Gr., Jack Raats That's really a question for your ISP to answer. ;-) Basically there needs to be a gateway somewhere, either locally (if you have some IPv4) or on your ISP side (if you don't). IPv6 and IPv4 are completely separate beasts, middleware "somewhere" to enable the two to talk is a requirement. At this moment I've solved the problem using a relayhost, which has ipv4 and ipv6. I also added this relayhost to the SPF record of the domain. Question: Is it possible to send mail directly to an ipv6 and ipv4 (all) mailserver and using the relayhost for an ipv4 only mailserver? Gr., Jack Raats
Re: ADDRESS_VERIFICATION_README
post...@ptld.com: > On 02-04-2022 4:19 pm, Viktor Dukhovni wrote: > > On Fri, Feb 04, 2022 at 04:16:47PM -0500, post...@ptld.com wrote: > > > >> In using address verification it is very clear that any "reject" from > >> the remote mail server would result in the email triggering the > >> verification to be rejected. But i do not see anything about 4xx defer > >> responses. What if the remote server is doing gray listing and > >> responds with a 4xx during the probe process? > >> > >> How does postfix handle this? Does it also give the email triggering > >> the verification a 4xx or rejects it with a 5xx? > > > > Postfix does the only right thing. > > > That is a confusing response. It almost reads like a joke but Viktor never > jokes. > Which is the "right thing"? Postfix replies with a hard reject when the probe fails with a permanent error, otherwise Postfix replies with a soft reject. Wietse
Re: ipv6 only postfix server
Jack Raats: > Is it possible to send mail directly to an ipv6 and ipv4 (all) > mailserver and using the relayhost? for an ipv4 only mailserver? Use smtp_fallback_relay. Wietse
Re: ipv6 only postfix server
On 2022-02-04 21:48, Jack Raats wrote: I have an ipv6 only server running postfix. Mailing to and from an ipv6 server is no problem. BUT: How to mail to an ipv4 only server? Which options do I have? ipv10 is the only one to wait for https://datatracker.ietf.org/doc/html/draft-omar-ipv10-06.html how it will break ssl/tls or not is maybe another question
Re: ipv6 only postfix server
> On 4 Feb 2022, at 5:58 pm, Benny Pedersen wrote: > > On 2022-02-04 21:48, Jack Raats wrote: >> I have an ipv6 only server running postfix. Mailing to and from an >> ipv6 server is no problem. >> BUT: >> How to mail to an ipv4 only server? >> Which options do I have? > > ipv10 is the only one to wait for > > how it will break ssl/tls or not is maybe another question Let's not drag "ipv10" into this forum, it has fouled the air in enough IETF mailing lists. It is not going to happen, and should not waste anyone's time here... -- Viktor.
Re: Multi-instance and outbound fails SPF
Hi,
> > I have a multi-instance postfix config and am trying to figure out why
> > Microsoft 365 is marking my email from the outbound instance as SPF
> > softfail.
>
> Because you're forwarding email received from an external domain,
> and it is *that* (envelope sender) domain's SPF records that count,
> not yours.
Oh yes, I also thought that may have been a possibility, thanks.
> > Authentication-Results: spf=softfail (sender IP is 209.222.90.109)
> > smtp.mailfrom=gmail.com; dkim=pass (signature was verified)
> > header.d=gmail.com;dmarc=pass action=none
> > header.from=gmail.com;compauth=pass
> > reason=100
>
> Unless you're "google.com", or "google.com" lists your IPs in its SPF
> records, SPF is *supposed* to fail. This is why DKIM was invented, it
> survives simple verbatim forwarding.
So signing my message as it leaves my server is the right approach, or
are you referring to Gmail signing the mail as it's sent from their
server originally?
This problem has apparently been all over the internet for years, so I
don't think it's an unintentional bug by Microsoft.
https://answers.microsoft.com/en-us/msoffice/forum/all/routing-to-exchange-online-results-in-spf-softfail/367e14ac-a3ce-46a2-8949-ffbc8f66edc7
It doesn't look like the EHLO from my server is recorded anywhere in
the email headers, but it does hit on SPF_HELO_NONE from spamassassin,
apparently from Gmail:
Received-SPF: Pass (mailfrom) identity=mailfrom;
client-ip=209.85.208.49; helo=mail-ed1-f49.google.com;
envelope-from=mysqlstud...@gmail.com; receiver=
Would $smtp_helo_name apply here? The postfix instance is processing
mail for a number of domains, so if so, I'm unsure how I would set it
other than the $myhostname default.
I've also added SPF records to each host to include itself ("v=spf1 a
-all"). But is it even necessary, considering no mail actually
originates on this server?
Re: Multi-instance and outbound fails SPF
On Fri, Feb 04, 2022 at 08:16:49PM -0500, Alex wrote: > > Unless you're "google.com", or "google.com" lists your IPs in its SPF > > records, SPF is *supposed* to fail. This is why DKIM was invented, it > > survives simple verbatim forwarding. > > So signing my message as it leaves my server is the right approach, or > are you referring to Gmail signing the mail as it's sent from their > server originally? The message originated from Google, they DKIM signed it. There's little reason for you to sign it, unless you're modifying the message and take responsibility for its content. > This problem has apparently been all over the internet for years, so I > don't think it's an unintentional bug by Microsoft. > https://answers.microsoft.com/en-us/msoffice/forum/all/routing-to-exchange-online-results-in-spf-softfail/367e14ac-a3ce-46a2-8949-ffbc8f66edc7 If you're the primary MX operator for your own domain, and forwarding to Microsoft for actual mailbox hosting, your forwarding arrangement to Microsoft should be via some dedicated authenticated (or at least IP- restricted) channel, where Microsoft does not apply any SPF or DKIM checks, they should trust your server as authorised to forward mail into your users' mailboxes. Just relaying externally originated content to their public port 25 service is not a good idea. > Would $smtp_helo_name apply here? The postfix instance is processing > mail for a number of domains, so if so, I'm unsure how I would set it > other than the $myhostname default. You're barking up the wrong tree... SPF is key of the envelope sender, which isn't your domain. The real problem is not failing SPF, it is sending to Microsoft in a manner than has them doing any SPF or DKIM checks at all. -- Viktor.
