[pfx] Re: managesieve filter not working

[John Fawcett via Postfix-users]

On 04/06/2024 11:18, Celal.Dikici via Postfix-users wrote:

Hello,
For the e-mail infrastructure we use roundcube 1.6.6 postfix 3.7.10, 
dovecot 2.3.19.1 installed on debian 12.05.  We use the larry theme as 
the interface. We use managesieve plugin for filtering. I have 
extracted some configurations below. Although the services are working 
properly, the filtering rules are not working. Although I have 
activated the Sieve logs, no negative logs are being sent. It is as if 
postfix/dovecot is not talking to managesieve. I wonder where I am 
doing wrong?

Thank you for your help.


Hi Celal

this is not a Postfix issue. You will probably find more help about 
sieve on the dovecot mailing list. Postfix itself does not have any 
direct interaction with managesieve or with sieve script interpreter.


I assume that you are using lmtp protocol to deliver email from postfix 
to dovecot. If that's the case then I guess you are missing the 
following dovecot setting for lmtp.


mail_plugins = $mail_plugins sieve

I'd also suggest checking which of your sieve scripts is active and 
therefore supposed to be running during mail delivery. The active one is 
pointed to by a link in the mail directory named dovecot.sieve.


John



___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Masters.cf

[John Fawcett via Postfix-users]

Sorry for following up on my own post, but I want to correct the record. 
Please disregard my previous email. I realize now I made a blunder 
during the analysis, since I was working on two similar questions one 
unrelated to postfix and I mixed up the data sets without realizing it. 
Sorry for the noise.


What I should have posted is that for postfix and xbl for submission 
service, if I take last 30 days of data, xbl blocked 100% of probes 24 
out of 30 days. When probes do get through they tend to do quite a few 
attempts at authenticating, often from the same ip address, so adding 
fail2ban on top has the potential (in my case) to bring the blocking to 
near 100%. The probes that get through generally seem low risk since 
they mainly but not always are for random and inexistent users.


One thing to bear in mind is that the number of probes explicitly 
blocked by xbl as evidenced by the logs may be lower than the number of 
probes being avoided by using it. This would be the case if the probe 
scripts have an adaptive behaviour, increasing the probes where they 
start getting real responses to AUTH and backing off if they get 
disconnected before AUTH.


John

On 29/05/2024 17:46, John Fawcett via Postfix-users wrote:



On 29/05/2024 14:07, Viktor Dukhovni via Postfix-users wrote:

On Wed, May 29, 2024 at 07:26:10AM -0400, John Hill via Postfix-users wrote:


The wrapper-mode TLS "smtps" rejects are naturally after the TLS
handshake.


    465    inet  n   -   n   -   -   smtpd
     -o smtpd_delay_reject=no
     -o {smtpd_client_restrictions=reject_rbl_client 
zen.spamhaus.org=127.0.0.4}
     -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
     ...

     submission inet  n   -   n   -   -   smtpd
     -o smtpd_delay_reject=no
     -o {smtpd_client_restrictions=reject_rbl_client 
zen.spamhaus.org=127.0.0.4}
     -o 
smtpd_relay_restrictions=permit_sasl_authenticated,permit_mynetworks,reject

All set up this way.
I will let it run overnight and see what hits.

Works like  a charm.

  1   SASL authentication failed ---

Only one.

Perhaps a bit of luck?  For me, the XBL only catches around 10% of the
SASL probes.  May your luck hold up.


The majority of the probes I see that are not stopped by XBL are 
relatively harmless and don't get to try the AUTH command. They mainly 
come from ips that repeat in a short space of time (where potentially 
fail2ban could be used) and


  * fail in the starttls for protocol or cipher issues
  * disconnect without issuing starttls so never get to the AUTH command
  * try issuing AUTH without starttls so get disconnected for too many
invalid commands

The cases I have where AUTH has been tried and failed are relatively 
few. They mainly come from fast varying ips so fail2ban is not that 
useful unless I want to start banning based on a single probe. They 
usually appear to target specific existing users.


John



___
Postfix-users mailing list --postfix-users@postfix.org
To unsubscribe send an email topostfix-users-le...@postfix.org___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Masters.cf

