[2024-09-20 14:23] Christian Schulte <c...@schulte.it>
> On 20.09.24 11:38, Christian Schulte wrote:
> > On 20.09.24 10:41, Christian Schulte wrote:
> >> Hi,
> >>
> >> I am currently searching for way to enforce authentication for all mails
> >> sent from a domain the server is a mx for. For example:
> >>
> >> table domains { "domain.com", "domain.net", "domain.org" }
> >>
> >> action "local_mail" mbox
> >> action "outbound" relay
> >>
> >> match from domain <domains> !auth reject
> >> ^^^^^^^^^^^ not supported
> >>
Yes, there is no "from domain" in match, but there is "from mail-from"
which should work for your problem. Maybe you need a regex.
> > Replying to myself. Maybe OpenSMTPD could do this by default without any
> > configuration. It could just enforce by default that a mail sent from a
> > domain, for which it is a MX in DNS, needs to be transferred in a
> > session with some kind of authentication in effect - may that be by
> > certificate, user/password, whatever.
> >
>
> I am so glad I finally found a place I can talk to myself. It's really
> that easy. I'll send a patch implementing something like that sometime.
> On receiving a MAIL FROM command, just query DNS, after configured
> expansion/masquerading whatever, to see if the daemon is an MX for that
> domain and act in submission mode if so automatically without the need
> to change a single bit of the configuration grammar. Client connects,
> sends something from@domain, daemon checks whether it is setup as an MX
> for that domain in DNS and uses that information to switch to
> "submission" mode (require tls, authentication, add missing headers or
> validate, etc.).
I don't think this is a good idea to write such thing build in. Also
it souldn't be enabled by default. A better approach would be to
implement such a mx check as a table.
What I would like to have is a bit more flexibility about the address
matching for sender and recipient. First off all adding some domain
match for the sender domain. But also some local-part matching for
sender and recipient. But this is a bit triky to implement without
adding to mutch complexity.
Philipp
