So, the internal email domain is used by both servers sending in email
alerts/reports (to the sys-ops) and by users for internal organisation
communication. Those users that require external email access also have
an email account in an externally-facing domain, and usually use the
appropriate domain when sending email. Occasionally, an internal domain
email gets accidentally sent out on the Internet, and of course, replies
to that mis-sent email bounce. So we'd like to stop that from happening
(hence my Q).
Also occasionally, an internal email user sets up a forwarding to an
externally-facing domain (still within the organisation/lan - usually
their externally-facing organisation email), plus sometimes internal
emails are CC'd to organisation-specific externally facing domains. So
while filtering on submission sounds like it might be the way to go, we
have to ensure that emails to/from user_x@example.internal can still
reach use...@example.com, etc, but not user_z@somewhere_on_the_internet.com
Yeah, its a rather complicated set-up - and I've tried to
streamline/simplify things, but management want to keep using the
existing set-up, so...
Does that help explain things?
And thanks muchly for the help :-)
On 25/1/25 20:30, Viktor Dukhovni via Postfix-users wrote:
On Sat, Jan 25, 2025 at 10:06:36AM +0100, Tomasz Pala via Postfix-users wrote:
Emails are permitted to be sent between all three domains.
I would try:
master.cf:
smtpd [...]
-o virtual_mailbox_domains=example.com,example.org
This does not do what you think it does, because the classification of
addresses into address classes happens in the trivial-rewrite service,
not in smtpd(8). Best to not jump-in and reply with "I would try", if
you don't actually have an answer.
main.cf:
virtual_mailbox_domains=example.com,example.org,example.internal
To effect access control, access(5) checks should be used.
On Sat, Jan 25, 2025 at 10:15:57AM +0100, Tomasz Pala via Postfix-users wrote:
If that doesn't work - different approach, using only restrictions,
e.g.
smtpd_recipient_restrictions = permit_mynetworks [...]
reject_unauth_destination
check_recipient_access hash:/etc/$config_directory/my_domains
This is closer, but the OP's main problem is stopping internal senders
from reaching the public Internet. For that it would be appropriate
to know how and whether internal senders are actually authenticated
when submitting new messages. And are particular users always in
a particular domain, or do they wear multiple hats with some mail
authorised to be sent, and some not from the very same user.
Restricting outbound mail is best handled at submission, rather than on
gateway systems, where the envelope sender may not accurately reflect
who is sending the mail, or in what capacity.
The relevant access(5) primitive is: "check_sender_access", and one may
be able to set an "action" for some envelope sender domains that is
"reject_unauth_destination". But without a better problem statement,
it is unclear whether this is the right approach.
--
PEREGRINE IT Pty Ltd Signature
*Matthew J BLACK*
M.Inf.Tech.(Data Comms)
MBA
B.Sc.
MACS (Snr), CP, IP3P
When you want it done /right/ ‒ the first time!
Phone: +61 4 0411 0089
Email: matt...@peregrineit.net <mailto:matt...@peregrineit.net>
Web: www.peregrineit.net <http://www.peregrineit.net>
View Matthew J BLACK's profile on LinkedIn
<http://au.linkedin.com/in/mjblack>
This Email is intended only for the addressee. Its use is limited to
that intended by the author at the time and it is not to be distributed
without the author’s consent. You must not use or disclose the contents
of this Email, or add the sender’s Email address to any database, list,
or mailing list unless you are expressly authorised to do so. Unless
otherwise stated, PEREGRINE I.T. Pty Ltd accepts no liability for the
contents of this Email except where subsequently confirmed in writing.
The opinions expressed in this Email are those of the author and do not
necessarily represent the views of PEREGRINE I.T. Pty Ltd. This Email is
confidential and may be subject to a claim of legal privilege.
If you have received this Email in error, please notify the author and
delete this message immediately.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
