[pfx] Re: strict access restrictions and bounces

2024-03-25 Thread Jaroslaw Rafa via Postfix-users
Dnia 25.03.2024 o godz. 16:11:47 Daniel Marquez-Klaka via Postfix-users pisze:
> 2 postfix mail server, one, mail-server1, is connected to the
> internet, the second,
> calling it list-server1, which serves a few mailing lists, is only
> reachable thru
> mail-server1.
> 
> On mail-server1 a transport map entry sends everything for
> @list-dom.de to list-server1,
> list-server1 does his work and sends all back to mail-server1 which
> then delivers to
> the final destination.
> 
> On list-server1, to prevent the whole world sending mails, I have
> installed a
> check_sender_access map to accept a few allowed domains, reject
> everything else.

I don't understand what is actually your scenario and what exactly are you
trying to prevent.

>From what you write, I assume that only mail-server1 is open to receive mail
from the Internet, and it forwards only messages that should reach
list-server1 to that server. I assume list-server1 does not accept mails
directly from the Internet, so there is no possibility of "whole world
sending mails" to it. (If it isn't the case, then just block list-server1
from receiving mails from anywhere except mail-server1 using
check_client_access).

Maybe you want the people who are not subscribed to the mailing lists on
list-server1 to not be able to send mail to those lists? But you can do this
directly on mailing list level, every mailing list software has controls
that allow to specify who is able to send to the list (usually the choice is
everyone/subscribers only/moderators only, sometimes additionally you can
block or allow particular senders).

So please describe more clearly, what do you actually want to do.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: strict access restrictions and bounces

2024-03-25 Thread Viktor Dukhovni via Postfix-users
On Mon, Mar 25, 2024 at 04:11:47PM +0100, Daniel Marquez-Klaka via 
Postfix-users wrote:

> I have a problem with check_sender_access that I can't find a solution to.
>
> 2 postfix mail server, one, mail-server1, is connected to the
> internet, the second, calling it list-server1, which serves a few
> mailing lists, is only reachable thru mail-server1.
> 
> On mail-server1 a transport map entry sends everything for
> @list-dom.de to list-server1, list-server1 does his work and sends all
> back to mail-server1 which then delivers to the final destination.
> 
> On list-server1, to prevent the whole world sending mails, I have
> installed a check_sender_access map to accept a few allowed domains,
> reject everything else.

The problem is self-inflicted, the access checks are in the wrong place.
The access(5) checks need to be implemented *at* the edge relay
(server1), not the downstream list server.

> ... bounces, as the are send with empty FROM (<>), as I understand to
> prevent loops, get rejected to. This is a problem because nobody will
> ever notice if there are dead emails in a list. Also, automatic bounce
> handling (I am using mailman3 on list-server1)
> will never do anything.

The vast majority of bounces will happen at the outbound edge relay,
when remote systems reject the outgoing mail.  These will not run into
any access check issues, once they're implemented in the right place.

Some bounces will be remote, you can use a milter to process remote
bounces, parsing the bounce multipart/report.

Bottom line, all filters belong on the relay, not the internal server.

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


[pfx] Re: strict access restrictions and bounces

2024-03-25 Thread Matus UHLAR - fantomas via Postfix-users

On 25.03.24 16:11, Daniel Marquez-Klaka via Postfix-users wrote:
I have a problem with check_sender_access that I can't find a solution 
to.


My setup actually works very well with the exception of bounce handling.
More on that later, first to describe my setup:

2 postfix mail server, one, mail-server1, is connected to the 
internet, the second,
calling it list-server1, which serves a few mailing lists, is only 
reachable thru

mail-server1.

On mail-server1 a transport map entry sends everything for 
@list-dom.de to list-server1,
list-server1 does his work and sends all back to mail-server1 which 
then delivers to

the final destination.

On list-server1, to prevent the whole world sending mails, I have 
installed a
check_sender_access map to accept a few allowed domains, reject 
everything else.


 8< 
smtpd_sender_restrictions = check_sender_access 
regexp:/etc/postfix/config/access_sender,

 reject
 8< 

access_sender file:

 8< 
/^([a-z0-9_=\.-]+)@dom1.de/OK
/^([a-z0-9_=\.-]+)@dom2.de/OK
/^([a-z0-9_=\.-]+)@dom3.de/   OK


are you trying to limit allowed characters for local part of address in 
those domains?


I'd recommend simple hash map, containing "dom1.de", "dom2.de", "dom3.de" 
- you need not (probably should not) to use regular expressions for 
everything




 8< 

All fine so far, but...

... bounces, as the are send with empty FROM (<>), as I understand to 
prevent loops,
get rejected to. This is a problem because nobody will ever notice if 
there are dead
emails in a list. Also, automatic bounce handling (I am using mailman3 
on list-server1)

will never do anything.

 8< 
: host 10.245.16.24[10.245.16.24] said: 554 
5.7.1 <>:
   Sender address rejected: Access denied (in reply to MAIL FROM 
command)

 8< 


add "<>" or whatever you have defined as smtpd_null_access_lookup_key as 
another allowed sender.


http://www.postfix.org/postconf.5.html#smtpd_null_access_lookup_key


with 10.245.16.24 being list-server1

After all googleing and manual reading I have done, I can't find a 
solution and hope someone

