Hi,

in a BSD standard setup (MTA runs on [::]:25 or [::1]:25,
/usr/sbin/sendmail as MSA connects to [::1]:25 to deliver
locally-submitted mail), is there a way to make some
mailboxen “local-only” (i.e. allow mail delivery from
the local system only but not from the internet)?

I have access_db, so I guess I can do a…

To:foobar@example.org ERROR:"550 No delivery here."

… but do I need special handling to allow local submission to work,
or is a different way correct?

bye,
//mirabilos
--
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Thorsten Glaser wrote:

> in a BSD standard setup (MTA runs on [::]:25 or [::1]:25,

Which *BSD? Free, Open, Net, ???

> /usr/sbin/sendmail as MSA connects to [::1]:25 to deliver

It should connect to port 587.

> locally-submitted mail), is there a way to make some
> mailboxen "local-only" (i.e. allow mail delivery from
> the local system only but not from the internet)?

Of course, but you probably need "custom rules" - In Local_check_rcpt
check that $&{client_name} is "localhost" and if isn't then check
whether the RCPT address is "local only": if yes, reject the mail.

You can probably find example rulesets online.

Thorsten Glaser <tg@mirbsd.de> wrote:

> Hi,

Hello Thorsten,

> in a BSD standard setup (MTA runs on [::]:25 or [::1]:25,
> /usr/sbin/sendmail as MSA connects to [::1]:25 to deliver
> locally-submitted mail), is there a way to make some
> mailboxen “local-only” (i.e. allow mail delivery from
> the local system only but not from the internet)?

the question is indeed what exactly you rate as "local". The "sender
address" - might it be the envelope address or even the mail from
address - is no good idea since these can be faked. The same applies to
domains. Leaves IP addresses.

Look for a rule set which combines sender IP address and recipient
e-mail address for a lookup in the access database and allows wildcards.
Or run independent instances on different IP addresses and let external
systems deliver to the instance which doesn't know / blocks certain
internal addresses and internal systems to deliver to the instance which
is unrestricted - possibly run a split DNS setup where you resolv the
same DNS name to the two different IP addresses. Or use a mail domain
which is not routable in the internet - e.g. "home.arpa" - and block the
recipient addresses with the external domain and don't restrict them on
the unroutable domain.

There are lots of ways how to achieve what you gave a keyword for. In
the end it depends on what exactly you want to achieve.

> [...]

Regards,
Henning
--
Habit is habit, and not to be flung out of the window by any man, but coaxed
down-stairs a step at a time.
-- Mark Twain, "Pudd'nhead Wilson's Calendar