[John Fawcett via Postfix-users]

On 29/05/2024 14:07, Viktor Dukhovni via Postfix-users wrote:

On Wed, May 29, 2024 at 07:26:10AM -0400, John Hill via Postfix-users wrote:


The wrapper-mode TLS "smtps" rejects are naturally after the TLS
handshake.


    465    inet  n   -   n   -   -   smtpd
     -o smtpd_delay_reject=no
     -o {smtpd_client_restrictions=reject_rbl_client 
zen.spamhaus.org=127.0.0.4}
     -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
     ...

     submission inet  n   -   n   -   -   smtpd
     -o smtpd_delay_reject=no
     -o {smtpd_client_restrictions=reject_rbl_client 
zen.spamhaus.org=127.0.0.4}
     -o 
smtpd_relay_restrictions=permit_sasl_authenticated,permit_mynetworks,reject

All set up this way.
I will let it run overnight and see what hits.

Works like  a charm.

  1   SASL authentication failed ---

Only one.

Perhaps a bit of luck?  For me, the XBL only catches around 10% of the
SASL probes.  May your luck hold up.


The majority of the probes I see that are not stopped by XBL are 
relatively harmless and don't get to try the AUTH command. They mainly 
come from ips that repeat in a short space of time (where potentially 
fail2ban could be used) and


 * fail in the starttls for protocol or cipher issues
 * disconnect without issuing starttls so never get to the AUTH command
 * try issuing AUTH without starttls so get disconnected for too many
   invalid commands

The cases I have where AUTH has been tried and failed are relatively 
few. They mainly come from fast varying ips so fail2ban is not that 
useful unless I want to start banning based on a single probe. They 
usually appear to target specific existing users.


John

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Masters.cf

[John Fawcett via Postfix-users]

On 29/05/2024 02:18, John Hill via Postfix-users wrote:


On 5/28/24 8:10 PM, John Hill via Postfix-users wrote:


On 5/28/24 8:00 PM, Bill Cole via Postfix-users wrote:

On 2024-05-28 at 19:18:10 UTC-0400 (Tue, 28 May 2024 19:18:10 -0400)
John Hill via Postfix-users 
is rumored to have said:
[...

On 5/28/24 7:13 PM, Bill Cole via Postfix-users wrote:

On 2024-05-28 at 19:04:37 UTC-0400 (Tue, 28 May 2024 19:04:37 -0400)
John Hill via Postfix-users 
is rumored to have said:

[...]

Sending of the message failed.
An error occurred while sending mail. The mail server responded:
: Sender address rejected: Email blocked by 
security policy.
Please check the message recipient "postfix-users@postfix.org" 
and try again.


What does the log say about that attempt?

I believe that specific text indicates a problem in 
smtpd_sender_restrictions.


May 28 19:02:04 proteus.noach.com opendmarc[504352]: ignoring 
connection from gibson.noach.com
May 28 19:02:04 proteus.noach.com postfix/submission/smtpd[504893]: 
discarding EHLO keywords: CHUNKING
May 28 19:02:04 proteus.noach.com postfix/submission/smtpd[504893]: 
Anonymous TLS connection established from 
gibson.noach.com[192.168.200.253]: TLSv1.3 with cipher TLS_AES_128_GC
M_SHA256 (128/128 bits) key-exchange X25519 server-signature 
RSA-PSS (2048 bits) server-digest SHA256
May 28 19:02:04 proteus.noach.com postfix/submission/smtpd[504893]: 
discarding EHLO keywords: CHUNKING
May 28 19:02:09 proteus.noach.com postfix/submission/smtpd[504893]: 
NOQUEUE: reject: RCPT from gibson.noach.com[192.168.200.253]: 554 
5.7.1 : Sender address rejec
ted: Email blocked by security policy; from= 
to= proto=ESMTP helo=<[192.168.200.253]>
May 28 19:02:09 proteus.noach.com postfix/submission/smtpd[504893]: 
too many errors after RCPT from gibson.noach.com[192.168.200.253]
May 28 19:02:09 proteus.noach.com postfix/submission/smtpd[504893]: 
disconnect from gibson.noach.com[192.168.200.253] ehlo=2 starttls=1 
auth=1 mail=1 rcpt=0/1 commands=5/6


It's not something in smtpd_sender_restrictions, but this is as the 
log says, a *Sender* stage failure. I don't see an XBL hit (which 
makes sense, given the private client address) or anything 
indicating a failure at the EHLO or client phases. I see from 
earlier in the thread that you have smtpd_sender_login_maps set and 
"Email blocked by security policy" seems like something you might 
get from that lookup failing. The session summary shows that you did 
authenticate but I see no indication of what your SASL login was. I 
suspect that if you perform a query on your database for the sender 
'jh...@noach.com' it will not return whatever login you 
authenticated as.
I also thought for a moment that the problem was due to having 
'permit_my_networks' before 'permit_sasl_authenticated' in 2 
restriction lists and you hence never needing to authenticate, but 
the session summary says otherwise. Note that if all of your 
submission clients use authentication, permit_my_networks is 
unnecessary.


