MESSAGE
| DATE | 2022-01-03 |
| FROM | raf
|
| SUBJECT | Re: [Hangout - NYLXS] Adding Additional domains and outgoing email
|
On Mon, Jan 03, 2022 at 01:29:59PM -0500, Ruben Safir wrote:
> On Thu, Dec 23, 2021 at 11:20:09AM +1100, raf wrote:
> > On Wed, Dec 22, 2021 at 12:20:31AM -0500, Ruben Safir wrote:
> >
> > > On Wed, Dec 22, 2021 at 02:19:49PM +1100, raf wrote:
> > > > On Tue, Dec 21, 2021 at 06:52:23AM -0500, Ruben Safir wrote:
> > > >
> > > > > I want to add a domain for the office in addition to my current domain.
> > > > >
> > > > > I've done this before, following the outline in:
> > > > > http://www.postfix.org/VIRTUAL_README.html#canonical
> > > > >
> > > > > using
> > > > >
> > > > > [ruben-at-www2 ~]$ cat /etc/postfix/main.cf|grep mydest
> > > > > mydestination = www.domain1.com, www2.domain1.com, home.domain1.com,
> > > > > domain1.com, domain2.com, domain3.com, domain4.com, domain5.com,
> > > > > newistdomain.com
> > > > >
> > > > > So I can receive mail satisfactory and this has been good enough since I
> > > > > normally ssh in from remote and use mutt and all my outgoing email is
> > > > > transformed to name-at-domain.com
> > > > >
> > > > > I need for select users from the newistdomain.com to have that
> > > > > name-at-newistdomain.com
> > > > >
> > > > > I am using thunderbird and dovecot to pop mail from the system. At
> > > > > home, this is no problem as I am on the local network. I just set up the
> > > > > smtp server to the postfix host running postfix.
> > > >
> > > > That should probably be the same for all Thunderbird users as well.
> > > >
> > > > > mydomain = domain1.com
> > > > > masquerade_domains = domain1.com, domain1.com #which is probably wrong
> > > > > myhostname = domain1.com
> > > >
> > > > I'm sure that domain1.com doesn't need to appear twice in
> > > > the masquerade_domains parameter, but it's harmless.
> > > >
> > > > > How do I securely open postfix to relay email received from these
> > > > > specific external office locals using newistdomain.coms
> > > >
> > > > If you can already connect using Thunderbird, you must
> > > > have an entry for submission and/or submissions/smtps
> > > > (i.e., port 587 and/or 465) in /etc/postfix.master.cf,
> > >
> > > Thunderbird can directly talk to postfix SMTP without dovecot et al?
> > >
> > > I thought it only talks to postfix on the outbound mail. This is not
> > > taylor uucp :(
> >
> > Thunderbird can talk SMTP to Postfix on ports 25, 465,
> > and/or 587. But it can probably only use port 25 when
> > it's connecting from an IP address that is in Postfix's
> > $mynetworks and so doesn't necessarily require
> > authentication. Ports 465 and 587 should require
> > authentication.
> >
> > Thunderbird only connects to Dovecot directly for
> > reading mail via POP/IMAP (ports 110, 143, 993, 995).
> >
> > However, for authenticated SMTP, Thunderbird connects
> > to Postfix, and Postfix can then connect to Dovecot
> > locally for authenticating the user. One way of doing
> > that is:
> >
> > /etc/postfix/main.cf:
> > smtpd_sasl_type = dovecot
> > smtpd_sasl_path = private/auth
>
> Can't this be done with tls withouth dovecot or sasl?
Authentication is needed by Dovecot for IMAP access
to read email. So it should be available for use by
Postfix as well.
Authentication should also be required by Postfix for
submission of email from remote clients like
Thunderbird. The only typical exception to that would
be when the Thunderbird clients are on a "trusted"
network, and so their IP address can take the place of
SASL authentication in order for Postfix to decide that
it's OK to accept mail from them to be relayed to the
outside world. Some would argue that SASL
authentication should always be used whenever possible.
However, even though TLS (usually) only verifies the
identity of the server, rather than authenticating the
client, it can do that as well, by using client
certificates in addition to the server certificate. See
http://www.postfix.org/TLS_README.html for details.
So yes, you should be able to replace uses of
permit_sasl_authenticated in various parameters
with "smtpd_tls_req_ccert = yes" as -o option
override in master.cf for your submission service.
I'm sure there's more to it, but the TLS_README
should help.
> I tried to do this and I get this error
>
>
> An error occurred while sending mail: Outgoing server (SMTP) error. The
> server responded: TLS not available due to local problem.
The Postfix server's logfile should contain more information
about what the local problem was.
You can also use openssl to connect to the server and examine
the certificate details, with a command like this for port 25 or 587:
DOMAIN=example.com
SERVER=example.com
PORT=25
echo | \
openssl s_client -starttls smtp -showcerts -servername $SERVER -connect $DOMAIN:$PORT 2>/dev/null | \
openssl x509 -inform pem -noout -text | less
Or like this for port 465:
DOMAIN=example.com
SERVER=example.com
PORT=465
echo | \
openssl s_client -showcerts -servername $SERVER -connect $DOMAIN:$PORT 2>/dev/null | \
openssl x509 -inform pem -noout -text | less
But will probably just confirm the local problem.
The mail logs are more likely to help you identify
the cause.
> I have this in the config file now:
>
> /etc/postfix/main.cf
>
>
> smtpd_sender_restrictions = hash:/etc/postfix/access,
> reject_unknown_sender_domain
>
> smtpd_recipient_restrictions =
> check_client_access hash:/etc/postfix/helo_client_exceptions
> check_sender_access hash:/etc/postfix/sender_checks,
> reject_invalid_hostname,
> ### Can cause issues with Auth SMTP, so be weary!
> reject_non_fqdn_hostname,
> ##################################
> reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain,
> reject_unknown_recipient_domain,
> permit_mynetworks,
> reject_unauth_destination,
> permit_mynetworks, reject_unauth_destination,
> reject_invalid_hostname,
> reject_non_fqdn_hostname,
> reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain,
> reject_unknown_recipient_domain,
> reject_rbl_client zen.spamhaus.org,
> reject_rbl_client bl.spamcop.net
> reject_rbl_client cbl.abuseat.org,
> permit
> smtpd_data_restrictions = reject_unauth_pipelining, permit
>
> ############################################################
> # SASL stuff
> ############################################################
> smtp_sasl_auth_enable = no
> smtp_sasl_security_options =
> smtp_sasl_password_maps =
> smtpd_sasl_auth_enable = no
> ############################################################
> # TLS stuff
> ############################################################
> #tls_append_default_CA = no
> relay_clientcerts =
It looks like the relay_clientcerts parameter would do
what you want, if you point it at a lookup table
containing your client TLS certificate fingerprints.
You'd need to use permit_tls_clientcerts in place of
permit_sasl_authenticated in the appropriate
smtp_*_restrictions parameter for the submission
service in master.cf. See
http://www.postfix.org/postconf.5.html#relay_clientcerts
http://www.postfix.org/postconf.5.html#permit_tls_clientcerts
However, it's probably much easier to use SASL authentication
instead since you already have dovecot.
> #tls_random_source = dev:/dev/urandom
>
> smtp_use_tls = yes
> smtp_tls_loglevel = 1
> smtp_enforce_tls = no
> smtp_tls_CAfile = /etc/postfix/tls/smtpd.pem
> #smtp_tls_CApath =
> smtp_tls_cert_file = /etc/postfix/tls/smtpd.pem
> smtp_tls_key_file = /etc/postfix/tls/smtpd.pem
I don't think the above two parameters should be pointing
to the same file. But I might be wrong about that. I've
never had the Postfix server use a client certificate
when sending mail out. But it really doesn't look right.
Normally, the server would only use a specific client
certificate for outgoing mail when sending to a particular
transport that required it, not to all potential recipient
servers as would be the case when putting those parameters
in main.cf. It might be sensible to just replace the above
with:
smtp_tls_security_level = may
smtp_tls_loglevel = 1
> #smtp_tls_session_cache_timeout = 3600s
> smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
The above should probably use ${data_directory} rather
than ${queue_directory}. But maybe that depends on the system.
I think I had queue_directory originally but got warning messages
in the logfile about it. If you aren't seeing those warnings,
it's probably fine.
> smtpd_use_tls = yes
> smtpd_tls_loglevel = 1
> smtpd_tls_CAfile = /etc/postfix/tls/smtpd.pem
> #smtpd_tls_CApath =/etc/postfix/tls/smtpd.pem
> smtpd_tls_cert_file =/etc/postfix/tls/smtpd.pem
> smtpd_tls_key_file =/etc/postfix/tls/smtpd.pem
The same pem file as above is being used as the server
certificate as well. And the cert and key parameters
are pointing to the same file again which looks unusual
to me. Does it contain both the private key and the
full chain? If so, you could use the
smtpd_tls_chain_files parameter instead of
smtpd_tls_cert_file and smtpd_tls_key_file.
Using the same file for smtpd_tls_CAfile as well looks
odd to me, but I'm not an expert. Maybe it's OK.
> smtpd_tls_ask_ccert = yes
Having the above in main.cf makes it apply to all
incoming SMTP connections. I don't think you want that.
You only want it for your own users whose client
certificates you know about. It should be in master.cf
where the submission/submissions services are defined.
And it should be "smtpd_tls_req_ccert = yes" instead,
so that the Thunderbird clients are required to possess
a known client certificate (if SASL authentication is
not going to be used).
I hope what I've said makes sense.
cheers,
raf
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
|
|
