Re: Send only configuration best practices?
Bastian Blank wrote: > Bob Proulx wrote: > > What's the best configuration for a web server that does not receive > > mail but needs to send mail? > > Send only does not exist. Every e-mail can produce bounces, which are > sent to the sender of the original e-mail and needs to be handled > somewhere. Of course any SMTP time rejects are prefectly okay. That's the best and most appropriate time to reject a message. Gone are the old days when sites would routinely relay for another site allowing spammers to fire and forget spam to anyone and dodge the returning bounce message. > If you don't want replies, send with the empty sender (and run into a > complete different set of problems). Yes. It's rather a problem either way. There is really no good best practice to apply here. The problem is one of the classic damned if you do and damned if you don't problems. And yet password resets (and bug notifications) are useful messages to send by email from web sites that don't have any other need for email. Sometimes contining onward being unreasonable is the only reasonable course of action. Bob
Re: Send only configuration best practices?
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 only does not exist. Every e-mail can produce bounces, which are sent to the sender of the original e-mail and needs to be handled somewhere. If you don't want replies, send with the empty sender (and run into a complete different set of problems). Bastian -- War isn't a good life, but it's life. -- Kirk, "A Private Little War", stardate 4211.8
Re: Send only configuration best practices?
Kris Deugau wrote: > Bob Proulx wrote: > > 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. > > webservice.example.org. IN MX 0 . > > ? I thought of that too. :-) I previously tried that a while back and found that Postfix won't accept mail in my own configuration in that case. : host mail.proulx.com[96.88.95.61] said: 550 5.7.27 : Sender address rejected: Domain example.org does not accept mail (nullMX) (in reply to RCPT TO command) Where example.org is the replacement for this other domain I was twiddling that I set up with a Null MX record for as a test case. And then found that Postfix, perhaps due to my own unique configuration here, won't accept mail from it in that case. I presume due to: reject_unknown_sender_domain Reject the request when Postfix is not final destination for the sender address, and the MAIL FROM domain has 1) no DNS MX and no DNS A record, or 2) a malformed MX record such as a record with a zero-length MX hostname (Postfix version 2.3 and later). The reply is specified with the unknown_address_reject_code parameter (default: 450), unknown_address_tempfail_action (default: defer_if_permit), or 550 (nullmx, Postfix 3.0 and later). See the respective parameter descriptions for details. But this is such a useful feature that it is often used and I would not want to do without it. I don't know how many sites have this or equivalent set but I think it would be a very high percentage. Therefore adding a Null MX would actually make the problem worse. I think it is all or nothing. > Or just publish the server as a normal MX record, and just don't set up any > actual handling for inbound mail (ie, configure Postfix to not listen on the > public IP, and/or block port 25 inbound in the firewall). That's basically the situation now. And sites that do callbacks for sender address verification then refuse to accept the mail because the sending site is a send only site. I initially never thought that Sender Address Verification was a problematic. On a first look it seemed cool. But now I think it is really a tangled mess! Mostly I see in conjuction with exim sites. For those reading along but don't know what this is: https://en.wikipedia.org/wiki/Callback_verification http://www.postfix.org/ADDRESS_VERIFICATION_README.html https://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_lists.html#SECTcallver But I am avoiding it. > Sites insisting on having an MX record for the sending FQDN (or worse, the > rDNS name) are likely to reject this too, but if they're that insistent on > having a return channel you're likely going to end up in their separate > local blocklist sooner or later anyway. Mostly I was trying to get a feel for how much of a problem other people have been seeing with this issue. The feeling I get from reading so far is that it while there may be some problems it hasn't been an overwhelmingly huge problem such that everyone knows the answer except for me. > The problem with sites that take a strict line like this is that they WILL > reject a certain amount of legitimate mail, and in the long run the only fix > is to convince them that they need to relax their restrictions. Over time > this will happen naturally; either they bend to pressure from their users > to let in mail that their users want to receive, or they lose the users > whose mail they refused to let through. I think you are right. It's not a problem for 99.44% of sites. I am just trying to smooth out the 0.56% that are having problems. (Obviously numbers I just guessed out on the spot.) I think my plan is to continue without an MX record and without the ability to verify sender address verification for those sites that do it. And those sites will either adapt or their customers will keep complaining that they are not getting mail. For the 99% of everyone else things will just keep working. Bob
Re: Send only configuration best practices?
Bob Proulx wrote: 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. webservice.example.org. IN MX 0 . ? Or just publish the server as a normal MX record, and just don't set up any actual handling for inbound mail (ie, configure Postfix to not listen on the public IP, and/or block port 25 inbound in the firewall). Sites insisting on having an MX record for the sending FQDN (or worse, the rDNS name) are likely to reject this too, but if they're that insistent on having a return channel you're likely going to end up in their separate local blocklist sooner or later anyway. If the server is a subdomain, point the MX record to the primary domain's MX, and configure it or not for the subdomain. The problem with sites that take a strict line like this is that they WILL reject a certain amount of legitimate mail, and in the long run the only fix is to convince them that they need to relax their restrictions. Over time this will happen naturally; either they bend to pressure from their users to let in mail that their users want to receive, or they lose the users whose mail they refused to let through. -kgd
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
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?
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?
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?
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. 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. -- Viktor.
Re: Send only configuration best practices?
> "Bob" == Bob Proulx writes: 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. (Plus admin Bob> mail such as cron output to root. But I can ensure that is Bob> delivered to me and read.) But the host never needs to receive Bob> email from the public. Just outgoing. Is this about what you Bob> would think too? 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. No need to replicate the pain again and again for individual servers. Bob> o SPF configured Bob> o DKIM configured Bob> o DMARC set as p=none Bob> o No MX records Bob> o inet_interfaces = loopback-only Bob> But some mail configuration testing sites (such as mail-tester.com) Bob> flag sites that send but do not have an MX record for receiving mail. Bob> Presumably because there is no way for a separate bounce notification Bob> message to be sent, even if that isn't desirable. But a reject at Bob> SMTP time is always available. Bob> Strategy wise is an MX record now a required thing for sending mail Bob> like some test sites say? If so then I should set up one. And Bob> arrange for some system somewhere, perhaps this one but probably a Bob> different one, to receive incoming mail for it. But with what Bob> configuration? A catchall that accepts and silently discards all Bob> incoming mail perhaps so as to pass sender address verification? Bob> I am lost at sea thinking of this possible requirement for hosts that Bob> do sender address verification types of things. I would appreciate Bob> any wisdom that might be shared here with regards to a strategy for Bob> this type of web site system. Bob> Thanks! Bob> Bob
Send only configuration best practices?
What's the best configuration for a web server that does not receive mail but needs to send mail? Password resets. Bug ticket update notifications. That type of email. (Plus admin mail such as cron output to root. But I can ensure that is delivered to me and read.) But the host never needs to receive email from the public. Just outgoing. Is this about what you would think too? o SPF configured o DKIM configured o DMARC set as p=none o No MX records o inet_interfaces = loopback-only But some mail configuration testing sites (such as mail-tester.com) flag sites that send but do not have an MX record for receiving mail. Presumably because there is no way for a separate bounce notification message to be sent, even if that isn't desirable. But a reject at SMTP time is always available. Strategy wise is an MX record now a required thing for sending mail like some test sites say? If so then I should set up one. And arrange for some system somewhere, perhaps this one but probably a different one, to receive incoming mail for it. But with what configuration? A catchall that accepts and silently discards all incoming mail perhaps so as to pass sender address verification? I am lost at sea thinking of this possible requirement for hosts that do sender address verification types of things. I would appreciate any wisdom that might be shared here with regards to a strategy for this type of web site system. Thanks! Bob