I do not have a solution handy for you, but you have at least gotten 
beyond the XBL issue. It seems possible that you only need to 
harmonize the login used for authentication in Thunderbird with that 
in your sender login map database.


Yes close, I'll figure it out, trial and error!


Thanks

--john

this worked - I think
 -o 
smtpd_recipient_restrictions=permit_sasl_authenticated,reject_rbl_client=zen.spamhaus,org=127.0.0.4,reject



I added and = after reject_rbl_client=



--john

I doubt it. By the time smtpd_recipient_restrictions is evaluated there 
is the possibility that AUTH attempts have already been allowed. Benny's 
suggestion elsewhere in this thread looks correct to me (substituting 
his rbl with zen and return code 127.0.0.4).


John

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Masters.cf

[John Fawcett via Postfix-users]

On 29/05/2024 01:11, Bill Cole via Postfix-users wrote:

On 2024-05-28 at 18:50:11 UTC-0400 (Wed, 29 May 2024 00:50:11 +0200)
John Fawcett via Postfix-users 
is rumored to have said:

[...]

Hi John

I think you are missing the following in master.cf for the submission 
service


-o smtpd_delay_reject=no

Without that the smtpd_client_restrictions will not be evaluated when 
the client connects and so you will allow the connected client to try 
authentication.


That is not what is happening here. The order of restrictions within 
the same restriction list matters, and Postfix is careful about logic. 
If you put permit_sasl_authenticated ahead of reject_rbl_client, the 
permit must be able to   take effect without evaluating the reject 
condition. That demands allowing as many AUTH commands as your other 
config will allow to fail.



Hi Bill

You're right that the order matters and the reject_rbl_client should be 
the first restriction in smtpd_client_restrictions for the submission 
service. Actually it is probably the only one that is really needed.


I may be wrong but I don't believe that specifying 
permit_sasl_authenticated influences behaviour in allowing AUTH 
attempts. I believe it will just evaluate to permitting the access if at 
the time of the evaluation the user is authenticated.


John

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Masters.cf

[John Fawcett via Postfix-users]

On 29/05/2024 00:27, John Hill via Postfix-users wrote:


On 5/28/24 4:50 PM, John Hill via Postfix-users wrote:


On 5/28/24 4:43 PM, Benny Pedersen via Postfix-users wrote:

John Hill via Postfix-users skrev den 2024-05-28 22:12:

On 5/28/24 3:38 PM, Benny Pedersen via Postfix-users wrote:

John Hill via Postfix-users skrev den 2024-05-28 21:14:


I had dumped the configs but here is what I had.


submission inet n   -   y   -   - smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_delay_reject=no
  -o { smtpd_client_restrictions = reject_rbl_client 
auth.spamrats.com=127.0.0.43, permit }
  -o { smtpd_relay_restrictions = permit_mynetworks, 
permit_sasl_authenticated, reject }


https://www.spamrats.com/postfix-configuration.php

works for me :)


Does this look correct. I'm not getting a error, waiting to see if 
it works.!