can point me into the right direction.



--
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.
Linux IS user friendly, it's just selective who its friends are...
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: How to set the minimum number of bits for (non-EC) DH key exchange?

2024-03-25 Thread Viktor Dukhovni via Postfix-users
On Mon, Mar 25, 2024 at 09:24:23AM +0100, Alexander Leidinger wrote:
> thought-chain could be:

> IF there is no MITM, and IF the session is encrypted, then at least use good
> encrpytion so that an attacker which is only able to listen, is not able to
> get the content.

But, in that case, the vast majority of servers will advertise a DH
group of 2048-bits or more.  Refusing to complete the TLS handshake
will result in a cleartext delivery.

> Also: this is not a specific recommendation for SMTP, it is a generic
> recommendation for encrypted communication independent from the context it
> is used in, so there may be no thought at all about opportunistic TLS.

Exactly, and even then the general case is much too strict in many
contexts, not just opportunistic TLS in SMTP.  Often, the content is not
very sensitive, and communication at "adequate" security levels takes
priority over a maximal security posture.

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


[pfx] strict access restrictions and bounces

2024-03-25 Thread Daniel Marquez-Klaka via Postfix-users

Hello List,

I have a problem with check_sender_access that I can't find a solution 
to.


My setup actually works very well with the exception of bounce handling.
More on that later, first to describe my setup:

2 postfix mail server, one, mail-server1, is connected to the internet, 
the second,
calling it list-server1, which serves a few mailing lists, is only 
reachable thru

mail-server1.

On mail-server1 a transport map entry sends everything for @list-dom.de 
to list-server1,
list-server1 does his work and sends all back to mail-server1 which then 
delivers to

the final destination.

On list-server1, to prevent the whole world sending mails, I have 
installed a
check_sender_access map to accept a few allowed domains, reject 
everything else.


 8< 
smtpd_sender_restrictions = check_sender_access 
regexp:/etc/postfix/config/access_sender,

  reject
 8< 

access_sender file:

 8< 
/^([a-z0-9_=\.-]+)@dom1.de/OK
/^([a-z0-9_=\.-]+)@dom2.de/OK
/^([a-z0-9_=\.-]+)@dom3.de/   OK
 8< 

All fine so far, but...

... bounces, as the are send with empty FROM (<>), as I understand to 
prevent loops,
get rejected to. This is a problem because nobody will ever notice if 
there are dead
emails in a list. Also, automatic bounce handling (I am using mailman3 
on list-server1)

will never do anything.

 8< 
: host 10.245.16.24[10.245.16.24] said: 554 
5.7.1 <>:
Sender address rejected: Access denied (in reply to MAIL FROM 
command)

 8< 

with 10.245.16.24 being list-server1

After all googleing and manual reading I have done, I can't find a 
solution and hope someone

can point me into the right direction.

Thanks in advance,
Daniel

--
Anything that is unrelated to elephants is irrelephant.___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: How to set the minimum number of bits for (non-EC) DH key exchange?

2024-03-25 Thread Alexander Leidinger via Postfix-users

Am 2024-03-23 17:17, schrieb Viktor Dukhovni via Postfix-users:

PS: As of January 2024, the German BSI has tighten its recommendation
for asymmetric algorithms over finite fields to at least 3000 bits
(i.e. RSA encryption, RSA signatures and FFDH).


With little thought about the opportunistic TLS use-case.


I'm not claiming to know what the rationale is, but one possible 
thought-chain could be:
IF there is no MITM, and IF the session is encrypted, then at least use 
good encrpytion so that an attacker which is only able to listen, is not 
able to get the content.


Also: this is not a specific recommendation for SMTP, it is a generic 
recommendation for encrypted communication independent from the context 
it is used in, so there may be no thought at all about opportunistic 
TLS.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


signature.asc
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: How to set the minimum number of bits for (non-EC) DH key exchange?

2024-03-25 Thread Alexander Leidinger via Postfix-users

Am 2024-03-23 15:58, schrieb Matthias Nagel via Postfix-users:

I wonder whether setting `smtpd_tls_dh1024_param_file` to a custom 
2048-bit DH group would help? But from my understanding of the docs 
that should not be necessary as Postfix 3.8.5 uses a built-in 2048bit 
group if left empty.


Postfix doesn't complain if you configure it this way (I tried). I don't 
know if it does what you want to do (I have a custom cipher spec I 
allow).


You could install a test-instance and test with nmap:
 - "nmap -p  --script ssl-enum-ciphers ", pay attention 
to the part "(dh ...)" in the output


Do a scan before and after the smtpd_tls_dh1024_param_file change.

PS: As of January 2024, the German BSI has tighten its recommendation 
for asymmetric algorithms over finite fields to at least 3000 bits 
(i.e. RSA encryption, RSA signatures and FFDH).


If this is as a result of an audit, or in preparation of an audit: have 
a look if it helps to talk with the auditors. Sometimes they are open to 
arguments (cleartext is allowed, dh 1024 is better than cleartext). If 
they only look at checkboxes to tick, see the part above or disabling 
the parts as you suggested (you could increase the smtpd_tls_loglevel to 
1 and check over a suitable amount of time if someone is using those 
ciphers you want to disable before you actually disable them).


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


signature.asc
Description: OpenPGP digital signature
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org