[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] How to spot a competent developer

[Kolusion K via Postfix-users]

If you ever want to get an idea of how competent a developer is then I suggest 
looking no further at the quality of their documentation. My experience is that 
this is the best way to gauge how disciplined or lazy they are. :)

May the good lord bless you all and may we all pray for Trump in 2024!!
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: CVE-2023-51764

[Wietse Venema via Postfix-users]

Gerben Wierda via Postfix-users:
> Is
> 
> smtpd_data_restrictions =
> reject_unauth_pipelining,
> permit_mynetworks,
> permit_sasl_authenticated,
> reject_multi_recipient_bounce
> 
> enough to stop this small(?) risk (before I manage to upgrade)?

Please see https://www.postfix.org/smtp-smuggling.html#short

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

[pfx] Re: Behaviour in case of multiple relay hosts with multiple DNS records

[Wietse Venema via Postfix-users]

Peter Wienemann via Postfix-users:
> Dear Wietse,
> 
> thanks for your careful review.
> 
> On 2024-01-05 16:11:56 +0100, Wietse Venema via Postfix-users wrote:
> > Peter Wienemann via Postfix-users:
> >> smtp(8):
> >> 
> >> The Postfix SMTP+LMTP client supports multiple destinations separated
> >> by comma or whitespace (Postfix 3.5 and later). Delivery is tried in the
> >> specified order. For each individual destination the delivery rules of
> >> RFC 5321, Section 5.1 are applied.
> >> 
> > 
> > Unfortunately this says that RFC 5321 applies to LMTP deliveries,
> 
> RFC 2033 says: "The LMTP protocol is identical to the SMTP protocol 
> [SMTP] [HOST-REQ] with its service extensions [ESMTP], except as 
> modified by this document."

Indeed. The PROTOCOL FORMAT is similar to SMTP with small differences.

However the USAGE is completely different.

1 - RFC 2033 says that LMTP [...] MUST NOT be used on the TCP service
port 25.

2 - MX records specify where a domain receives email on the TCP
service port 25.

Therefore, MX records MUST NOT be used to locate an LMTP service.

I am not going into the rest of the responses. I will only state
that Postfix documentation is NOT A TUTORIAL for how email works.

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

[pfx] Regarding reject_unlisted_sender and preventing sender address spoofing

[Taco de Wolff via Postfix-users]

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 to postfix-users-le...@postfix.org

[pfx] Re: Behaviour in case of multiple relay hosts with multiple DNS records

[Viktor Dukhovni via Postfix-users]

On Fri, Jan 05, 2024 at 06:46:01PM +0100, Peter Wienemann via Postfix-users 
wrote:

> > Unfortunately this says that RFC 5321 applies to LMTP deliveries,
> 
> RFC 2033 says: "The LMTP protocol is identical to the SMTP protocol [SMTP]
> [HOST-REQ] with its service extensions [ESMTP], except as modified by this
> document."

But, in fact LMTP MX records are only for SMTP relay, and to not apply
to either submission or LMTP.

> I do not find any exceptions mentioned in RFC 2033 concerning the choice of
> target hosts. Therefore - to my understanding - the same target selection
> rules apply for SMTP and LMTP. If this is a misunderstanding on my part,
> please correct me.

They do not.  MX records specify the location of the inbound SMTP
servers for a domain, and there is no reason to expect to find the
associated LMTP servers at the same set of servers. 

In any case, LMTP delivery is a local matter (replacing ad-hoc local
delivery IPC mechanisms), and there is no reason for a sending domain
domain to connect to the LMTP servers of an unrelated domain, so the
resolution mechanism is unspecified.

Indeed, how exactly would you specify unix-domain sockets in MX records?
This is why LMTP nexthops are just transport end-points, not logical
destinations subject to MX lookup.

Since the RFC failed to note this distinction, the problem is with the RFC.

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

[pfx] CVE-2023-51764

[Gerben Wierda via Postfix-users]

Is

smtpd_data_restrictions =
reject_unauth_pipelining,
permit_mynetworks,
permit_sasl_authenticated,
reject_multi_recipient_bounce

enough to stop this small(?) risk (before I manage to upgrade)?

Gerben Wierda (LinkedIn , Mastodon 
)
R IT Strategy  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

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

[pfx] Re: Behaviour in case of multiple relay hosts with multiple DNS records

[Peter Wienemann via Postfix-users]

Dear Wietse,

thanks for your careful review.

On 2024-01-05 16:11:56 +0100, Wietse Venema via Postfix-users wrote:

Peter Wienemann via Postfix-users:

smtp(8):

The Postfix SMTP+LMTP client supports multiple destinations separated
by comma or whitespace (Postfix 3.5 and later). Delivery is tried in the
specified order. For each individual destination the delivery rules of
RFC 5321, Section 5.1 are applied.



Unfortunately this says that RFC 5321 applies to LMTP deliveries,


RFC 2033 says: "The LMTP protocol is identical to the SMTP protocol 
[SMTP] [HOST-REQ] with its service extensions [ESMTP], except as 
modified by this document."


I do not find any exceptions mentioned in RFC 2033 concerning the choice 
of target hosts. Therefore - to my understanding - the same target 
selection rules apply for SMTP and LMTP. If this is a misunderstanding 
on my part, please correct me.



and it ignores the possibility that SRV record lookups have been
enabled. I will keep the text that delivery is tried in the specified
order.


Yes, this is a valid point which I missed. Thanks for bringing this up.


transport(5):

This tries to deliver to bar.example (following the rules of RFC 5321,
Section 5.1) before trying to deliver to foo.example.