submission inet  n   -   n   -   - smtpd
  2 -o smtpd_hard_error_limit=1
  3 -o stress=yes
  4 -o syslog_name=postfix/submission
  5 -o smtpd_etrn_restrictions=reject
  6 -o smtpd_sasl_auth_enable=yes
  7 -o smtpd_sasl_type=dovecot
  8 -o smtpd_sasl_path=private/auth
  9 -o smtpd_sasl_security_options=noanonymous
 10 -o smtpd_sasl_tls_security_options=noanonymous
 11 -o 
{smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_rbl_client 
xbl.spamhaus,org=127.0.0.4, reject}
 12 -o 
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject

 13 -o smtpd_helo_restrictions=permit_mynetworks,permit
 14 -o smtpd_tls_security_level=encrypt
 15 -o 
smtpd_sender_login_maps=mysql:/etc/postfix/mysql-email2email.cf

 16 -o milter_macro_daemon_name=ORIGINATING
 17

--john


unneeded complicated

line: 2 5 7 8 9 10 13 15 fits better in main.cf

spamrats allow sending mail when recipient is only local

with your config its rejected


I have been sending mail from local/remote authenticated clients?

--john 
 11 -o 
{smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_rbl_client 
xbl.spamhaus,org=127.0.0.4, reject}


reject_rbl_client doing nothing.

SASL logon fails ips are in manually found in XBL

Postscreen spamhaus blocks work.

postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11] for port 25


--john


Hi John

I think you are missing the following in master.cf for the submission 
service


-o smtpd_delay_reject=no

Without that the smtpd_client_restrictions will not be evaluated when 
the client connects and so you will allow the connected client to try 
authentication.


Personally I use zen.spamhaus.org=127.0.0.4 for submission, but I'm not 
sure that makes any difference respect to xbl.spamhaus.org=127.0.0.4.


Also please check your settings in the config files. In the email above 
I see a comma in xbl.spamhaus,org instead of a dot. If you copied it 
from the config then the config is wrong.


John
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: SASL reject force disconnect

[John Fawcett via Postfix-users]

On 28/05/2024 11:39, Christophe Kalt via Postfix-users wrote:
On Sun, May 26, 2024 at 5:57 AM John Fawcett via Postfix-users 
 wrote:


For submission I only use xbl (return code 127.0.0.4) excluding
other other data contained in zen like pbl that lists isp dynamic
ip ranges from which you would normally expect to get connections
to submission. For me it's safe to use xbl for submission since I
don't want connections from exploited machines and it cuts out
most of the noise and some of the risk from people hammering smtp
auth. It won't fit everyone's use case though.

For this to be worthwhile, I assume you also set smtpd_delay_reject to 
no ?


___
Postfix-users mailing list --postfix-users@postfix.org
To unsubscribe send an email topostfix-users-le...@postfix.org


yes, I set it in master.cf just for submission service.

John
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: SASL reject force disconnect

[John Fawcett via Postfix-users]

On 27/05/2024 13:31, John Hill via Postfix-users wrote:



On 5/27/24 4:13 AM, Matus UHLAR - fantomas via Postfix-users wrote:

> postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11]



John Hill via Postfix-users:

Is this the same thing?


On 25.05.24 15:54, Wietse Venema via Postfix-users wrote:

See https://www.spamhaus.org/faqs/dnsbl-usage/#200 for a table
with the purpose of different lookup results.

To block xbl listed clients with postscreen, one would configure
xbl.spamhaus.org or zen.spamhaus.org=127.0.0.4


While they are the same, I recommend using the latter, so you can 
benefit from caching DNS results in case the same source IP connects 
to smtp and submission/submissions(=smtps) services.


