Re: Postconf and postmap in check_policy_service scripts
Matus UHLAR - fantomas: I was curious if I could do a script that would do the same, with the same possible issues. I can do perl, but it looks neither python nor perl have interface to postfix what could e.g. expand maps without calling external commands. On 01.07.21 22:49, Kevin N. wrote: Among other things, it mainly acted as a proxy between Postfix and Dovecot's quota-status to make sure that the quota query was done for a real user instead of an alias. The word "proxy" brought me to an idea that process probably could communicate with proxymap to read from tables, it would just need to load table names from postconf at start and reload. would that be possible? If so, it looks like the proxymap processes are restarted quite often, does that mean that we don't need to detect if postfix is loaded, just reload config when connection to proxymap fails? One solution is when the table is in a real database (sql, etc.) then you could use perl/pythobn/etc bindings. Accessing Berkeley DB from perl or python may be possible but they should adhere to the locking protocols that Postfix uses, typically FCNTL-style shared locks for reading. I was told it will be migrated to a real database but since it is used only internally it wasn't high on the priorities list :) . in my case it's not planned. -- 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. WinError #98652: Operation completed successfully.
Re: Search for free MX Backup Service
On 2021-07-02 07:54, Maurizio Caloro wrote: Searching any Service that offer free any possible MX Backup? Found kisolabs "dot" com but it seems this service are down perfekt for testing backup mx :=) Thanks for possible update or help you could do self service with another postfix server with longer postconf -d maximal_queue_lifetime it defaults to 5 days if you really need backup mx then extend this setting to more days on the backup mx server, dont trust other severs then your own if you can fix all in less then 5 days you dont need backup mx another reason for not have a backup mx is that spammers try to abuse this backup mx more then the main server in hope its less secured by less rbl / milter content filtering then the main server is all in all dont use backup mx if not needed
Postfix / Dovecot SASL
On http://www.postfix.org/SASL_README.html it says: To find out what SASL implementations are compiled into Postfix, use the following commands: % postconf -a (SASL support in the SMTP server) % postconf -A (SASL support in the SMTP+LMTP client) On our RHEL 8 server, postfix 3.5.8-1, dovecot 2.3.8-9, the responses are: % postconf -a cyrus dovecot % postconf -A cyrus Checking installed packages, we find cyrus-sasl cyrus-sasl-gssapi cyrus-sasl-lib cyrus-sasl-plain all 2.1.27-5 Does this mean that smtpd_sasl_type should be "cyrus" if we want to use LMTP ? Does this also mean that the rest of the Dovecot SASL setup described on the page is worthless ? Thanks.
Re: Postconf and postmap in check_policy_service scripts
Matus UHLAR - fantomas: > >>Matus UHLAR - fantomas: > >>>I was curious if I could do a script that would do the same, with the same > >>>possible issues. > >>> > >>>I can do perl, but it looks neither python nor perl have interface to > >>>postfix > >>>what could e.g. expand maps without calling external commands. > > On 01.07.21 22:49, Kevin N. wrote: > >Among other things, it mainly acted as a proxy between Postfix and > >Dovecot's quota-status to make sure that the quota query was done for > >a real user instead of an alias. > > The word "proxy" brought me to an idea that process probably could > communicate with proxymap to read from tables, it would just need to load > table names from postconf at start and reload. > > would that be possible? No, because proxymap is an internal protocol, and Postfix supports only programs that use the external protocols (SMTP, UNIX mailbox, maildir, $home/.forward, and lookup tables). You can safely use socketmap: and tcp: Postfix map types if you need to talk to a different program. There was an incompatible internal protocol change in Postfix 3.7. This would definitely break all programs that look under the Postfix hood, but has no impact on programs that use only supported methods. Wietse
Re: Postconf and postmap in check_policy_service scripts
>>Matus UHLAR - fantomas: >>>I was curious if I could do a script that would do the same, with the same >>>possible issues. >>> >>>I can do perl, but it looks neither python nor perl have interface to postfix >>>what could e.g. expand maps without calling external commands. On 01.07.21 22:49, Kevin N. wrote: >Among other things, it mainly acted as a proxy between Postfix and >Dovecot's quota-status to make sure that the quota query was done for >a real user instead of an alias. Matus UHLAR - fantomas: The word "proxy" brought me to an idea that process probably could communicate with proxymap to read from tables, it would just need to load table names from postconf at start and reload. would that be possible? On 02.07.21 09:10, Wietse Venema wrote: No, because proxymap is an internal protocol, and Postfix supports only programs that use the external protocols (SMTP, UNIX mailbox, maildir, $home/.forward, and lookup tables). You can safely use socketmap: and tcp: Postfix map types if you need to talk to a different program. There was an incompatible internal protocol change in Postfix 3.7. This would definitely break all programs that look under the Postfix hood, but has no impact on programs that use only supported methods. so we're stuck with calling postmap externally for now -- 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. Save the whales. Collect the whole set.
smtp_tls*_protocols and !TLSv1
:-)
Maybe seems strange but...
With those settings my postfix (3.5.9) no broken connections are reported:
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1.1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1.1
But when I change to those:
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
from time to time sessions from some reputable and presumably well
configured mail servers are terminated during the SSL negotiation phase
with "SSL_accept error". It looks like '!TLSv1' is seen as something
like "!TLSv1.x" ("no TLS 1.x at all") rather than "!TLSv1.0". Yes it is
a stupid supposition but I cannot think of any other explanation. Is it
possible?
Best regards,
Marek
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Postfix / Dovecot SASL
White, Daniel E. (GSFC-770.0)[NICS]: > On http://www.postfix.org/SASL_README.html > it says: > > To find out what SASL implementations are compiled into Postfix, use the > following commands: > > % postconf -a (SASL support in the SMTP server) > % postconf -A (SASL support in the SMTP+LMTP client) > > On our RHEL 8 server, postfix 3.5.8-1, dovecot 2.3.8-9, the responses are: > > % postconf -a > cyrus > dovecot The above are for RECEIVING email. It IS NOT for DELIVERING email. > % postconf -A > cyrus And the above is for DELIVERING email. It IS NOT for RECEIVING email. > Checking installed packages, we find > cyrus-sasl > cyrus-sasl-gssapi > cyrus-sasl-lib > cyrus-sasl-plain > > all 2.1.27-5 > > Does this mean that smtpd_sasl_type should be "cyrus" if we want > to use LMTP ? No. The smtpd_xxx parameters are for RECEIVING email. The LMTP protocol is for DELIVERING email. > Does this also mean that the rest of the Dovecot SASL setup described > on the page is worthless ? No. That text covers RECEIVING email. LMTP is for DELVERING email. Wietse
Re: smtp_tls*_protocols and !TLSv1
On Fri, Jul 02, 2021 at 03:14:58PM +0200, Marek Kozlowski wrote:
> It looks like '!TLSv1' is seen as something like
> "!TLSv1.x" ("no TLS 1.x at all") rather than "!TLSv1.0". Yes it is a stupid
> supposition but I cannot think of any other explanation. Is it possible?
No, !TLSv1 means no TLS 1.0.
The reason is more simple: there exist virtually no TLSv1.1
implementations as 1.2 was published only two years later, but there
still exist quite some TLSv1.0 implementations in legacy systems. So
all still existing systems support either 1.0, 1.2 or 1.3 (usually
including all the older versions as well.)
Bastian
--
I'm a soldier, not a diplomat. I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9
Re: smtp_tls*_protocols and !TLSv1
On Fri, Jul 02, 2021 at 03:14:58PM +0200, Marek Kozlowski wrote:
It looks like '!TLSv1' is seen as something like
"!TLSv1.x" ("no TLS 1.x at all") rather than "!TLSv1.0". Yes it is a stupid
supposition but I cannot think of any other explanation. Is it possible?
On 02.07.21 15:56, Bastian Blank wrote:
No, !TLSv1 means no TLS 1.0.
The reason is more simple: there exist virtually no TLSv1.1
implementations as 1.2 was published only two years later, but there
still exist quite some TLSv1.0 implementations in legacy systems. So
all still existing systems support either 1.0, 1.2 or 1.3 (usually
including all the older versions as well.)
I would better say, that nearly all implementation that support tlsv1.1
support also tlsv1.2.
However, there's no point in allowing tlsv1.0 but not tlsv1.1.
server-server connections should support tlsv1.0 as well, client connections
are often required to support at least tlsv1.2
smtpd_tls_mandatory_protocols is used on ports where TLS is mandatory, which
usually means ports used by clients.
smtpd_tls_protocols is used where TLS is not mandatory, which mostly means
for server connections.
this it's mostly safe to put
smtpd_tls_protocols=!SSLv2,!SSLv3
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3,!TLSv1
or even
smtpd_tls_protocols=!SSLv2,!SSLv3
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSV1.1
--
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.
Depression is merely anger without enthusiasm.
Re: smtp_tls*_protocols and !TLSv1
:-)
On 7/2/21 3:56 PM, Bastian Blank wrote:
On Fri, Jul 02, 2021 at 03:14:58PM +0200, Marek Kozlowski wrote:
It looks like '!TLSv1' is seen as something like
"!TLSv1.x" ("no TLS 1.x at all") rather than "!TLSv1.0". Yes it is a stupid
supposition but I cannot think of any other explanation. Is it possible?
No, !TLSv1 means no TLS 1.0.
The reason is more simple: there exist virtually no TLSv1.1
implementations as 1.2 was published only two years later, but there
still exist quite some TLSv1.0 implementations in legacy systems. So
all still existing systems support either 1.0, 1.2 or 1.3 (usually
including all the older versions as well.)
But on the other hand it's hard to believe than some servers with a good
reputation (according to https://talosintelligence.com) of reputable
American universities still don't support TLS 1.2 nor 1.3... Do you
suggest... they haven't upgraded their mail servers for over a decade?
So I'm a bit confused.
Best regards,
Marek
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Postfix / Dovecot SASL
No. The smtpd_xxx parameters are for RECEIVING email. The LMTP protocol is for DELIVERING email. No. That text covers RECEIVING email. LMTP is for DELVERING email. Maybe im over stating the obvious, but i can see how there could be some ambiguity mentioned here. In this context saying that LMTP is for delivering mail, just to clarify, it's not delivering mail like you are sending out an email from you to another service (like from y...@nasa.gov to some...@gmail.com) although with some tweaking you could. But delivering in the sense that the email just received by postfix is being delivered to the users mail box. [Internet] -smpt-> [postfix] -LMTP-> [dovecot] -OS-filesave-> [inbox storage]
Re: Postfix / Dovecot SASL
% postconf -A (SASL support in the SMTP+LMTP client) I might be wrong, but I think that part of the document is actually referring to the LMTP protocol in general and not necesarily to Dovecot's LMTPD server. https://en.wikipedia.org/wiki/Local_Mail_Transfer_Protocol Cheers, K.
Re: Postfix / Dovecot SASL
On Fri, Jul 02, 2021 at 10:15:53AM -0400, post...@ptld.com wrote: > > No. The smtpd_xxx parameters are for RECEIVING email. > > The LMTP protocol is for DELIVERING email. > > > > No. That text covers RECEIVING email. LMTP is for DELVERING email. > > Maybe im over stating the obvious, but i can see how there could be some > ambiguity mentioned here. Postfix has an SMTP server (smtpd(8)) and an SMTP/LMTP client (smtp(8) and lmtp(8) are the same program under two names). The documentation of "postconf -[Aa]" makes the appropriate distinctions: -a List the available SASL plug-in types for the Postfix SMTP server. The plug-in type is selected with the smtpd_sasl_type -- configuration parameter by specifying one of the names listed below. cyrus This server plug-in is available when Postfix is built -- with Cyrus SASL support. dovecot This server plug-in uses the Dovecot authentication -- server, and is available when Postfix is built with any form of SASL support. This feature is available with Postfix 2.3 and later. -A List the available SASL plug-in types for the Postfix SMTP client. The plug-in type is selected with the smtp_sasl_type -- or lmtp_sasl_type configuration parameters by specifying one of the names listed below. cyrus This client plug-in is available when Postfix is built with Cyrus SASL support. This feature is available with Postfix 2.3 and later. The SMTP server receives mail from another mail handling system into the Postfix queue. The SMTP and LMTP client deliver mail mail from the Postfix queue to another mail handling system. -- Viktor.
forged sender addresses from my domain
:-) I'd like to disable any mail from 'my.domain' from external networks and non authenticated users. For envelope addresses my solution works and is as follows: At first bind valid addresses with their owners: smtpd_sender_restrictions = ... reject_sender_login_mismatch, ... But this setting works for existing addresses only. That means that mail from: qwertyuiop1234567890@my.domain still won't be rejected here. So the second restriction is: list1 = check_client_access hash:/etc/postfix/list_of_my_networks, reject smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/file1 ... /etc/postfix/file1: my.domain list1 /etc/postfix/list_of_my_networks 1.2 OK 3.4 OK I'm not sure if it's the simplest solution but works fine... for the envelope. I'm wondering if I could apply the same during the DATA phase for the 'from:' field? Would be nice if you could do that similarly without involving any other filters / milters. Is it possible? Best regards, Marek smime.p7s Description: S/MIME Cryptographic Signature
Re: forged sender addresses from my domain
:-) I'd like to disable any mail from 'my.domain' from external networks and non authenticated users. For envelope addresses my solution works and is as follows: At first bind valid addresses with their owners: Precisely: smtpd_sender_restrictions = check_sender_acces ... check_client_access ... reject_sender_login_mismatch, for some exceptions for the print server and some special pseudo-users. Best regards, /m smime.p7s Description: S/MIME Cryptographic Signature
Re: forged sender addresses from my domain
I'd like to disable any mail from 'my.domain' from external networks Do you mean this literally? Stopping me from sending an email using my mail server that claims to be from 'your.domain'? You can't, you can only publish SPF records and hope the receiving mail server of the spoofed email rejects it based on those records. Or do you mean just preventing users on your mail server from sending a spoofed from address? In that case reject_sender_login_mismatch does this completely on its own. But this setting works for existing addresses only. That means that mail from: qwertyuiop1234567890@my.domain still won't be rejected here. Unless i misunderstand what you mean, this is not true. reject_sender_login_mismatch can be setup to only allow emails being sent out where the from, not just the envelope-from, has to match the users login credentials. Meaning no email can be sent that doesn't have a user/password associated with it.
Re: forged sender addresses from my domain
:-) On 7/2/21 5:02 PM, post...@ptld.com wrote: Do you mean this literally? Stopping me from sending an email using my mail server that claims to be from 'your.domain'? You can't, you can only publish SPF records and hope the receiving mail server of the spoofed email rejects it based on those records. Or do you mean just preventing users on your mail server from sending a spoofed from address? In that case reject_sender_login_mismatch does this completely on its own. OK, small clarification: I'd like to disable any mail from 'my.domain' from external networks and non authenticated users... ...delivered to my users. /m smime.p7s Description: S/MIME Cryptographic Signature
Re: forged sender addresses from my domain
OK, small clarification: I'd like to disable any mail from 'my.domain' from external networks and non authenticated users... ...delivered to my users. Making sure i understand, you are saying you want to stop me from using my mail server from sending an email to one_of_your_users@your.domain claiming to be from you@your.domain? That can be does with SPF records. You publish records that says only your mail server is authorized to send emails on behalf of @your.domain, then you use something like "check_policy_service unix:private/spfpolicy" to deny any email claiming to be from @your.domain that wasn't sent from your mail server IP.
Re: forged sender addresses from my domain
reject_sender_login_mismatch can be setup to only allow emails being sent out where the from, not just the envelope-from, has to match the users login credentials Are you sure? The documentation only mentions the MAIL FROM address.
Re: forged sender addresses from my domain
On 2021-07-02 17:05, Marek Kozlowski wrote: I'd like to disable any mail from 'my.domain' from external networks and non authenticated users... ...delivered to my users. basicly all local senders in recipient maps is forged senders on port 25 ? easy to fix :=) with postfixadmin: check_sender_access proxy:pgsql:/path-to-sql-maps/virtual_alias_maps result from this map most return REJECT 5.5.x Forged sender in port 25 is not allowed poormanns spf check without dns this check must not be done for sasl auth users more help needed ?, show logs
Re: forged sender addresses from my domain
:-) On 7/2/21 5:10 PM, post...@ptld.com wrote: OK, small clarification: I'd like to disable any mail from 'my.domain' from external networks and non authenticated users... ...delivered to my users. Making sure i understand, you are saying you want to stop me from using my mail server from sending an email to one_of_your_users@your.domain claiming to be from you@your.domain? That can be does with SPF records. You publish records that says only your mail server is authorized to send emails on behalf of @your.domain, Of course I do. then you use something like "check_policy_service unix:private/spfpolicy" to deny any email claiming to be from @your.domain that wasn't sent from your mail server IP. For some reasons I'd like not to apply restrictive SPF checking. For envelopes my simple solution works perfectly without SPF. How about internal "from:" Best regards, /m smime.p7s Description: S/MIME Cryptographic Signature
Re: forged sender addresses from my domain
On 2021-07-02 17:14, Marek Kozlowski wrote: For some reasons I'd like not to apply restrictive SPF checking. For envelopes my simple solution works perfectly without SPF. How about internal "from:" milters is needed for this one reject if from is local not signed, but this is breaked by maillists that breaks dkim :/
Re: forged sender addresses from my domain
On 07-02-2021 11:13 am, Damian wrote: reject_sender_login_mismatch can be setup to only allow emails being sent out where the from, not just the envelope-from, has to match the users login credentials Are you sure? The documentation only mentions the MAIL FROM address. I think im sure. Here is a real case from my mail logs today. Ofcourse myemail@ was replaced, otherwise everything else is the same. connect from static-host119-73-117-17.link.net.pk[119.73.117.17] NOQUEUE: reject: RCPT from static-host119-73-117-17.link.net.pk[119.73.117.17]: 550 5.7.23 : Recipient address rejected: SPF rejected because SPF fail - not authorized; from= to= proto=ESMTP helo= lost connection after RCPT from static-host119-73-117-17.link.net.pk[119.73.117.17] disconnect from static-host119-73-117-17.link.net.pk[119.73.117.17] ehlo=1 mail=1 rcpt=0/1 commands=2/3 Am i wrong and the from= is actually the envelope from or is it checking against the from address?
Re: forged sender addresses from my domain
Are you sure? The documentation only mentions the MAIL FROM address. Oops, my last reply was on SPF receiving and now i see you were talking about sending out login mismatched. My understanding is that it verifies the from and not just the envelope from, but if im wrong id like to know.
Re: forged sender addresses from my domain
On 2021-07-02 17:22, post...@ptld.com wrote: Am i wrong and the from= is actually the envelope from or is it checking against the from address? this is check_policy_service not reject_sender_login_mismatch
Suggestion for changing error message
Hi, Recently I was confronted with an error message like: Can't write to /var/spool/mail/BLADDDIBLA It took me another hour or so to find out why not. It would be helpful if the error message would read something like: Can't wite to /var/spool/mail/BLADIBLA, mailboxsize exceeded This would make solving the problem a lot quicker. Thanks Adrian -- Adri P. van Bloois "The greatest threat to our planet is the belief that someone else will save it." Robert Swan.
Re: Suggestion for changing error message
Adrian van Bloois: > Hi, > Recently I was confronted with an error message like: > Can't write to /var/spool/mail/BLADDDIBLA > It took me another hour or so to find out why not. > It would be helpful if the error message would read something like: > Can't wite to /var/spool/mail/BLADIBLA, mailboxsize exceeded > > This would make solving the problem a lot quicker. As discussed in off-list mail, this error message is from code that is not part of the official Postfix distribution. This list is therefore the wrong place to complain about this. Wietse
Re: smtp_tls*_protocols and !TLSv1
On 2021-07-02 at 10:04:29 UTC-0400 (Fri, 2 Jul 2021 16:04:29 +0200) Marek Kozlowski is rumored to have said: But on the other hand it's hard to believe than some servers with a good reputation (according to https://talosintelligence.com) of reputable American universities still don't support TLS 1.2 nor 1.3... Do you suggest... they haven't upgraded their mail servers for over a decade? So I'm a bit confused. While few systems survive without any patching for a decade, it's quite common for a mail server's underlying OS and its TLS library to have not had a major version update since before the platform supported TLSv1.2. RHEL 6 and its derivatives are still in wide use, as are FreeBSD versions prior to v10 that still have OpenSSL 0.9.8* in the base install and old Windows versions without recent TLS support. Whether it's inattention, a devotion to stability, or lack of support capacity, many places just don't do updates that aren't largely automated. I confess to still having one stubborn old FreeBSD 8 machine in production, due to customers who have not invested in maintaining custom software. It doesn't send mail to the world using the base OpenSSL, but I can understand how people can keep old systems in use long past their proper expiration dates. It is also important to understand that what you see as a 'mail server' offering you mail from a large organization may very well be strictly a SMTP client as far as the outside world is concerned, e.g. an old Exchange 2003 mail hub behind a firewall whose only access to the outside world is to send mail on port 25. With the risks of using TLSv1.0 for a SMTP client being negligible to non-existent, updating a commercial package with a significant cost may never happen. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: forged sender addresses from my domain
On 7/2/21 11:05 AM, Marek Kozlowski wrote: > :-) > > On 7/2/21 5:02 PM, post...@ptld.com wrote: >> >> Do you mean this literally? Stopping me from sending an email using my >> mail server that claims to be from 'your.domain'? >> You can't, you can only publish SPF records and hope the receiving mail >> server of the spoofed email rejects it based on those records. >> >> Or do you mean just preventing users on your mail server from sending a >> spoofed from address? In that case reject_sender_login_mismatch does >> this completely on its own. > > OK, small clarification: > > I'd like to disable any mail from 'my.domain' from external networks and > non authenticated users... > > ...delivered to my users. So what you REALLY mean is, you want to reject incoming mail from senders forging your domain name. Try something like this: main.cf: smtpd_sender_restrictions = permit_mynetworks ... check_sender_access lmdb:/etc/postfix/sasl_authenticated check_sender_access lmdb:/etc/postfix/block-local-sender block-local-sender: my.domain REJECT Fake local sender address is not allowed -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
Re: forged sender addresses from my domain
On 2021-07-02 at 10:46:07 UTC-0400 (Fri, 2 Jul 2021 16:46:07 +0200) Marek Kozlowski is rumored to have said: :-) I'd like to disable any mail from 'my.domain' from external networks and non authenticated users. For envelope addresses my solution works and is as follows: At first bind valid addresses with their owners: smtpd_sender_restrictions = ... reject_sender_login_mismatch, ... But this setting works for existing addresses only. That means that mail from: qwertyuiop1234567890@my.domain still won't be rejected here. So the second restriction is: list1 = check_client_access hash:/etc/postfix/list_of_my_networks, reject smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/file1 ... /etc/postfix/file1: my.domain list1 /etc/postfix/list_of_my_networks 1.2 OK 3.4 OK You've already got 'permit_mynetworks' ahead of this, so why the complexity? The best practice in the modern world is to have your legitimate users connect via port 465 (TLS-wrapped) or port 587 (STARTTLS) and authenticate. With that in place, you can disable authentication on port 25 and just reject anyone on port 25 claiming to be one of your uses in the envelope. It is also best to not use 'permit_mynetworks' unless you have to support senders who cannot do authentication on a submission port. I'm not sure if it's the simplest solution but works fine... for the envelope. I'm wondering if I could apply the same during the DATA phase for the 'from:' field? Would be nice if you could do that similarly without involving any other filters / milters. Is it possible? You COULD use header_checks IF you are willing to force all submission to submission ports, but I don't recommend it. Unless you are willing to forbid your users from submitting mail to mailing lists such as this one which send messages back with the From header unmodified, you will need something a before-queue body filter (i.e. a milter) to do more complicated logic to determine which might be valid uses of your domain in a From header. This is part of what DMARC was designed to fix but it really hasn't done so, rather it has broken a lot of mailing lists. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: forged sender addresses from my domain
On 2021-07-02 21:37, Phil Stracchino wrote: main.cf: smtpd_sender_restrictions = permit_mynetworks ... check_sender_access lmdb:/etc/postfix/sasl_authenticated whould be check_sasl_accesss imho check_sender_access lmdb:/etc/postfix/block-local-sender list of local recicpients that is forged if not using sasl block-local-sender: my.domain REJECT Fake local sender address is not allowed reuse virtual-alias-maps just with changed result if sqlite database have , then value can be mapped with same key with diffrent result, so is same on both check_mumble_access
Re: Search for free MX Backup Service
On 01 Jul 2021, at 23:54, Maurizio Caloro wrote: > > Searching any Service that offer free any possible MX Backup? MX backups are a legacy of 30-40 years ago when it was very common to have machines that only periodically connected to the Internet. There are many reasons they are a bad idea in a modern context, and having a third party be a alternate path for your mail is a particularly bad idea. The real question is why do you think you need a backup MX? IMO, if you really do need a backup MX (and I doubt very much you do) then the only reasonable way to do it is to have a second server under your control to act as backup. The better solution, nearly alway¹, is to have two mail servers that share a spool and both act in a load-balanced way that is basically invisible to the sending transport. ¹ Nearly always means "in every case I can think of, but there might be some case I have not thought of." -- When someone is impatient and says, "I haven't got all day," I always wonder, How can that be? How can you not have all day?
www.postfix.org site appears to be down.
When going to https://www.postfix.org I get, after an invalid certificate error, > Apache Software Foundation Distribution Directory > > The directories linked below contain current software releases from the > Apache Software Foundation projects. Older non-recommended releases can be > found on our archive site. And a long list of folders for various apache.org projects. Nothing about postfix on the page. Thinking it might be my connection (Comcast Business), I checked from another Internet connection using a different ISP (CenturyLink, or whatever they are called now) with the same results. OTOH, using T-Mobile, all appears fine. Trace routes from both connections get to uu-router.customer.surf.net (different IPs) and then stall out. I can't trace route on T-Mobile. -- people didn't seem to be able to remember what it was like with the elves around. Life was certainly more interesting then, but usually because it was shorter. And it was more colourful, if you liked the colour of blood. --Lords and Ladies
Re: www.postfix.org site appears to be down.
On 03/07/2021 07:48, @lbutlr wrote: When going to https://www.postfix.org I get, after an invalid certificate error,... The correct address is http://www.postfix.org (no https...)