Here I think that the original text is more clear than the updated
text, which again implies that RFC 5321 applies to LMTP, 


In this case delivery via LMTP is explicitly excluded since this refers 
to the example:


example.com  smtp:bar.example, foo.example


and ignores
the possibility of SRV record lookups or [] MX overrides.


Yes, SRV record lookups would still be an option. [] MX overrides are 
incompatible with the given example.



Clearly, it is not desirable to enumerate all the SMTP client's
email delivery strategies here. Those strategies are orthogonal to
the issue of multiple destinations, and they do not belong here.


I like your comment. This gives rise to another option: Just refer to 
the delivery strategy described in smtp(8). This would solve all the 
problems mentioned above.


Although after re-reading smtp(8) in the given context, I think that the 
cases


a) There are no MX records
b) MX lookup is switched off
c) SRV lookups are enabled

are not covered in the "description" section either. At least cases b) 
and c) can be figured out by looking through subsequent sections. Case 
a) is also missing in the explanation of the "domainname:port" syntax in 
section "SMTP destination syntax".


Best regards,

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

[pfx] Re: Behaviour in case of multiple relay hosts with multiple DNS records

[Wietse Venema via Postfix-users]

Peter Wienemann via Postfix-users:
> Hi Viktor,
> 
> On 2024-01-02 18:13:22 +0100, Viktor Dukhovni via Postfix-users wrote:
> > That said, indeed the documentation is not explicit on this point, one
> > has to read "between the lines".  If your technical writing skills are
> > adequate, perhaps you could suggest some concise and clear text
> > explaining the semantics.
> > 
> > This would need to be added to smtp(8), transport(5) and postconf(5),
> > with multiple affected parameters in the last case.
> 
> here are my suggestions (I hope I provided enough existing context to 
> make it clear where to insert the new text):
> 
> smtp(8):
> 
> The Postfix SMTP+LMTP client supports multiple destinations separated
> by comma or whitespace (Postfix 3.5 and later). Delivery is tried in the 
> specified order. For each individual destination the delivery rules of 
> RFC 5321, Section 5.1 are applied.
> 

Unfortunately this says that RFC 5321 applies to LMTP deliveries,
and it ignores the possibility that SRV record lookups have been
enabled. I will keep the text that delivery is tried in the specified
order.

> transport(5):
> 
> This tries to deliver to bar.example (following the rules of RFC 5321, 
> Section 5.1) before trying to deliver to foo.example.
> 

Here I think that the original text is more clear than the updated
text, which again implies that RFC 5321 applies to LMTP, and ignores
the possibility of SRV record lookups or [] MX overrides.

Clearly, it is not desirable to enumerate all the SMTP client's
email delivery strategies here. Those strategies are orthogonal to
the issue of multiple destinations, and they do not belong here.

> postconf(5):
> 
> Multiple destinations are supported in Postfix 3.5 and later. In this 
> case delivery is tried in the specified order. For each individual 
> destination the rules of RFC 5321, Section 5.1 are applied.
> 

Same problem. The text "delivery is tried in the specified order"
is correct, the thext that follows is incomplete or misleading.

> What I do not like about the above suggestions is the fact that the MX 
> lookup part of RFC 5321 is skipped if the [] notation is used. Thus 
> strictly speaking the rules of RFC 5321 are only partially followed in 
> that case. But since the user explicitly requested Postfix to skip MX 
> lookup in those cases, I hope that the above additions introduce more 
> clarity than confusion.

There are many cases where MX lookup is not desirable. The most
common cases are the submiossion submoissions/smtps services; the
less common case is SRV lookups.

Wietse

> Of course it would be even better to explain the algorithm described in 
> RFC 5321 with a few words directly in the Postfix documentation rather 
> than refer to the RFC, but this would be really tough to achieve.
> 
> Best regards,
> 
> Peter
> ___
> 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 to postfix-users-le...@postfix.org

[pfx] Re: Behaviour in case of multiple relay hosts with multiple DNS records

[Peter Wienemann via Postfix-users]

Hi Viktor,

On 2024-01-02 18:13:22 +0100, Viktor Dukhovni via Postfix-users wrote:

That said, indeed the documentation is not explicit on this point, one
has to read "between the lines".  If your technical writing skills are
adequate, perhaps you could suggest some concise and clear text
explaining the semantics.

This would need to be added to smtp(8), transport(5) and postconf(5),
with multiple affected parameters in the last case.


here are my suggestions (I hope I provided enough existing context to 
make it clear where to insert the new text):


smtp(8):

The Postfix SMTP+LMTP client supports multiple destinations separated
by comma or whitespace (Postfix 3.5 and later). Delivery is tried in the 
specified order. For each individual destination the delivery rules of 
RFC 5321, Section 5.1 are applied.



transport(5):

This tries to deliver to bar.example (following the rules of RFC 5321, 
Section 5.1) before trying to deliver to foo.example.



postconf(5):

Multiple destinations are supported in Postfix 3.5 and later. In this 
case delivery is tried in the specified order. For each individual 
destination the rules of RFC 5321, Section 5.1 are applied.



What I do not like about the above suggestions is the fact that the MX 
lookup part of RFC 5321 is skipped if the [] notation is used. Thus 
strictly speaking the rules of RFC 5321 are only partially followed in 
that case. But since the user explicitly requested Postfix to skip MX 
lookup in those cases, I hope that the above additions introduce more 
clarity than confusion.


Of course it would be even better to explain the algorithm described in 
RFC 5321 with a few words directly in the Postfix documentation rather 
than refer to the RFC, but this would be really tough to achieve.


Best regards,

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