I added the zen,spamhaus,org=127.0.0.[2..11 to my submission settings 
in master.cf. Worked, but it blocked my AT mobile block. Go figure!


That's to be expected. The zen.spamhaus.org list also contains isp 
dynamic ip ranges which can be users that need to access submission.


I changed it to 127.0.0.4 to be more specific. It turns out AT 
mobile has numbers is in the XBL database. I tried bl.spamcop.net, and 
it does nothing.


If AT  is blocked when checking specifically for 127.0.0.4 then the ip 
is in XBL, but that would mean there is a likely to be an exploited 
device on that ip. I would not recommend using spamcop or other general 
purpose spam blocking lists for this purpose. XBL is specific for 
compromised hosts.


Last night I logged  "81 SASL authentication failed." That's about 
average. Seems I have a lot of new friends.


I'm still thankful to learn more about master.cf, I had ignored it for 
the most part.


--john


___
Postfix-users mailing list --postfix-users@postfix.org
To unsubscribe send an email topostfix-users-le...@postfix.org___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: SASL reject force disconnect

[John Fawcett via Postfix-users]

On 25/05/2024 20:50, John Hill via Postfix-users wrote:



On 5/25/24 11:22 AM, John Fawcett via Postfix-users wrote:


On 24/05/2024 03:03, John Hill via Postfix-users wrote:
I learn something every time I read this group, when I can keep up 
with the conversation!


I had auth on ports I did not need. I use auth on submission port 
587, for users access.


I do get a boat load of failed login attempts on 587. Funny how a 
China, US, Argentina, you name it, hosts, will try the same failed 
username password at nearly the same time.


Small world.

I use Fail2Ban to block the failed IP. The script writes it into the 
nftables table immediately.


I think this keeps Postfix waiting and times out, not a big deal. Is 
there a cli that my bash script could force disconnect the ip from 
Postfix?


I did search the man page and the docs, sorry if I missed it.

Thanks

--john



Hi John

maybe controversial for use on the submission service, but a while 
back I started using spamhaus xbl (the exploits data only, not the 
PBL or spammer data) as the first check (reject_rbl_client) in 
smtpd_client_restrictions for the submission service (on which I have 
AUTH enabled only after STARTTLS). I saw two results


1. there are few illegitimate smtp auth attempts that aren't blocked 
by XBL and end up trying the credentials


2. even the blocked traffic has fallen off to a small number of tries 
per day (usually < 20).


Point 2 tends to indicate that the hacker scripts only start 
hammering when they find an AUTH command enabled.


Fail2ban can still be used for the ips that get through, since then 
they start hammering, but the cases are so limited I haven't bothered.


John





I use zen.spamhaus.net in postscreen.



postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11]

Is this the same thing?
--john


___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


___
Postfix-users mailing list --postfix-users@postfix.org
To unsubscribe send an email topostfix-users-le...@postfix.org


postscreen is protecting the smtp service (port 25). I also use the zen 
configuration you have above in postscreen, (i.e. including the other 
data not just xbl) since I am more aggressive for smtp.


For submission I only use xbl (return code 127.0.0.4) excluding other 
other data contained in zen like pbl that lists isp dynamic ip ranges 
from which you would normally expect to get connections to submission. 
For me it's safe to use xbl for submission since I don't want 
connections from exploited machines and it cuts out most of the noise 
and some of the risk from people hammering smtp auth. It won't fit 
everyone's use case though.


John
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: How to allow only one specific sender to use smtp ?

[John Fawcett via Postfix-users]

On 25/05/2024 23:58, Mike via Postfix-users wrote:

Hello,

My setup like below:

I have Postfix setup and use dovecot as SASL. Now, all email accounts 
can use the smtp server to send emails. I want to allow only one email 
account to send out emails and rest of others can only use POP3 or IMAP.


How can I make that?

Thanks

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


Hi Mike

as mentioned elsewhere in the thread you could use the sasl backend to 
do this.


