Send only configuration best practices?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Send only configuration best practices?

Bob Proulx
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
Reply | Threaded
Open this post in threaded view
|

Re: Send only configuration best practices?

John Stoffel-2
>>>>> "Bob" == Bob Proulx <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Send only configuration best practices?

Viktor Dukhovni
In reply to this post by Bob Proulx
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:
        [hidden email]     error:5.1.1 This address does not receive email
        [hidden email]      discard:silently

The "nomail" variant is for silent discards, and is probably not what
you want in most cases, but is sometimes appropriate.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Send only configuration best practices?

Bob Proulx
In reply to this post by John Stoffel-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Send only configuration best practices?

Bob Proulx
In reply to this post by Viktor Dukhovni
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:
>         [hidden email]     error:5.1.1 This address does not receive email
>         [hidden email]      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
Reply | Threaded
Open this post in threaded view
|

Re: Send only configuration best practices?

wa6vvv
In reply to this post by Bob Proulx

> On 23 September 2020, at 22:32, Bob Proulx <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Send only configuration best practices?

Bob Proulx
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
Reply | Threaded
Open this post in threaded view
|

Re: Send only configuration best practices?

Kris Deugau
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
Reply | Threaded
Open this post in threaded view
|

Re: Send only configuration best practices?

Bob Proulx
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.

  <[hidden email]>: host mail.proulx.com[96.88.95.61] said: 550 5.7.27
    <[hidden email]>: 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
Reply | Threaded
Open this post in threaded view
|

Re: Send only configuration best practices?

Bastian Blank-3
In reply to this post by Bob Proulx
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
Reply | Threaded
Open this post in threaded view
|

Re: Send only configuration best practices?

Bob Proulx
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