Re: How to reject generic FCrDNS clients
On 11/11/21 10:28 AM, Bill Cole wrote: > On 2021-11-11 at 06:06:45 UTC-0500 (Thu, 11 Nov 2021 12:06:45 +0100) > Togan Muftuoglu > is rumored to have said: > >> Hi, >> >> How can I reject connections from generic Forward Confirmed Reverse >> DNS >> (FCrDNS) like “123-45-67-8.your.isp.com”. >> >> >> For the most cases spamhaus is able to block it but with the cloud >> providers >> with FCrDNS as follows not all of them are not blocked. >> >> 123-45-67-89.ip.linodeusercontent.com >> >> ec2-12-34-56-789.us-west-2.compute.amazonaws.com >> >> >> How can I reject these connections > > The canonical answer is "check_client_access with a pcre table" but if > you want something comprehensive that you don't need to actively manage > yourself you should consider the "Enemies List" service: > http://enemieslist.com. They use a rich set of non-obvious name patterns > and important exceptions. You likely do NOT want to arbitrarily reject > all mail from all hosts with programmatically IP-derived names, unless > you are intending to engage in a secondary boycott of major mail service > providers' (e.g. Microsoft) customers. > > (and no, I'm not affiliated with them in any way.) Do all of the major mail service providers have valid DMARC? If so, one approach would be to reject (or, more likely, quarantine) mail from such hosts *unless* DMARC matches. That would require an external tool, though. Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: After network outage postfix found not running
On 12/22/21 8:26 PM, Bob Proulx wrote: > Everything is good so no stress about anything here but I am poking at > the log files with a stick after a strange incident. Perhaps this > tripped over some problem that discussing it might either enlighten me > or perhaps unlikely improve things. Who knows? > > The GNU Savannah software forge had a network outage in the data > center lasting about eight hours. It was the dark of the night and > things were fixed quickly once the admins woke up at sunrise and went > to the data center to fix things. Due to the timing this was an > unusually long network outage event. > > I would like to describe four of the VMs of interest here. Two were > okay after networking returned. But two were found afterward without > postfix running. I am curious if the why is somehow useful or > interesting to know. > > All of the systems have their root block storage on a ceph network > attached storage pool. Which of course meant that the root file > system was unavailable for the full time of the eight hour outage. > Therefore if some bit of file data is cached and not expired then the > Linux kernel can service the request. If not and if it needs to read > the data then it attempts a network read and of course blocks waiting > for network I/O. > > Of course cron jobs were still running. And stacking up processes > blocked on I/O waiting. One server achieved a load average of 520 and > was perfectly fine recovering after networking was restored. Another > reached a load of 68 but afterward the postfix daemons were found to > be not running. In summary: Two of the four had no discernible > failures. Two of the four were found with postfix not running > afterward. Postfix seems to have been the only noticed failure. > Which I found rather unusual. And perhaps noteworthy. But this is a > very unusual situation where the root file system is unavailable for > an extended period of time. > > I am simply reviewing things afterward now. Trying to understand and > perhaps improve things. Since two of them failed. But again there is > no stress here. Everything is all good now. And this is a highly > unusual system event. Because those two were found without postfix > running I rebooted all of the servers subsequently as a preventative > maintenance action. Even though others seemed perfectly okay > afterward. Because almost certainly there would be other as yet not > found problems. > > Any ideas on why postfix would not be running after such an event on > two of the systems but okay on the others? > > Bob My intuition is that either some timeout somewhere got hit, or that some I/O failed (rather than being queued forever) and caused an error paging in some code. That would cause Postfix to die with SIGBUS. Do you have Postfix set to automatically be restarted if it crashes? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: https://www.postfix.org/ in trouble
On 1/3/22 09:08, Alexey Shpakovsky wrote: > On Mon, January 3, 2022 14:48, Jaap van Wingerde wrote: >> All the urls on https://www.postfix.org give an 'Not found'error, and a >> 'SSL_ERROR_BAD_CERT_DOMAIN' error. >> > > try plaintext http: http://www.postfix.org/ currently works for me. Browsers are starting to deprecate that, though. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Default TLS protocols
On 1/10/22 07:23, Viktor Dukhovni wrote: > On Mon, Jan 10, 2022 at 12:50:49PM +0100, Kveta Kladov wrote: > >> RFC 8996 deprecated TLS 1.0 and TLS 1.1 . >> >> Would you consider to update default values for >> >> smtp_tls_mandatory_protocols >> smtp_tls_protocols, >> smtpd_tls_mandatory_protocols >> smtpd_tls_protocols >> >> so that TLS 1.0 and TLS 1.1 are disabled by default ? > > There's no clear benefit to doing this with opportunistic TLS in SMTP. For opportunistic TLS, I mostly agree. I say “mostly” because disabling legacy protocols will reduce OpenSSL’s attack surface. However, if DANE, MTA-STS, or certificate verification is in use, then TLS 1.0 and TLS 1.1 should be disabled, as Postfix will fail closed in that case. The same is true for SMTPS and submission with mandatory STARTTLS. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: TLS enforcement options?
On 1/10/22 07:02, Jaroslaw Rafa wrote: > Dnia 10.01.2022 o godz. 09:35:49 Joachim Lindenberg pisze: >> Are you also not using a trusted certificate or even no certificate for >> your public web site? > > Did you notice the recent thread on this list about http://www.postfix.org > website (NOT https) where Viktor and others explained why there is no need > for the site to use HTTPS, as all the content is public and no private data > is processed by the site? TLS not only provides confidentiality, it also provides integrity — and integrity *does* matter. Furthermore, both Google and Mozilla have declared insecure HTTP to be deprecated. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: How can I build a reliable distribution list?
On 1/13/22 10:36, Benny Pedersen wrote: > On 2022-01-13 15:54, Michael Orlitzky wrote: > >> In short, you have to choose a mailing list package that is aware of >> the issues and can work around them, like the 3.x series of GNU >> Mailman. And then you have to configure it very carefully. > > what if mailman did not accept subscribers with dmarc policy reject ? That is not a good idea. You may lose legitimate subscribers this way. Use a mailing list package that can handle header-from rewriting. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Should that behaviour be like this?
On 1/20/22 08:13, Wietse Venema wrote: > tobs...@brain-force.ch: >> Today we stumbled over a postfix behaviour that was quite unexpected >> for us. >> >> we had in main.cf >> >> >> smtpd_client_restrictions = >>check_helo_access >> pcre:/etc/postfix/helo_access.pcre,regexp:/etc/postfix/helo_access.rege > > Commas and spaces are treated identically, therefore > this is equivalent to: > > smtpd_client_restrictions = > check_helo_access pcre:/etc/postfix/helo_access.pcre > regexp:/etc/postfix/helo_access.regex > > The syntax on the last line was deprecated, and was removed from > the manpage. For backwards compatibility, if you omit the > check_xxx_access before a table, then the kind of access is determined > by the smtpd_xxx_restrictions type. > > Therefore the above is equivalent to: > > smtpd_client_restrictions = > check_helo_access pcre:/etc/postfix/helo_access.pcre > check_client_access regexp:/etc/postfix/helo_access.regex > > Wietse Would it be possible for Postfix to issue a warning for such deprecated syntax? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Postfix high traffic (max proc) considerations
On 2/7/22 10:00, Wietse Venema wrote: > V?ctor Rubiella Monfort: >> Hello, >> >> I'm was reading http://www.postfix.org/TUNING_README.html about increase >> number of process configurations related. >> >> We can increase smtp easly to 1000 connections for example to allow >> multiple incoming connections. But what about pickup and qmsg processes? >> by default is configuret to 1 process. > > Not only by default; these programs will actually abort when you > change the limit. Likewise, some services such as cleanup require > no hard limit. > > However, increasing the number of processes only improves performce > up to the point that the OS kernel can no longer provide resources > to all those running processes. To what extend is Postfix’s process-per-connection architecture a limitation here? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: canonical_maps vs. *_recipient_maps
On 2/18/22 12:20, Wietse Venema wrote: > Jaroslaw Rafa: >> Dnia 18.02.2022 o godz. 11:17:13 Wietse Venema pisze: >>> Starting to wonder if reject_unverified_recipient should be given >>> more publicity. >> >> Definitely should. I always thought of reject_unverified_recipient only in >> context of a front-end server relaying mail to the final server, which is a >> pretty rare case for me (I usually work with single-server setups). I did >> not think that it can be used in such context as rewriting by canonical >> maps. > > Upon closer reading, address verification has limits some of > which are intentional. > > Address verification will validate addresses that result from > canonical mappings and of 1-to-1 virtual aliases. > > Address verification will not validate addresses that result from > the expansion of 1-to-many virtual aliases. It will just report > that the address before alias expansion is valid. > > It does not validate 1-to-many expansions because that would result > in an explosive behavior, because the result would ambiguous if > some addresses in the expansion result are valid and some not, and > because it could be undesirable to reveal what 1-to-many aliases > expand into. > > Address verification will also not validate addresses that result > from local aliasing/forwarding with alias_maps or ~/.forward files, > because I was too lazy to write code that determines if these are > 1-to-1 or 1-to-many, but also because it might reveal too much > information. It will just report that the address before alias > expansion or forwarding is valid. > > Wietse Is reject_unverified_recipient the correct approach for a standard Postfix/Dovecot setup? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Is it possible to send email by copying a file or files to an appropriate queue directory?
On 3/22/22 11:27, João Silva wrote: > > On 22/03/2022 14:57, Edward Sandberg wrote: >> You could use inotify to monitor a directory and trigger a script to >> send the mail. >> >> Here is a very simple example content of such an email file, but they >> get much more complex. >> >> To: f...@bar.com >> From: b...@foo.com >> Subject: example email >> >> Hello World! >> >> If the files are valid email files with headers you could just pipe >> them to sendmail. >> >> If the files are not valid emails with headers then you could send >> them as attachments. Something like the python module envelope would >> be a simple way to do this: https://pypi.org/project/envelope/ > > The following code (function) takes a bytesIO object and attaches it to > an email. > > A warning about inotify and python, if the rate of writing new files to > a directory is too high python may not keep up to it there are events > that may be "lost". I have found it the hard way. This is not specific to Python. It’s a general limitation of the inotify interface, and is necessary to avoid a trivial denial of service by being slow to consume events. Inotify does tell you when events have been lost, though, which allows you to resynchronize. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: DMARC in postfix ?
On 4/12/22 23:31, John Levine wrote: > For doing DMARC validation, I know about the opendmarc milter. Is that what > everyone uses? Is there anything else used in pratice? > > I know about perl and python libraries but they don't seem to have > milters or other ready to use integrations into MTAs. > > TIA, > John I’m curious if DMARC, ARC, and other features should be supported in Postfix natively. I believe pretty much any Internet-facing MTA that isn’t a null client needs them, and Exim has native support for at least some of them. I also trust that if it is in Postfix, it will be implemented properly. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Rewriting envelope-from of root mail (realname, not email address)
On 4/23/22 09:47, Rob McGee wrote: > On 2022-04-22 22:53, Viktor Dukhovni wrote: >> On Fri, Apr 22, 2022 at 06:54:56PM -0700, Dan Mahoney wrote: >>> We *also* recently set sp=reject in dmarc. Which presents us with a >>> problem. >> >> I have no advice re DMARC, never have or will use it. > > Which indeed IS a word of advice. :) And a bad one. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: password security
On 4/26/22 01:35, Antonio Leding wrote: > Anyone who thinks that F2B merely “quiets logs” unfortunately has no > idea what F2B actually does… Would you mind explaining? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: password security
On 4/27/22 07:58, Michael Ströder wrote: > On 4/27/22 12:27, Jaroslaw Rafa wrote: >> Dnia 27.04.2022 o godz. 17:47:06 AndrewHardy pisze: >>> >>> I’m very interested in what options / solutions (if any) exist that allow >>> you to use a passwordless approach to authenticating your users against >>> imaps/pop3/smtps/submission services (tls encrypted of course) >> >> To my knowledge, Thunderbird supports certificate-based authentication both >> to imaps and smtps/submission. On the server side, you can probably configure >> certificate-based authentication in most mail server software, in particular >> in Postfix and Dovecot. > > Configuring it on the server-side is fairly easy. > > The hard part is enrolling client certs for end-users, especially into > Thunderbird. > > Mozilla hunked out all features for PKI client cert enrollment from > Firefox and Thunderbird. So today it's easier to issue client certs to > Outlook users than to Thunderbird users. :-( > > Ciao, Michael. Please report a bug on https://bugzilla.mozilla.org as this is a problem with Thunderbird. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: password security
On 4/27/22 08:37, Jahnke-Zumbusch, Dirk wrote: > Hi everybody, > >>>> I’m very interested in what options / solutions (if any) exist that allow >>>> you to use a passwordless approach to authenticating your users against >>>> imaps/pop3/smtps/submission services (tls encrypted of course) > > one way to authenticate may be using Kerberos. Get your > K5-Ticket-Granting-Ticket at your Kerberos server, > yes: using username password, and then use this ticket > during the next hours to authenticate against properly > configured servers (Dovecot, Apache, ...). May be this > is a hint into the direction of what might help you. > > Cheers, Dirk. Please enable channel binding if you go with this route. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: password security
On 4/27/22 12:27, Michael Ströder wrote: > On 4/27/22 14:37, Jahnke-Zumbusch, Dirk wrote: >>>>> I’m very interested in what options / solutions (if any) exist that allow >>>>> you to use a passwordless approach to authenticating your users against >>>>> imaps/pop3/smtps/submission services (tls encrypted of course) >> >> one way to authenticate may be using Kerberos. > > Not recommended for roaming users accessing submission service via > public Internet. > > Ciao, Michael. Hard disagree; Kerberos is safe for use over the Internet. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: password security
On 4/27/22 14:01, Wietse Venema wrote: > Michael Stroeder: >>> Either way a compromised CA or a compromise KDC is bad news... >> >> Yes! >> >> And one of my biggest concerns are bad operational practices. That's why >> admins should not have to manually deal with crypto key files like >> service keytabs or TLS server keys. > > To implement strong (network) security, some system will have to > keep some secret somewhere. Few people can afford operating an HSM > (hardware security module), what are the remaining options. > > Wietse TPM-backed storage might work, but I suspect it is too slow in practice. One could use TPM-based disk encryption though. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Documentation Edit Request - smtpd_reject_unlisted_recipient
On 5/11/22 11:56, Wietse Venema wrote: > James Feeney: >> Then, leaving out the DeMorgan transform, and beginning again with >> your original format, how about: > > Please do not reply to the list AND my address. > > The pseudocode is incomplete. Condition 2.i) matches the recipient > address against an unspecified table. > > The implementation matches the recipient domain (to determine the > address class) before matching the recipient address against the > valid recipient table for that specific addres class. This avoids > unnecessary recipient address lookups, which is good for reliability. > > The documentation is consistent with this behavior. > > I think that replacing the documentation with (correct) pseudocode > would not be an improvement. Humans are not machines. I agree, but including correct pseudocode could be useful as well. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: What is happening here? (TLS Library Problem)
On 6/10/22 08:55, Gerben Wierda wrote: > >> On 10 Jun 2022, at 13:17, Wietse Venema wrote: >> >> Wietse Venema: >>> Gerben Wierda: >>>> >>>>> On 10 Jun 2022, at 02:30, Wietse Venema wrote: >>>>> >>>>> Gerben Wierda: >>>>>> What is happening here? (mail is delivered, I?m just curious) >>>>>> >>>>>> Jun 09 23:37:39 mail postfix/postscreen[4294]: CONNECT from >>>>>> [146.185.52.133]:10400 to [192.168.2.66]:25 >>>>>> Jun 09 23:37:45 mail postfix/postscreen[4294]: PASS NEW >>>>>> [146.185.52.133]:10400 >>>>>> Jun 09 23:37:45 mail smtp/smtpd[4296]: connect from >>>>>> ims-smtp133.persgroep-ops.net[146.185.52.133] >>>>>> Jun 09 23:37:46 mail smtp/smtpd[4296]: CC868E75AA1E: >>>>>> client=ims-smtp133.persgroep-ops.net[146.185.52.133] >>>>>> Jun 09 23:37:47 mail postfix/cleanup[4300]: CC868E75AA1E: >>>>>> message-id=<220609233739.sim_40lt1wa1poje3tjw6hnmtvk29xxj_ghn7vvejgut3cs3hljfekzafd9hipabzz8ro0vetlr2qj0j2ddp9oie2u%2bfuro...@ims-smtp133.persgroep-ops.net> >>>>>> Jun 09 23:37:48 mail postfix/qmgr[8801]: CC868E75AA1E: >>>>>> from=, size=34628, nrcpt=1 (queue active) >>>>>> Jun 09 23:37:48 mail smtp/smtpd[4296]: warning: TLS library problem: >>>>>> error:0A000126:SSL routines::unexpected eof while >>>>>> reading:ssl/record/rec_layer_s3.c:309: >>>>>> Jun 09 23:37:48 mail smtp/smtpd[4296]: disconnect from >>>>>> ims-smtp133.persgroep-ops.net[146.185.52.133] ehlo=2 starttls=1 mail=1 >>>>>> rcpt=1 data=1 commands=6 >>>>>> >>>>> >>>>> Did you look for 0A000126 with a web search engine? >>>> >>>> Yes. Searched on the entire error string as well. >>>> >>>> But that did not give me a clue. >>> >>> I got: OpenSSL 3 is more strict about clients that disconnect without >>> fully following the protocol. >> >> Specifically, google 0A000126, the first result is PHP issue 8369a > > Indeed. Interesting. I use duckduckgo (which relies on Bing afaik) and it > doesn’t find that. > >> which links to https://github.com/openssl/openssl/issues/11378 >> <https://github.com/openssl/openssl/issues/11378>. The >> latter had a breaking fix, backed it out for OpenSSL 1.1.1, but >> kept it in the branch that become OpenSSL 3. > > So basically, the sender doesn’t properly close the SSL protocol, their MTA > is using an SSL which isn’t properly implemented. My understanding is that a truncation attack is never a problem in SMTP, as a premature EOF is always an SMTP error. If this is in fact the case, Postfix should set SSL_OP_IGNORE_UNEXPECTED_EOF to tell OpenSSL to not treat a missing close_notify as an error. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Preventing .forward backscatter
On 6/27/22 17:15, Derek B. Noonburg wrote:
> On Thu, 23 Jun 2022 20:13:10 -0400
> Viktor Dukhovni wrote:
>
>> On Thu, Jun 23, 2022 at 02:43:02PM -0700, Derek B. Noonburg wrote:
>>
>>> I'm running postfix to handle email for several users. One of them
>>> has a .forward file that points to a gmail address. Gmail's servers
>>> are rejecting some email for various causes ("low reputation of
>>> sending domain", SPF failures).
>>>
>>> The problem is that postfix then bounces the email back to the
>>> (likely forged) sender, which means my server is sending
>>> backscatter.
>>>
>>> What I'd like to do is silently drop any email that's rejected by
>>> the target of a .forward file. Is there some way to configure
>>> postfix to do that? Or some better way of handling this problem?
>>
>> If you can convince the user to surrender the alias management to you,
>> then you instead configure:
>>
>>
>> owner-user: user
>> user: some.a...@gmail.com
>>
>> And presto magic, email to gmail will be forwarded with an envelope
>> sender address that no longer fails SPF checks. DKIM should continue
>> to work, because the message content will not be modified in transit.
>
> Can you elaborate a little bit on exactly what this does? From
> aliases(5): "when an alias exists for owner-name, this will override
> the envelope sender address, so that delivery diagnostics are directed
> to owner-name". If I understand correctly, the current situation is
> that email received for "user" is forwarded to "some.a...@gmail.com"
> with the original envelope sender. And with this change, it's still
> forwarded to gmail, but with the envelope sender set to
> "user@mydomain". Do I have that right?
>
> That would fix gmail's SPF rejections, but probably not the other
> rejections. Or wait -- is gmail rejecting based solely on the envelope
> sender address?
>
> Will this work in conjunction with the virtual alias table? I.e., if I
> have virtual aliases like this:
>
> f...@example.com user
> b...@example.com user
>
> then the owner-user / user aliases are processed after the virtual
> alias, yes?
>
> I think the big problem here (as Bob Proulx pointed out) is that the
> forwarded mail is spam. For my own email, I do spam filtering on a
> different machine (i.e., after postfix has delivered it). I'm handling
> email for a few friends, one of whom is effectively using gmail to do
> spam filtering. I think the real fix is going to be to stop forwarding
> email like this, and completely change the way email is processed for
> this user.
rspamd might be an option for this.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: Where to place spamhaus tests
On 8/7/22 09:50, Linkcheck wrote: > On 07/08/2022 1:12 pm, Rob McGee wrote: >> dig 2.0.0.127.zen.spamhaus.org. any > > ANY has to be after DIG, not at the end, but... > > > ; <<>> DiG 9.10.3-P4-Ubuntu <<>> any 2.0.0.127.zen.spamhaus.org. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18750 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;2.0.0.127.zen.spamhaus.org. IN ANY > > ;; ANSWER SECTION: > 2.0.0.127.zen.spamhaus.org. 3579 IN A 127.255.255.254 > > ;; Query time: 1 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sun Aug 07 14:34:59 BST 2022 > ;; MSG SIZE rcvd: 71 > > > And I use a local copy of Unbound for all DNS work. You need to check the following: 1. Unbound MUST be operating as a recursive resolver, NOT a stub resolver. That means that it is making requests from upstream nameservers directly, rather than via an upstream recursive resolver. In the case of Unbound, this means that all forward-zone: directives in the configuration file must be removed, unless they are restricted (via name:) to zones that are not a suffix of zen.spamhaus.org. 2. Your instance of Unbound MUST NOT be accessible from the Internet. That is, unauthorized users must not be able to submit DNS queries to it. If they can, I suspect it would be considered a public recursive resolver and blocked. Can you provide your `unbound.conf` as well as all of the files it includes? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Postscreen DNSBL do not seem to be working
On 8/9/22 16:02, Dino Edwards wrote: > >> It's absolutely not forwarding. It's resolving recursively. I'm using > unbound with pfsense and I'm suspecting there is something wrong with it. >> When I point to MS DNS server or 9.9.9.9, it's resolving correctly. > > The issue has been resolved. Just in case someone finds the solution useful, > pfsense by default has rebind protection enabled which disables DNS > responses using rfc1918. So disabling rebinding DNS protection in pfsense is > the solution. Unbound allows configuring rebinding protection in unbound.conf. You should allow only the expected RFC1918 addresses, not all of them and certainly not loopback. What RFC1918 addresses are you seeing? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: send mail from the domain directly to the local server without going out to the Internet
On 8/18/22 06:14, Jaroslaw Rafa wrote: > Dnia 18.08.2022 o godz. 09:17:39 Sam R pisze: >> As you suggest, I enabled TLS wrappermode on both senders servers and the >> internal server, set "smtp_tls_security_level = encrypt " to senders >> servers and it seems perfect now. >> Thanks a lot Noel and Thank you all too! > > I doubt if you should use port 465 at all. > > RFCs clearly say that port 465 is for mail submission, not for receiving > mail addressed to local users, and that authentication is mandatory on port > 465. From what you write, it seems that you send mail via port 465 without > authentication, which is not the intended use of that port. > > IMHO, you should be sending mail between your servers using just regular > port 25. The servers should have each other IP addresses in $mynetworks, so > the receiving server will trust the sending server. I recommend using client certificate authentication on port 465 instead. IP addresses are not a strong form of authentication unless one is using a secure VPN such as WireGuard. Also one should be encrypting traffic anyway as a matter of best practice. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: send mail from the domain directly to the local server without going out to the Internet
On 8/19/22 07:08, Matus UHLAR - fantomas wrote: > On 19.08.22 10:47, Sam R wrote: >> So I am a little divided, >> On the one hand I think that port 25 is enough to transmit mails locally, > > I guess by "locally" you mean "on the local network". > > port 25 is standard for server-server communication, 465/587 are standard > for client-server communication where authentication is required/enforced. > >> on the other hand I think that an encryption would be better, especially on >> the dmz. > > I'd say "especially for connections crossing not-secured network". > mails within LAN/DMZ should be safe unencrypted, unless you have reason not > to trust the network or someone on it. Google made this assumption and it turned out to be wrong. Use mutually authenticated TLS. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: send mail from the domain directly to the local server without going out to the Internet
On 8/19/22 13:48, Matus UHLAR - fantomas wrote: >>> On 19.08.22 10:47, Sam R wrote: >>>> So I am a little divided, >>>> On the one hand I think that port 25 is enough to transmit mails locally, >>> >>> I guess by "locally" you mean "on the local network". >>> >>> port 25 is standard for server-server communication, 465/587 are standard >>> for client-server communication where authentication is required/enforced. >>> >>>> on the other hand I think that an encryption would be better, especially on >>>> the dmz. > >> On 8/19/22 07:08, Matus UHLAR - fantomas wrote: >>> I'd say "especially for connections crossing not-secured network". >>> mails within LAN/DMZ should be safe unencrypted, unless you have reason not >>> to trust the network or someone on it. > > On 19.08.22 09:09, Demi Marie Obenour wrote: >> Google made this assumption and it turned out to be wrong. Use mutually >> authenticated TLS. > > what are you talking about? > because I have access to private networks where this is not an issue. See Snowden leaks. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: filtering incoming email mail_from/reply to/from/etc.
On 8/22/22 12:17, Phil Stracchino wrote: > On 8/22/22 11:50, Viktor Dukhovni wrote: >> On Mon, Aug 22, 2022 at 05:35:54PM +0200, Patrick Proniewski wrote: >>> But the "loophole" here is that blank sender/return-path is allowed >>> (MAILER DAEMON), I could prohibit that, but with huge caveats. >> >> Best to ignore bad advice. You may need a better antispam filter. Ad >> hoc rules for past (and plausibly never again) abuse are not likely to >> be effective. That said, no antispam filter is 100% effective. Some >> spam *will* get through no matter what you do. > > If there was a method of spam filtering that was 100% effective, > *everyone* would be using it. ...And the spammers would be working > night and day to figure out ways to circumvent it. > > A lot of the problems in spam filtering is that the protocols we use for > email delivery were fundamentally designed in insecure, unauthenticated > ways, because they were created in a different, friendlier, arguably > more naïve world in which nobody imagined that anyone would abuse email > on a large scale. Trying to bolt security and authentication onto > anything after the fact is always harder than designing in secure > authentication from the start. > > The other side of that coin, though, is that we are in a lot better > place to do that secure authentication now, because our tools (hardware > and software) are so much better and more capable. But that doesn't > mean it's not still a hard problem. The correct solution to prevent email forgery is DNSSEC + DKIM + DMARC with p=reject + some way to prevent DMARC from accepting based on SPF alone. In practice, lots of stuff is misconfigured. I don’t run a mail server, but if I did, I would be pretending that Google had p=quarantine, even though it has p=none. I would also be using DNS over TLS to 8.8.8.8 with pinned CA certificates to get Google’s DNS records, and refusing to send mail to Google unless a Google CA signed the server’s TLS cert. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Fwd: Re: Postfix 3.5 and outbound TLS/SSL
On 8/22/22 17:38, nate wrote: > On 2022-08-22 14:30, Viktor Dukhovni wrote: > >> Correct, because there's no point. Mail would be sent whether the >> certificate is trusted or not, and whether or not the DNS-ID matches >> expectations. >> >> Setting up a TLS policy for each domain that's hosted by Microsoft is >> unrealistic, and they don't yet support DANE (but this is planned). > > ok thanks! > > I looked into DANE yesterday had never heard of it before that I can > recall anyway, and it appeared to need DNSSEC, which isn't something > I've had an interest to deploy. I read what appeared to be a really > good blog post on DNSSEC a few years ago that really ripped it apart > (https://sockpuppet.org/blog/2015/01/15/against-dnssec/). Can't > vouch for accuracy but the person seemed like they knew what they > were talking about. That was of course 7 years ago so maybe things > have changed since. > > nate You should definitely deploy DNSSEC, but only after you are able to deploy it properly. That means having procedures to avoid nasty DNSSEC- related downtime. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: incoming log entries missing during peak arrival time
On 11/15/22 08:17, Wietse Venema wrote: > Dhammika Gunawardena: >> Hi >> >> We maintain a private relay server to send ebills for a customer. >> During peak sending hours, we miss about 5-10% of incoming messages but >> outgoing messages are available. >> We capture subject line in incoming message to track ebills. When >> incoming messages are missing, we are in trouble. >> Mail log written by rsyslog. >> >> Need help either >> 1. to fix the issue >> 2. Or write Subject in outgoing message > > Avoid logging loss caused by system-effing-d. > > https://www.postfix.org/MAILLOG_README.html > > Wietse RateLimitIntervalSec=0 in journald.conf is also an option. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: What happens if Postfix can't reach relay_host? - Postfix on laptops for system messages, with relay_host behind VPN
On 11/15/22 17:56, r.barc...@habmalnefrage.de wrote: > Wietse, Thanks so much for your quick and helpful response! It's an honor to > talk to you! > > So my idea might only work, if I use the LAN IP address (e.g. 10.1.2.3) of > the internal mail server as relay_host. > If Postfix can't connect to 10.1.2.3, it will probably retry mail relaying > for some days, configurable in maximal_queue_lifetime. That would be fine. > > But it will NOT work, if I use an intranet FQDN (e.g. > internalmail.myintranet.corp), which can only be resolved, if the laptop is > in the LAN or VPN. > Then emails get lost if they arrive while not in the LAN / VPN. > > Or do you maybe have a different idea / suggestion about how to collect local > system emails from laptop clients? Place the FQDN in /etc/hosts. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: helo command rejected
On 12/2/22 08:08, David Dolan wrote: > On Fri, 2 Dec 2022 at 10:33, David Dolan wrote: >> Subject:Re: helo command rejected >>> From: Viktor Dukhovni >>> Date: 2022-12-01 16:56:13 >>> Message-ID: Y4jcrRxsEJPsWZVZ () straasha ! imrryr ! org >>> [Download RAW message or body] >>> >>> On Thu, Dec 01, 2022 at 04:06:30PM +, David Dolan wrote: >>> >>>> This is the full line: >>>> >>>> NOQUEUE: reject: RCPT from unknown[103.246.251.109]: >>>> 450 4.7.1 : >>>> Helo command rejected: Host not found; >>>> from=<#> to=<#> >>>> proto=ESMTP helo= >>> >>> Indeed the hostname "wx-use2.prod.hydra.sophos.com" exists and has >>> multiple IP addresses, requiring support for either TCP or EDNS with a >>> UDP buffer larger than 512 bytes Perhaps your DNS resolver or the C >>> library stub resolver are configured to limit DNS to 512 bytes of UDP >>> and also don't retry over TCP? In that case you'd get only a truncated >>> response with no answers, and have no way to recover: >>> >>> $ dig +nocmd +ignore +norecur +noedns -t a >>> wx-use2.prod.hydra.sophos.com @ns-1793.awsdns-32.co.uk >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14328 >>> ;; flags: qr aa tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 >>> >>> ;; QUESTION SECTION: >>> ;wx-use2.prod.hydra.sophos.com. IN A >>> >>> ;; Query time: 9 msec >>> ;; SERVER: 205.251.199.1#53(ns-1793.awsdns-32.co.uk) (UDP) >>> ;; WHEN: Thu Dec 01 11:47:53 EST 2022 >>> ;; MSG SIZE rcvd: 47 >>> >>> Are you on a MUSL libc system? IIRC there's no support for TCP in >>> MUSL's stub resolver. See, for example: >>> >>> https://news.ycombinator.com/item?id=28312935 >>> >> We do use Alpine Linux so maybe truncation is the issue? I thought it may >> have been initially but couldn't find anything confirming >> > This is from the mail relay which says it's truncated and trying tcp mode. > It does return all 33 IP addresses > dig wx-use2.prod.hydra.sophos.com > ;; Warning: Message parser reports malformed message packet. > ;; Truncated, retrying in TCP mode. > > I guess it's using the musl resolver in Alpine so we need to migrate OS to > get past this issue? Another option would be for Postfix to use an alternate DNS library, like C-Ares, libasr, or libunbound. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: TLS config confirmation
On 12/10/22 16:48, Alex wrote: > Hi, > > On Thu, Dec 8, 2022 at 2:17 AM Matus UHLAR - fantomas > wrote: > >> On 07.12.22 12:28, Alex wrote: >>> smtp_tls_security_level = may >>> smtpd_tls_security_level = may >>> smtp_tls_mandatory_protocols= !SSLv2,!SSLv3,!TLSv1,!TLSv1.1 >>> smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1 >> >> so, you don't enforce TLS on a server-server communication (correct), but >> you disable tlsv1 and tlsv1.1 protocols. >> >> This means, if you communicate with older server supporting up to TLS 1.1 >> or >> 1.0, communication will be unencrypted. >> >> This does not make much sense - tls1.0 is better than plaintext. >> > > I think I assumed there was a vulnerability, like there is with SSLv3, that > lead me to disable it. > > I've now changed it to just: > > smtpd_tls_mandatory_protocols = >=TLSv1.0 > > Can I also ask if it's a security risk from an information disclosure > perspective to have multiple domains on the same letsencrypt cert? Each > postfix instance I have configured processes mail for a number of different > domains, so it's possible a user could ascertain info about those other > clients by querying the cert directly. It certainly makes it easier for me > to maintain the certs, but wanted to consider at what cost to privacy or > the disclosure of that info. The most important part is not supporting RSA key exchange. If you support RSA key exchange you may be vulnerable to e.g. ROBOT or Bleichenbacher’s CAT. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: tls connection reuse
On 12/14/22 07:05, Wietse Venema wrote: > Gino Ferguson: >> Hi List, >> >> >> I'm reading the doc and wondering why 'smtp_tls_connection_reuse' >> is not enabled by default? > > Because it was unknown if doing so would cause problems (in Postfix, > or in other software). Only real-world deployment can tell such > things. > >> Are there any possible drawbacks? > > None have come up sofar. So maybe it is safe to make it the default. > We know it works well for small messages. but I'd like so see > performance metrics for large email messages, because many connections > are handled by a smaller number of single-threaded tlsproxy > processes. Can these processes handle multiple connections concurrently in an event-driven manner? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Spammer succeeded in relaying through my server
On 12/21/22 06:02, Jaroslaw Rafa wrote: > Dnia 21.12.2022 o godz. 13:21:06 Samer Afach pisze: >> Thank you for the explanation. I will follow up on this and >> hopefully I'll find a way to solve this problem properly without >> obfuscation of incoming IP addresses. Seems like, worst case >> scenario, I just have to disable relaying of emails altogether and >> that'll solve the problem, at least until a better solution is >> available. > > Do any other containers on your machine relay mail through your Postfix? > > If no, you can safely allow relaying mail from localhost only. > > If yes, do all these containers seem to connect from address 172.30.0.1 or > is this address used only by haproxy, and other containers connect from > different 172.30.* addresses? > > If all containers are using 172.30.0.1 address, you must reconfigure Docker > networking so that each container uses its own IP address from Postfix point > of view (I don't know how as I don't use Docker, but it is certainly > possible). If it is already the case, you don't need to do anything. > > Then, you have to fiddle somehow with smtp_*_restrictions so to allow > relaying mail from other hosts in 172.30.* subnet, but reject relaying from > 172.30.0.1 (or just set explicitly mynetworks= to all IP addresses of the > containers that will relay mail). Just an idea, can't think of detailed > configuration settings now. An alternative, which I prefer, is to require all submission to be on port 465 (over TLS) and require SASL authentication on that port. Port 25 would then be for receiving email only. I prefer using client certificates for authentication, and having the secret keys injected when launching the containers (they would not be in the images). -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: warning: disabling connection caching
On 12/20/22 06:13, Wietse Venema wrote: > Fourhundred Thecat: >> Hello, >> >> I had this in my logs: >> >>postfix/master: warning: process /usr/lib/postfix/sbin/scache pid >> 1215 killed by signal 11 >>postfix/master: warning: /usr/lib/postfix/sbin/scache: bad command >> startup -- throttling >>postfix/smtp: warning: problem talking to service >> private/scache: Connection timed out >>postfix/smtp: warning: problem talking to service >> private/scache: Connection timed out >>postfix/smtp: warning: disabling connection caching >> >> as the last line says, connection caching was disabled. >> >> Is this permanently, or until next restart of thew master process? > > Until the smtp client process terminates. > >> Also, if I wanted to test scache, how can I trigger it? >> >> If I send one email to multiple email addresses on same domain, will >> this trigger scache? (ie, deliver multiple emails in one connection to >> the server?) > > Did you build Postfix? > > Is this one of those container-optimized libc implementations? Should Postfix use an alternate DNS library, instead of the one provided by libc? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Spammer succeeded in relaying through my server
On 12/23/22 09:58, Samer Afach wrote: > Dear postfix experts: > > I think I'm getting to the end of this problem. I was able to use > haproxy to relay connections to my docker container with correct source > information (and I'm seeing the correct IP addresses in the logs of > postfix/dovecot). I would appreciate it if you could take a look at my > settings before going public and changing the MX records back to this > server. > > How I tested: I was actively blocking/unblocking firewalls, > starting/stopping containers (start, test, stop), and in every step, I > ran swaks, with one of these configurations (in fact, I'm planning to > automate these tests and run them periodically, what a nice tool this > turned out to be): > > swaks --to a...@example.com --from=b...@example.com --server > mail.example.com:587 --tls > swaks --to a...@example.com --from=b...@example.com --server > mail.example.com:465 --tlsc > swaks --to a...@example.com --from=b...@example.com --server > mail.example.com:25 --tls > swaks --to a...@example.com --from=b...@example.com --server > mail.example.com:25 > > I was consistently getting the result "Access denied" in swaks, which I > hope means that no relaying is possible anymore. Meanwhile, I succeeded > in sending messages with Thunderbird with proper authentication. > > Email relaying was only possible when sending emails with swaks through > localhost (even though it's going through the proxy in localhost), i.e.: > > swaks --to a...@example.com --from=b...@example.com --server 127.0.0.1:587 > --tls > swaks --to a...@example.com --from=b...@example.com --server 127.0.0.1:465 > --tlsc > swaks --to a...@example.com --from=b...@example.com --server 127.0.0.1:25 > --tls > swaks --to a...@example.com --from=b...@example.com --server 127.0.0.1:25 > > Does this constitute proof that relaying isn't possible anymore? You need to ensure that the outside world cannot connect to Postfix or Dovecot directly, bypassing HAProxy. -- Sincerely, Demi Marie Obenour (she/her/hers)
Re: Spammer succeeded in relaying through my server
x27;t needed (SASL is > necessary > and sufficient). > >> -o smtpd_upstream_proxy_protocol=haproxy >> ``` >> >> The other standard ports (25, 465 and 587) without proxying are unreachable >> from the outside. >> >> And finally, `postconf -n` (I fixed the issues indicated in the email chain >> after having read their documentation): >> >> ``` >> alias_database = hash:/etc/aliases >> alias_maps = hash:/etc/aliases >> append_dot_mydomain = no >> biff = no >> broken_sasl_auth_clients = yes >> debug_peer_level = 6 >> debug_peer_list = 0.0.0.0/0 >> disable_vrfy_command = yes >> inet_interfaces = all >> inet_protocols = ipv4 >> mailbox_size_limit = 0 >> maillog_file = /dev/stdout >> message_size_limit = 0 >> milter_default_action = accept >> milter_protocol = 2 >> mydestination = localhost >> myhostname = example.com >> mynetworks_style = subnet >> myorigin = localmail.example.com >> non_smtpd_milters = inet:docker-email-opendkim:12301 >> postscreen_upstream_proxy_protocol = haproxy >> proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps >> $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains >> $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps >> $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks >> $smtpd_sender_login_maps >> readme_directory = no >> recipient_delimiter = + >> relay_domains = >> relayhost = >> smtp_tls_cert_file = /shared-keys/mail.example.com/fullchain.pem >> smtp_tls_key_file = /shared-keys/mail.example.com/privkey.pem > > The above two parameters should probably be renoved. > Specifying a particular key for outgoing TLS connections > is only important when connecting to specific remote > servers that require your server to use a specific > known key. That doesn't look to be the case here. > Usually, you only need to specify the cert/key files > for the smtpd_ versions of these parameters. See below > for comments on those. > >> smtp_tls_loglevel = 1 >> smtp_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1 >> smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1 > > The above parameter isn't needed (and maybe the one > above it too). TLSv1 and TLSv1.1 are better than no > encryption at all. And these settings are for outgoing > connections. So even if your mail server is scanned as > part of a naive cookie-cutter security assessment, the > scanner won't know that you are willing to use those > deprecated protocols for sending mail, and so won't > complain. If you don't exclude TLSv1 and TLSv1.1 in the > similar smtpd_tls_protocols parameter, such a scanner > would complain, even though it's still better than no > encryption. Security scanners usually assume that > policies that should apply to a web server (using > mandatory encryption) should also apply to a mail > server (using opportunistic encryption). For ports 465 and 587, encryption should be mandatory, so requiring strong ciphers is a good idea. Also, blocking non-forward-secrecy ciphers is important to prevent the ROBOT attack. -- Sincerely, Demi Marie Obenour (she/her/hers)
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: warning: unexpected protocol delivery_request_protocol from private/bounce socket (expected: delivery_status_protocol)
On 1/1/23 19:01, Wietse Venema wrote: > trading fours: >> I am seeing the subjected error for a small percentage of messages, and >> then those message stay in the deferred queue. >> >> from the log: >> postfix/local[1124]: warning: unexpected protocol delivery_request_protocol >> from private/bounce socket (expected: delivery_status_protocol) > > You changed the 'bounce' service entry in master.cf, and replaced > the bounce program name with the name of some program that does not > implement the delivery_status service protosol. Don't do that. > > Also, you are receiving mail, presumably via SMTP, and then bouncing > it. Don't do that. Is there any reason for mail received on port 25 to be bounced? Or should bouncing be reserved for authenticated mail submission? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Group-based SASL Auth
On 1/3/23 17:23, Xavier Belanger wrote: > Hi, > > My question is not directly related to Postfix, but hopefully > someone could point me in the right direction. > > I am building a SMTP relay server with SASL authentication, > using LDAP (Active Directory) as a backend and it does work. > Regular users can send emails after being authenticated. Have you considered using Kerberos + channel binding instead of LDAP authentication? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Rate limiting local clients: configuration and logging
On 1/3/23 19:20, Hébergement Arbre Binaire wrote: >> If submission rate limits are required, use SMTP instead of the Postfix > sendmail command. > > Aside from creating a "shim" of some sort to catch sendmail calls made by > random malicious scripts and that uses SMTP to route mail to the local MTA, > I don't see any solution. It's a bit above my paygrade since any and all > MTA matters have a "cold water on neck effect" on me :-) I recommend using firewall rules to ensure that only the postfix user can connect to port 25 outbound. Otherwise, the script can just send mail directly. You might try submitting a patch to add this feature to postdrop (the privileged mail submission component of Postfix). -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Dumping effective postfix configuration
On 1/6/23 07:15, Wietse Venema wrote: > Peter Wienemann: >> Hi, >> >> is there a way to dump the effective postfix configuration rather than >> the one specified in main.cf/master.cf? It seems that changes to >> main.cf/master.cf have an immediate impact on the output of postconf >> regardless of whether a reload/restart of the service was performed. > > How would that work? Different Postfix processes start at different > times, and some processes (qmgr, master) run forever. What about using inotify/kqueue to determine when a config file has changed and reload accordingly? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Simple forwarder for postfix?
On 1/10/23 18:02, Dan Mahoney wrote: > Viktor, > > I apologize for the off-list email — I would like to add some context here, > but also not mention my day job by name specifically on a public mailing list. > > We are already using the alias-function as you suggest: > > support-contacts: support-st...@isc.org, > :include: /usr/local/etc/rt42/contact-alias.lst > > And I see the bit about -owner being special, however, this is not about the > envelope sender, but the envelope RECIPIENT: > > When we attempted to deliver to someone hosted on office 365, we get a bounce > like the below, where it seems to not have rejected on the envelope header, > but on the envelope recipient.. Exchange 365 is correct to refuse delivery to support-st...@isc.org, at least assuming that isc.org is not itself on Exchange 365. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
BINARYMIME in Postfix
On 3/20/21 2:51 PM, John Levine wrote: > It's defined in RFC 3030. Read all about it: > https://www.rfc-editor.org/info/rfc3030 > > It happens that I just added CHUNKING and BDAT to an MTA I use (mailfront if > you know > what that is.) Inbound the code is quite simple and I would be surprised if > there were > any problems with it. Outbound it's a little trickier since BDAT requires > you to know > the exact size of the chunk of message you're sending, which means it has to > deal with > turning \n into \r\n, but again, it's not a big deal. > > I'm guessing that someone had some problem talking to Gmail or > Hotmail/Outlook, the > two largest systems that can use BDAT, turned it off to see if that was the > problem, > and never bothered to turn it back on when it wasn't. This reminded me that Postfix does not have BINARYMIME support. GMail does not, but Outlook does. How useful would BINARYMIME support be? It does mean that DKIM signing would need to be done in the sending path, but I cannot think of any reasons that would be a blocker. Having DKIM and DMARC built-in to Postfix would be a nice feature, tbh. The only open-source MTA I know of with built-in DKIM is Exim but I would never dare use it in production. Ideally, the signing keys should be in a separate process for privilege separation, but Postfix is already multi-process so that should be doable. Of course, the final decision is up to Wietse. Sincerely, Demi Marie Obenour she/her/hers OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: BINARYMIME in Postfix
On 3/21/21 2:25 PM, Wietse Venema wrote: > John Levine: >> It appears that Wietse Venema said: >>> Demi Marie Obenour: >>>> How useful would BINARYMIME support be? It does mean that DKIM signing >>>> would need to be done in the sending path, but I cannot think of any >>>> reasons that would be a blocker. Having DKIM and DMARC built-in to >>>> Postfix would be a nice feature, tbh. The only open-source MTA I >>>> know of with built-in DKIM is Exim but I would never dare use it in >>>> production. >>>> >>>> Ideally, the signing keys should be in a separate process for privilege >>>> separation, but Postfix is already multi-process so that should be >>>> doable. Of course, the final decision is up to Wietse. >>> >>> See also https://github.com/OpenSMTPD/OpenSMTPD/issues/1090 >>> >>> I haven't had the time to properly analyze what this would take. >>> Here's a first inventory. >> >> Since most other MTAs don't suport BINARYMIME, you'd need some way >> to sniff the recipient server and then rewrite the binary parts >> as base64 before sending the message, recomputing any DKIM and ARC >> signatures on the way. Have fun with that. > > That might work for one-to-one messages, but not for one-to-many. > A more general solution would convert and sign during delivery. Not > fun, but technically possible. > >> BINARYMIME avoids the 33% size increase of base64. If people cared >> about that, since every MTA now supports 8BITMIME it would be easy >> to invent a quoted-unprintable content-transfer-encoding which >> escaped only the few characters that are special in 8BITMIME (CR >> LF NUL and to be on the safe side, 0xff.) That would get you about >> 98% of the way to binary with 2% of the work. > > This would turn binary content into a long line. That works perfectly > with qmail and Postfix (except that the Postfix SMTP client will > need a hint to avoid folding such lines at the 998 octet limit of > RFC 5321). Another approach would be to create a “wrapped” MIME type that just wraps another message in base64. That has the advantage of working with multipart/signed et al. quoted-printable also has line continuations. > Wietse Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: quoted-unprintable, was BINARYMIME in Postfix
On 3/21/21 8:13 PM, John Levine wrote: > It appears that Wietse Venema said: >> With uniform or compressed payloads, 256 bytes become 261 on average, >> thus it takes 978.9 bytes on average to expand into 998. Add CR >> and LF to the 998, and we have an expansion of 1000/978.9=1.022 or >> just a little over 2%. > > That was my estimate too. I was rounding, so sue me. > >> It could have been a good idea 25 years ago. > > Turns out it came up on the ietf-smtp list in 2003. Here's the mail > discussion > and a strawman I-D that Ned Freed wrote for a deflate-8bit encoding that > combines > deflate compression (like gzip) with minimal escapes for 8BITMIME. > > https://mailarchive.ietf.org/arch/browse/ietf-822/?gbt=1&index=VmGPBP83tzuzAzdKOwtckalMipE > > https://datatracker.ietf.org/doc/draft-freed-mime-newenc/ > > I agree that these days we routinely pass around ummpteen megabyte base64 > messages and > nobody cares. If we did care, the reasonable approach would be to stick the > giant file > on a web server and use message/external-body to refer to it. That is > defined in > RFC 2017 which was indeed 25 years ago. Not an option, sadly. Good MUAs refuse to load external content for privacy reasons. Sincerely, Demi OpenPGP_signature Description: OpenPGP digital signature
Re: idea: inlining pcre, cidr, etc and detecting TLS handshakes
On 4/14/21 3:39 PM, Wietse Venema wrote:
> Viktor Dukhovni:
>> On Wed, Apr 14, 2021 at 02:24:23PM -0400, Wietse Venema wrote:
>>> TL;DR: the idea is to change the smtpd_forbidden_commands default
>>> setting to something like:
>>>
>>> CONNECT GET POST pcre:{/^\x16/ Possible TLS handshake}
>>>
>>> Which would match current TLS protocols.
>>
>> I guess subject to "#ifdef HAVE_PCRE".
>
> Sure. Note that this is configurable, so that a signature can be
> added without having to upgrade or recompile Postfix, and that this
> does not care whether a problem is the servers's fault or client's.
>
> (aside from that, the ability to replace a lookup table pathname
> with {the file content} has potential for other use cases).
>
>> Another option to reduce user surprise is to log warnings when
>> listening on port 465, but TLS wrapper mode is not enabled. Or,
>> more radically, implicitly enable wrapper mode when configured to
>> run on port 465.
>
> Heuristics for the expected state of ports and protocols are
> preferably configurable. If they were hard-coded in C, Postfix would
> need to be recompiled when there is a need to change a rule.
>
> Wietse
Would the following be a good idea?
- Ports 25 and 587 default to having TLS wrapper mode disabled.
TLS handshakes without STARTTLS are logged.
- Port 465 defaults to having TLS wrapper mode disabled. Connections
that do not begin with a TLS handshake are logged.
- Other ports default to the current behavior, but this is deprecated
and logs a warning at startup. The warning can be suppressed by
explicitly enabling or disabling the TLS wrapper.
I wonder if we could also have similar behavior w.r.t. authentication:
ports 587 and 465 automatically enable it, port 25 automatically
disables it, and listening on other ports logs a warning unless an
explicit setting exists.
Sincerely,
Demi
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: idea: inlining pcre, cidr, etc and detecting TLS handshakes
On 4/15/21 11:00 AM, Wietse Venema wrote: > Demi Marie Obenour: >> Would the following be a good idea? > [a bunch of port-dependent behavior] > > That is all good and well, but this needs to be made configurable. > > I boldly assume this will use the xxx_tls_wrapper_mode parameters, > instead of replacing them with some totally different mechanism. I don’t particularly care about the mechanism. Since this already exists, using it is obviously preferable to writing a new one. > Possible options: > > smtpd_tls_wapper_mode = > Something that depends on an inbound port which is defined > in master.cf. As of Postfix 3.3, the read-only "service_name" > parameter contains the first field of a master.cf entry, > in the form of a port, service-name, host:port, host:service-name, > or UNIX-domain pathname. Extracting or matching the port > or service-name portion is beyond what is currently possible > with Postfix conditional parameter expansions. From a > security standpoint, using this information is OK because > master.cf is writable by the super-user only, and because > the Postfix master daemon is a trusted process. > > smtp_tls_wrapper_mode = > Something that depends on an outbound port or service-name > that is specified in a delivery request in a next-hop > destination as host:port or host:service-name (this is based > on information from default_transport, relayhost, transport_maps, > or the sender-dependent versions of those). Basically, > this would make parameter evaluation dependent on data in > a delivery request. There is prior art for doing this in > the local delivery agent in very limited cases: luser_relay, > forward_path, and command_execution_directory. That had to > be implemented very carefully to avoid security problems. > > So based on this we need > > 1) SMTP server: Add support to match the port or service name in > in the service_name parameter (new parameter evaluation code, > non-trivial), OR: make the port or service name available as another > parameter (new code in daemon library, trivial and safe). In both > cases, make the smtpd_ls_wrapper_mode default value port dependent. Exactly. > 2) SMTP client: Postpone the evaluation of smtp_tls_wrapper_mode > until after a delivery request is received, add support for > request-dependent $parameter expansion in smtp_tls_wrapper_mode, > and make that bullet-proof. Doing this for smtp_tls_wrapper_mode > can be made safe; doing this for more SMTP client parameters would > require a much more extensive security analysis. From my perspective, SMTP + STARTTLS is equivalent to SMTPS, except that they use different port numbers and the latter uses fewer round-trips. Obviously, downgrade from TLS to no TLS is bad, but switching between SMTP + STARTTLS and SMTPS is fine. That said, this appears to be more complicated than I thought it would be. Do you consider the extra complexity (and attack surface) justified? > Wietse Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Trusting postfix client certs for relaying
On 4/17/21 5:15 PM, Wietse Venema wrote: > Dan Mahoney (Gushi): >> All, >> >> The dayjob has a number of machines out in the wild that need to be able >> to send mail (mostly from cron jobs) home to the mothership. Not all have >> controllable reverse DNS. It's an issue with donated colo and transit. >> Doing a bunch of tunnels would work but it's a really stupid answer. >> >> We'd like to use client-certs as an auth mechanism. We're already >> deploying trusted client certs for use with puppet, so we have a full CA >> setup already in place. If we trust any cert signed by our puppetmaster's >> CA (which uses a root/intermediate/leaf setup for signing) we should be >> golden. >> >> However, reading the postfix docs >> (http://www.postfix.org/TLS_README.html#server_vrfy_client) , I see >> warnings that one should not use permit_tls_all_clientcerts for something >> like that. If an outside client were to connect with (say) a let's >> encrypt cert configured as a client cert (which we may want to *validate*, >> but *not permit for relaying*, that cert would allow relay) >> >> It seems that There are knobs that let you list *individual certs* for >> allowing trusted relaying, but not *individual ca's*. >> >> Is there any way around this? > > Yes: handle that traffic with a dedicated smtpd instance that only > trusts your internal root. > > Postfix check_ccert_access currently supports matches based on > certificate fingerprint and public key fingerprint. The other > available attributes, issuer name and subject name, are too soft > for security decisions. > > Wietse Would it be possible to support trusting based on subject alt name? I would like a machine with a certificate for a.example.com to send mail from a.example.com domains. Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Trusting postfix client certs for relaying
On 4/18/21 2:39 PM, Wietse Venema wrote: > Demi Marie Obenour: >>>> It seems that There are knobs that let you list *individual certs* for >>>> allowing trusted relaying, but not *individual ca's*. >>>> >>>> Is there any way around this? >>> >>> Yes: handle that traffic with a dedicated smtpd instance that only >>> trusts your internal root. >>> >>> Postfix check_ccert_access currently supports matches based on >>> certificate fingerprint and public key fingerprint. The other >>> available attributes, issuer name and subject name, are too soft >>> for security decisions. >> >> Would it be possible to support trusting based on subject alt name? >> I would like a machine with a certificate for a.example.com to send >> mail from a.example.com domains. > > What is the trust model here? > > Wietse Each system is issued a certificate for its own domain. Perhaps a better example would be email Subject Alternative Names. Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Trusting postfix client certs for relaying
On 4/18/21 8:04 PM, Viktor Dukhovni wrote: > On Sun, Apr 18, 2021 at 07:59:07PM -0400, Demi Marie Obenour wrote: > >>>> Would it be possible to support trusting based on subject alt name? >>>> I would like a machine with a certificate for a.example.com to send >>>> mail from a.example.com domains. > > This rather mixes end-to-end properties (the message envelope sender is > a fixed element of a mult-hop SMTP relay chain) with hop-by-hop > properties (TLS client certificates). > > Permitting particular client certs is fine for MSA relay authorisation, > but is rather dubious for enforcing the envelope sender domain. > > Are then going to forbid the use of these sender domains unless the > client presents a corresponding certificate? Is this an a message > submission service or an inbound MTA? > >> Each system is issued a certificate for its own domain. Perhaps a >> better example would be email Subject Alternative Names. > > That's not an example (use-case), it is a certificate field. What > is the use-case. With some specificity... If I were to run my own email server (I don’t, but I plan on doing so someday), my preferred means of authentication would be by client certificate. And I would want users to be able to send emails as a specific user if, and only if, I have issued them a certificate with the corresponding email address in the SAN. Why client certificates? Because requiring authentication to even connect to the service avoids whole heaps of problems. If the user doesn’t present a certificate, they aren’t going to even get an SMTP greeting, much less be able to send mail. And that is extremely easy to validate: I just need to ensure that connections with no certificate, or with an invalid certificate, fail during TLS negotiation. Furthermore, client certificate authentication does not require any form of credentials (other than the server’s own certificate) to be stored on the server, nor does it require that the server have any form of authentication database. Finally, Postfix needs to run TLS and verify certificates anyway, so that it can securely relay mail. So client certificate authentication hardly increases the attack surface at all. Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Building and running Postfix as unprivileged user
On 4/27/21 9:30 AM, Paul Menzel wrote: > Dear Wietse, > > > Am 27.04.21 um 14:49 schrieb Wietse Venema: >> Paul Menzel: > >>> In our infrastructure, we are building Postfix from source with an >>> unprivileged user, and also try to run most services as an unprivileged >>> user. Privileged ports are forwarded to unprivileged ports, used by the >>> service, by configuring Linux? packet filter rules with *iptables*. >> >> Unprivileged Postfix comes up about once a year in this mailing >> list. Rather than hashing out the arguments here again, please use >> a search engine, or visit mailing list archives. > > Thank you for your prompt reply. Searching for *unprivileged* in the mailing > list archives, I actually only found discussion of containers, and Victor’s > reply in the thread *Should I be root or postfix user to execute postfix commands?* [1]: You can use Linux user namespaces to avoid having to modify Postfix. Postfix will think it is root, but UID 0 in the container is mapped to an unprivileged UID on the host. Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Clients Sending Phantom Email
On 4/28/21 6:59 PM, Asai wrote: > Thank you, Wietse: >> >> This means that client systems are compromised with malware >> that sends email directly to the outside world, bypassing >> your mail server. >> >> To stop these, block outbound port 25 on your firewall for all >> systems except your mail server. >> >> Wietse > > Is it safe to assume that all legitimate email services, like Outlook.com for > example, are going to be using a submission service and not sending directly > over port 25, and that blocking port 25 on outgoing connections will not > interfere with normal email delivery? Many legitimate ISPs (and even some cloud providers) block port 25 outbound, so yes. Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Postfix stable release 3.6.0
On 4/30/21 8:44 AM, Wietse Venema wrote: > @lbutlr: >> On 29 Apr 2021, at 17:05, Wietse Venema wrote: >>>This release requires "postfix stop" before updating, or before >>>backing out to an earlier release, because some internal protocols >>>have changed. Otherwise, long-running daemons (pickup, qmgr, >>>verify, tlsproxy, postscreen) may fail to communicate with the >>>rest of Postfix, causing mail delivery delays until Postfix is >>>restarted. >> >> This seems to be contradicting itself. Do we have to stop postfix before = >> updating, or do we have to restart postfix after updating? > > No it doesn't. > > You must STOP Postfix before updating or backing out. > > If you don't STOP then you must RESTART to clean up the mess > that you created. > > Wietse Is it possible for mail to be lost and/or mishandled as a result, or will the mess resolve itself when Postfix is restarted? Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[pfx] Re: use object storage as message store
On 3/12/23 01:21, Bill Cole via Postfix-users wrote: > On 2023-03-12 at 00:03:32 UTC-0500 (Sun, 12 Mar 2023 00:03:32 -0500) > Phil Stracchino via Postfix-users > is rumored to have said: > >> On 3/11/23 19:04, pyh--- via Postfix-users wrote: >>> Hello list, >>> >>> Is it possible to use an object storage system (like aws's S3) to >>> store >>> message files? if this can be implemented we may have a more >>> persistent >>> storage for email. AFAIK aws's S3 has three replicas for each file in >>> their system by default. >> >> >> S3 really isn't intended to be used that way. I'm not sure how you'd >> make that work and it would probably be a bad idea. > > Agreed. > > As far as Postfix specifically is concerned (i.e. the queues) S3 would > be a performance disaster. Is this because Postfix is designed assuming that queue access has low latency, and therefore does not try to hide the latency with asynchronous operations and batching? -- Sincerely, Demi Marie Obenour (she/her/hers) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix as relay server let us send messages with anothyer domain than ours
On 4/11/23 17:24, Viktor Dukhovni via Postfix-users wrote: > On Tue, Apr 11, 2023 at 03:34:09PM -0300, Roberto Carna via Postfix-users > wrote: > >> But we have realized that if we send messages using another domains >> than ourdomain1.com, the messages reach the recipients in Gmail, >> Hotmail and other public mail platforms. > > Perhaps as well considering how to address this, you might also consider > whether you're addressing the right problem... > > When an authorised message is slated to leave your network, the > consequences are least signficant when it purports to originate from > somebody else's domain. > > - Many receiving systems are liable to reject a message purporting > to originate from an unexpected domain (based on DMARC, ...). > > - There's little risk of reputational or financial damage if > the message does not impersonate a sender in your domain. > > On the other hand, if the message *is* from your domain, but > is an unauthorised message misleading your customers or business > partners, ... *then* you have a problem. > > While Postfix can to some extent enforce envelope to sender mismatches, > the real concern is usually the "From:" header, ... whose content is not > the MSAs job to enforce. A milter must be used for this. Since this, along with DMARC, is a core responsibility of a modern MTA, I am curious if making this a part of Postfix itself (as Exim did) has been considered. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Reject mail by language
On 4/18/23 23:38, Viktor Dukhovni via Postfix-users wrote: > On Wed, Apr 19, 2023 at 11:33:36AM +0800, tom--- via Postfix-users wrote: > >> I got a lot of spams (20+ every day) like the following for which i even >> don't know what language they were. >> > >> مميز المنتدى العربي الثالث > > The script is Arabic. Language is harder for an MTA to deduce. A > priori any of > > - Arabic > - Farsi > - Urdu > - ... > > Though in this case actually Arabic. I'd focus more on the client IP, > sender domain, ... than the content language. If this is a private mail server for only a small number of people, any mail in a script that none of the users can read is almost guaranteed to be spam, and would not be useful even if it wasn’t. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
