smtpd_tls_CApath etc - needed?
My mail servers, with LetsEncrypt certificates, seem to be working perfectly (sending to, and receiving from, the world), but I have never set any of: smtp_tls_CAfile smtp_tls_CApath smtpd_tls_CAfile smtpd_tls_CApath tls_append_default_CA Should I be setting any of these?
Re: Send only configuration best practices?
John Stoffel wrote: > Bob> What's the best configuration for a web server that does not > Bob> receive mail but needs to send mail? Password resets. Bug > Bob> ticket update notifications. That type of email. > > I would push all the email to the mailserver for the domain served by > that web server and let it deal with this issue. Make the client (web > server) only send emails through the mail gateway which is setup > properly. Sigh. I was hoping to be able to avoid this. But both of the responses were basically, set up something to handle incoming mail. > No need to replicate the pain again and again for individual servers. But your answer assumes there is already an incoming email system set up for that domain somewhere. But since that isn't always true it means that one would always need to be set up for it. And if there is only one single server for the project then that is the server it will land on. My preference would be not to do it at all. Bob
Re: Send only configuration best practices?
Viktor Dukhovni wrote: > On Wed, Sep 16, 2020 at 04:39:12PM -0600, Bob Proulx wrote: > > What's the best configuration for a web server that does not receive > > mail but needs to send mail? > > Send via a smarthost relay. Use a valid envelope sender domain that > will receive (and, as appropriate, take note of) bounces. Use a > valid "From" domain, but perhaps a "noreply" localpart. The system would be its own smarthost for outbound mail. I was hoping to avoid the need to set up an incoming mail server for this project. But so far yours and the other response were that if one wants mail to be accepted at other sites then the sending domain must publish MX records. Even though I know in your other message to the immediately following thread that you wrote that it should not be required by the RFCs. And I agree with that. But here the opposite is said, sounding as if from a practical standpoint regardless of the RFCs. > For the header RFC2822.From localpart, you have a choice of either > silently discarding or rejecting mail to that address. It is perhaps > more "friendly" to users who fail to notice the "noreply" localpart > to reject. > > transport: > nore...@example.org error:5.1.1 This address does not receive > email > nom...@example.org discard:silently > > The "nomail" variant is for silent discards, and is probably not what > you want in most cases, but is sometimes appropriate. These are good hints. How does the error:5.1.1 interact with other servers that attempt sender address verification? Does that fail for them or does it still allow the message through? Otherwise I think the discard:silently is really the better choice so that sender address verification passes. Meanwhile... In the immediately next thread you said this: Viktor Dukhovni wrote in the "postfix and MX" thread: > Just in case someone gets the wrong impression about MX records being > required... > > It is more than "not RFC friendly", it is simply broken viz. the public > Internet. Many legitimate sending domains have no MX records, this is > normal. Refusing mail from non-MX domains does damage to the email > ecosystem. Right! Bob
Re: Send only configuration best practices?
> On 23 September 2020, at 22:32, Bob Proulx wrote: > > John Stoffel wrote: >> Bob> What's the best configuration for a web server that does not >> Bob> receive mail but needs to send mail? Password resets. Bug >> Bob> ticket update notifications. That type of email. >> >> I would push all the email to the mailserver for the domain served by >> that web server and let it deal with this issue. Make the client (web >> server) only send emails through the mail gateway which is setup >> properly. > > Sigh. I was hoping to be able to avoid this. But both of the > responses were basically, set up something to handle incoming mail. > >> No need to replicate the pain again and again for individual servers. > > But your answer assumes there is already an incoming email system set > up for that domain somewhere. But since that isn't always true it > means that one would always need to be set up for it. And if there is > only one single server for the project then that is the server it will > land on. My preference would be not to do it at all. Check and see if DMA, Dragonfly mail agent, is available for your machine. It is a very simple send only mail server. It is easy to setup and run. Only sends mail. Nothing else other than DNS resolution is required. -- Doug
Re: Send only configuration best practices?
Doug Hardie wrote: > Bob Proulx wrote: > > Sigh. I was hoping to be able to avoid this. But both of the > > responses were basically, set up something to handle incoming mail. > > Check and see if DMA, Dragonfly mail agent, is available for your > machine. It is a very simple send only mail server. It is easy to > setup and run. Only sends mail. Nothing else other than DNS > resolution is required. Sorry but there is a misunderstanding. I wasn't asking any questions about Postfix. Or other MTA. Actually I was worried my question was too far off topic for this mailing list since I was asking about the email environment that exists as a practical matter today. If I am going to set up an MTA then I am definitely going to use Postfix for it. The question isn't one of trying to find an easier or simpler MTA to set up. Postfix is all of very powerful and yet very simple and easy all at the same time. It's definitely my choice to use if I am going to set up either an outgoing or incoming MTA. The problem is *other* sites. I am starting to get a trickle of complaints from people who are not receiving password reset emails. And the problem seems to be other sites that are requiring that senders have MX records, and the rest of the associated incoming mail server set up for it. Which I am well equipment to deal with but would rather not since not is simpler. Bob