For example if using dovecot sasl for the authentication with sql 
backend (and probably with ldap too though I didn't try that), dovecot 
has a %s variable that will be set to the service name (smtp, pop3, imap 
etc) and you can use that variable in the sql query to have different 
responses depending on user and service.


John


___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: SASL reject force disconnect

[John Fawcett via Postfix-users]

On 24/05/2024 03:03, John Hill via Postfix-users wrote:
I learn something every time I read this group, when I can keep up 
with the conversation!


I had auth on ports I did not need. I use auth on submission port 587, 
for users access.


I do get a boat load of failed login attempts on 587. Funny how a 
China, US, Argentina, you name it, hosts, will try the same failed 
username password at nearly the same time.


Small world.

I use Fail2Ban to block the failed IP. The script writes it into the 
nftables table immediately.


I think this keeps Postfix waiting and times out, not a big deal. Is 
there a cli that my bash script could force disconnect the ip from 
Postfix?


I did search the man page and the docs, sorry if I missed it.

Thanks

--john



Hi John

maybe controversial for use on the submission service, but a while back 
I started using spamhaus xbl (the exploits data only, not the PBL or 
spammer data) as the first check (reject_rbl_client) in 
smtpd_client_restrictions for the submission service (on which I have 
AUTH enabled only after STARTTLS). I saw two results


1. there are few illegitimate smtp auth attempts that aren't blocked by 
XBL and end up trying the credentials


2. even the blocked traffic has fallen off to a small number of tries 
per day (usually < 20).


Point 2 tends to indicate that the hacker scripts only start hammering 
when they find an AUTH command enabled.


Fail2ban can still be used for the ips that get through, since then they 
start hammering, but the cases are so limited I haven't bothered.


John



___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Dovecot logging to files causes postfix to break

[John Fawcett via Postfix-users]

On 18/05/2024 18:18, Richard Rosner via Postfix-users wrote:

Am 18.05.24 um 17:55 schrieb Wietse Venema:

Richard Rosner via Postfix-users:

I have a mailing server setup based on Debian Stable that uses
postfix for IMAP and SMTP and dovecot for internel mail handling,

You mean, Postfix for SMTP, Dovecot for IMAP.

Possible.



like filtering, sorting into users inboxes etc. I now wanted to
set dovecot to not write to syslog, but to dedicated files in
/var/log/dovecot. While everything indicates that this happens
successfully, postfix will soon start logging complaints:

 May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9:
 to=, relay=local, delay=3.2, 
delays=1.9/0.29/0/1.1,

 dsn=4.3.0, status=deferred (temporary failure. Command output:
 lda(user): Error: net_connect_unix(/run/dovecot/stats-writer)
 failed: Permission denied Can't open log file
 /var/log/dovecot/error.log: Permission denied )
That is a DOVECOT error message from the DOVECOT local delivery agent 
(lda).


Wietse


Why does it say postfix/local though? So you are sure this error can't 
have been caused by any interaction with postfix?



Richard


Hi Richard

though probably not relevant to your current issue, one thing to watch 
out for with the approach you are using is the value of postfix 
parameter postfix mailbox_size_limit. This value applies to all files 
written by the lda process that postfix spawns, not just the mailbox 
files, so also applies to log file sizes.


John

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: client checks with suspect IPs

[John Fawcett via Postfix-users]

On 16/01/2024 20:28, Alex via Postfix-users wrote:

Hi,

I need help with making a decision involved in determining whether to 
add an IP to my client_checks to bypass a blocklist entry on the 
Barracuda blocklist that is impacting one of our users. The problem is 
that this would also bypass the checks for other Zix hosted customers.


Jan 16 12:04:30 xavier postfix-118/postscreen[1006916]: NOQUEUE: 
reject: RCPT from  74.203.184.40]:3602: 550 5.7.1 Service unavailable; 
client [74.203.184.40] blocked using DNS Blocklist (barracuda); 
from=, to=, 
proto=ESMTP, helo=http://zh-gw.zixsmbhosted.com>>


I was also thinking I could add a sender_check for users at 
myclient.com  domain only, but that didn't work. 
The above entry relates to a client reject, but shouldn't a 
sender_check involving myclient.com  work as well?


smtpd_client_restrictions =
        permit_mynetworks,
        check_client_access ${indexed}client_checks,
        check_client_access pcre:$config_directory/client_checks.pcre,
        check_reverse_client_hostname_access 
pcre:$config_directory/reverse_client_hostname_access.pcre,

        check_client_access cidr:$config_directory/client_access_blocklist

/etc/postfix-118/client_checks.pcre:
/74\.203\.184\.40/                      OK

smtpd_sender_restrictions =
        permit_mynetworks,
        check_sender_access ${indexed}sender_checks,
        check_sender_access pcre:$config_directory/sender_checks.pcre,
        reject_unknown_sender_domain

/etc/postfix-118/sender_checks.pcre:
/myclient\.com/             permit

Any ideas greatly appreciated.


Hi Alex

that rejection is happening in postscreen, before handing off to smtpd 
so anything you configure in smtpd is not going to allow this email to 
pass. You'll at least need to allow this ip in the postscreen 
configuration for it to get to smtpd.


John
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: relay_domains override for smtpd

