On Thu, Apr 05, 2012 at 02:25:33AM -0400, Eric Kimminau wrote:
> Correct. domain1.com is the local domain, domain2 and domain3 are
> outside the local network and will pass through mailhost.domain1.com
> if they leave the local system.
Good, then DO NOT use the same access table to limit both the
*sender* and the *recipient*, since you only want to restrict the
*recipient* domain.
> > Of course not, your configuration is trying to filter sender domains:
> >
> > Fortunately, the "." pseudo-domain is not one of the Postfix address
> > lookup keys, so your access list is a noop.
> >
> I considered adding several lines for TLD, such as com, org, net,
> etc. But, as you have said this only apparently handles inbound
> mail, not outbound.
No, what I said was that you configured it to limit both senders
and recipients, the access(5) feature in Postfix can be used to
handle either or both and with the same or different tables, which
is perhaps your problem, most Postfix administrators *do not* (as
with Sendmail) use a single unified access table, rather, multiple
tables are used one for each type of access control:
check_sender_access hash:${config_directory}/access_from,
check_recipient_access hash:${config_directory}/access_to,
> My assumption was that mail connecting to the
> MTA, regardless of source, was considered inbound.<br>
This sentence is too vague to mean very much, but indeed mail
first comes in and then it goes out. Some recipient domains
are considered "inbound" (local, virtual alias, virtual mailbox
and relay, see ADDRESS_CLASS_README) others are considered "outbound".
The distinction is important mostly for access control, but it also
factors into transport resolution.
> smtpd_sender_restrictions =
> reject_non_fqdn_sender
> reject_unknown_sender_domain
> check_recipient_access hash:/etc/postfix/access
The above line is pointless.
> permit_auth_destination
> reject
With "permit_auth_destination, reject", you don't need any other
controls. If the permitted destination domains are in relay_domains
or mydestination, they are permitted, and the rest are rejected.
> # Recipient restrictions:
> smtpd_recipient_restrictions =
> reject_unauth_destination
> check_sender_access hash:/etc/postfix/access
>
> > This would be a big problem if the table worked as intended.
The sender check is misguided.
> reject_invalid_hostname
> reject_non_fqdn_sender
> reject_non_fqdn_hostname
> reject_unknown_sender_domain
> reject_unauth_pipelining
> reject_non_fqdn_recipient
> reject_unknown_recipient_domain
> permit_mynetworks
> reject
Here, you're just throwing everything up towards the ceiling and
hoping something will stick.
Ditch the sender restrictions and set:
# Not an inbound MX host, only trusted clients allowed.
smtpd_client_restrictions =
permit_mynetworks,
reject
# Only mail to authorized destinations allowed.
smtpd_recipient_restrictions =
permit_auth_destination,
reject
That's it. Then list the permitted domains in either relay_domains
or mydestination as appropriate. This rejects all mail addressed
to unwanted destinations. If you must instead capture it, you
need to permit the recipient and rewrite or route to the capture
mailbox. Is this worth the effort on a short deadline?
> > Your configuration shos signs of being slapped together through
> > multiple rounds of unsuccessful experimentation. I strongly
> > suggest you take the time to understand address classes and
> > access controls and deploy something much simpler.
>
> Viktor,
>
> I sincerely appreciate your response. And while I certainly also
> appreciate the suggestion, I need a solution implemented by Friday
> morning. RTFM, while it will teach me to fish, will have me losing
> out on the proverbial worm. It absolutely was slapped together. My
> postfix learning curve started about 2 hours before I sent my mail
> and I have about 8 hours Thursday to attempt to implement a workable
> solution.
I am helping you reluctantly. I had to demangle this HTML post and
ignore a bristly attitude. I would recommend to anyone unfamiliar
with a system to take on consulting work to configure said system
on a schedule so tight they have no time to RTFM.
Especially in such circumstances, I would suggest that you treat
any and all advice you receive as a gift, it may not always be the
gift you wanted, but you accept it with grace.
You do need to understand at least ADDRESS_CLASS_README, without
RTFM you could easily overlook some important detail.
I don't know why I am doing your job for you. Perhaps I'm a sucker
for punishment. Over and out.
--
Viktor.