[John Fawcett via Postfix-users]

On 16/01/2024 18:12, Marc Dierksen via Postfix-users wrote:

Salutations,

I am running Postfix 3.5.23 on Debian 11 as an edge mailserver that 
accepts mails on port 25 for a list of domains defined as 
relay_domains in the main.cf.


I am currently trying to setup a second smtpd process on port 587 that 
accepts mails only for local recipients.


I have added the following entry to the master.cf:

587    inet  n   -   y   -   -   smtpd
    -o relay_domains=
    -o content_filter=
    -o 
receive_override_options=no_unknown_recipient_checks,no_address_mappings,no_header_body_checks,no_milters

    -o smtpd_helo_restrictions=
    -o smtpd_client_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_relay_restrictions=
    -o 
smtpd_recipient_restrictions=permit_mynetworks,reject_unauth_destination

    -o mynetworks=127.0.0.0/8

The idea is that the reject_unauth_destination will reject all mails 
except for local recipients because relay_domains is empty.


Problem is mails for all the domains defined as relay_domains in the 
main.cf are still accepted.


If I set relay_domains to empty in the main.cf it works as expected.

So it seems to me the '-o relay_domains=' parameter for smtpd does not 
work correctly. According to the man page of smtpd however it should 
be supported.


Am I overlooking something?


Hi Marc

I'm probably missing something, but what would be the advantage of 
setting up a separate smtpd processes for this?  Out of curiosity how 
are these emails being sent to port 587?


One suggestion is to customize the syslog name of the new smtpd instance 
in master.cf so as to easily distinguish the logging that comes from the 
two processes.


  -o syslog_name=postfix/submission

Could you show the log entries of what you are seeing when email arrives 
on port 587?


Thanks

John



___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: recipient_bcc_maps clarification.

[John Fawcett via Postfix-users]

On 08/01/2024 05:54, anant--- via Postfix-users wrote:

Hello,

We have in main.cf always_bcc = zz...@xx.com and our domain is xx.com

For specific 2 recipients of our domain, we don't want always_bcc to 
be implemented.  ie. if a mail is addressed to a...@xx.com  (our domain 
only), mail should not be Bcc to zz...@xx.com. similarly if mail 
recipient is d...@xx.com (our domain only), mail should not be Bcc to 
zz...@xx.com.  For all others always_bcc to continue.


So, in summary, main.cf

always_bcc = zz...@xx.com
recipient_bcc_maps=regexp:/etc/postfix/regexp_recipient_bcc


#regexp_recipient_bcc

#/etc/postfix/regexp_recipient_bcc

a...@xx.com    a...@xx.com
d...@xx.com    d...@xx.com

Whether the above configuration will enable to get desired results? 
ie. always_bcc should not work for a...@xx.com and d...@xx.com and 
instead the mails are delivered to a...@xx.com and d...@xx.com only.



H Anant

I don't think that will work: if you try it I think you will find you 
get two copies of the email to a...@xx.com and d...@xx.com and still get 
all mails copied to zz...@xx.com without achieving the aim because the 
copy will alzo go to zz...@xx.com i.e. these are all cumulative 
configurations.


You will need to eliminate the always_bcc configuration since you don't 
always want all email to be bcced. You should only have the 
recipient_bcc_maps configured.


Since this map is searched according to the search order indicated here 
https://www.postfix.org/postconf.5.html#recipient_bcc_maps you could try 
to map the more specific addresses to /dev/null and have a domain wide 
bcc for the rest.


In order to do it and depending on how your domains are configured you 
might need a local alias in the aliases file to send mail to /dev/null 
file, e.g.


devnull:    /dev/null

Then you can use that as bcc destination for those addressed that should 
skip bcc copies.


#/etc/postfix/regexp_recipient_bcc

a...@xx.com    devnull
d...@xx.com    devnull
@xx.com    zz...@xx.com

Postfix will still generate bcc messages for emails to abc and def but 
they won't actually get sent out.


best regards

John

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Regarding reject_unlisted_sender and preventing sender address spoofing

[John Fawcett via Postfix-users]

On 05/01/2024 19:44, Taco de Wolff via Postfix-users wrote:

Hi,

I'm trying to understand how the reject_unlisted_sender option works 
in the smtpd_sender_restrictions option. This is what I understand it 
to do:


For any received mail (it is an smtpd option after all), either for 
receiving mail from an external server or for sending mail from a 
logged in user with SASL, it checks whether the sender domain 
(envelope FROM) is a valid recipient address (ie. in my case the 
domain exists in the virtual_mailbox_domains) for this server, and if 
it is not it will reject.


When testing however, it was accepting mail from an external server 
(gmail) to be delivered to an existing mailbox, but the sender domain 
was x...@gmail.com which is not a listed sender for my server 
obviously! Why are these mails not rejected? I don't want them to be 
rejected, but it is what I understood reject_unlisted_sender to do.


My goal is to prevent spoofing of the envelope FROM (since we can't 
control the header FROM from Postfix) for outgoing mail, I do this by 
setting smtpd_sender_login_maps and adding 
reject_sender_login_mismatch to the smtpd_sender_restrictions. This 
works perfectly for SASL authenticated users by forcing the envelope 
FROM to be the same as the login username (u...@domain.com), and I 
think the reject_unlisted_sender option would be redundant in this 
case. However, mail delivered locally (sendmail from system or from 
PHP) is not checked by the smtpd options, and I need a way to force 
the envelope sender for certain system users to 
nore...@primary-domain-of-user.com so that a PHP application can't 
spoof the envelope FROM when using sendmail. I use `sendmail -f 
nore...@primary-domain-of-user.com --` as the PHP sendmail_path, but 
I'd like to force this in Postfix for security.


Regarding spoofing of the header FROM, if they use a different domain 
name than their envelope FROM (whether it is a permitted sender for 
the server or not), the destination server will likely reject it due 
to invalid DKIM. This is something I'll take up with the milter 
(rspamd) that does the DKIM signing, to reject any mail that it cannot 
DKIM sign. It will be possible to use a different local part: 
int...@example.com could impersonate himself as ad...@example.com (not 
sure if that is something I want to fix).


Kind regards,
Taco de Wolff

___
Postfix-users mailing list --postfix-users@postfix.org
To unsubscribe send an email topostfix-users-le...@postfix.org


Hi Taco

you might find the address class readme useful in this context 
https://www.postfix.org/ADDRESS_CLASS_README.html#classes.


A reject_unlisted_recipient that worked as you are suggesting, that can 
reject x...@gmail.com, would not be useful since your server cannot have 
the list of potentially valid senders for domains that are not managed 
by your server. Such addresses are in the "default domain class" which 
does not have any "valid recipient" table.


The thing to note about reject_unlisted_sender is that it rejects the 
senders that would be rejected as recipients by 
reject_unlisted_recipient. i.e. it rejects senders that would not be 
valid recipients on your server.


So if address aaa@yourdomain does not exist on your server 
reject_unlisted_sender would reject it. If address bbb@yourdomain does 
exist reject_unlisted_sender would not reject it.


So if you are aiming to prevent forgeries ariving via smtp at port 25 
then reject_unlisted_sender will do this for a subset (those that are 
not valid addresses for your server). If you want to prevent all 
forgeries, you'd need to set up a sender access table with e REJECT 
action for your domain(s), and obviously not apply that to submission. 
However that could break some legitimate use cases, such as mail forwarding.


As for adding security to php use of sendmail, sendmail does not enforce 
the kind of controls you want. If you are concerned about forgeries from 
php then it is best to disable the use of sendmail from php or 
substitute the php sendmail setting with something custom that peforms 
the controls you want before invoking sendmail.


If you disable sendmail from php that way people will have to 
authenticate to your submission service from php to send emails.


John








___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: 25 years today

[John Fawcett via Postfix-users]

On 14/12/2023 14:20, Wietse Venema via Postfix-users wrote:

As a few on this list may recall, it is 25 years ago today that the
"IBM secure mailer" had its public beta release. This was accompanied
by a nice article in the New York Times business section.


Thanks Wietse and to all who have contributed.

Apart from being the only MTA software I'd want to use, this project 
stands out for its exemplary software engineering from design to 
implementation and for the dedication to it's support and evolution.


Happy anniversary Wietse and everyone!

John

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org