smtp_fallback_relay TLS with authentication - possible?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

smtp_fallback_relay TLS with authentication - possible?

Andrey Repin-2
Greetings, All!

I'm trying to set delivery on a new server, but hit a roadblock.

The premise is this:
1. All delivery should be handled directly, but…
2. Some of our clients are rejecting mail using particularly idiotic RBL,
however…
3. I have a relay server that usually works ok, although slower, but…
4. Relay server requires TLS and authentication.

Now, I've successfully configured dumb relayhost= with TLS and auth.
But I'm failing to mate it with either relay_transport= or
smtp_fallback_relay=

It either not using fallback relay, complain that it requires wrappermode=yes,
or says that there were timeout waiting for server greeting.

Any pointers?


--
With best regards,
Andrey Repin
Thursday, November 29, 2018 2:42:28

Sorry for my terrible english...
Reply | Threaded
Open this post in threaded view
|

Re: smtp_fallback_relay TLS with authentication - possible?

Viktor Dukhovni
On Thu, Nov 29, 2018 at 02:59:35AM +0300, Andrey Repin wrote:

> The premise is this:
> 1. All delivery should be handled directly, but...

    #
    relayhost =

> 2. Some of our clients are rejecting mail using particularly idiotic RBL,
>    however...

Are the rejects 4XX or 5XX?

> 3. I have a relay server that usually works ok, although slower, but...

You really should be more precise here.  Is the relay server doing STARTTLS
(on either port 25 or 587) or implicit TLS (port 465)?

> 4. Relay server requires TLS and authentication.

What flavour of TLS?  STARTTLS (TLS after SMTP) or implicit TLS
(SMTP after TLS)?

> Now, I've successfully configured dumb relayhost= with TLS and auth.
> But I'm failing to mate it with either relay_transport= or
> smtp_fallback_relay=

If the failures are confined to a mostly stable set of domains and are
not infrequent, then you want to always route these domains to the
relay via:

    main.cf:
        indexed = ${default_database_type}:${config_directory}/
        #
        # Enable SASL, with plaintext passwords sent only
        # to TLS authenticated servers.
        #
        smtp_sasl_auth_enable = yes
        smtp_sasl_security_options = noplaintext, noanonymous
        smtp_sasl_tls_security_options = $smtp_sasl_security_options
        smtp_sasl_tls_verified_security_options = noanonymous
        smtp_sasl_password_maps = ${indexed}sasl-passwd
        #
        # Some domains go to the relayhost
        #
        transport_maps = ${indexed}transport
        #
        # Per-destination security policy
        #
        smtp_tls_policy_maps = ${indexed}tls-policy
        #
        # Small fixed set of trusted CAs (5 or less, ideally one), if known
        # applicable to the relayhost
        #
        tlsrelay_CAfile = ...
        #
        # Otherwise, one of the usual kitchen sink "bundles", but set
        # empty if relayhost will not change CAs unexpectedly.
        #
        tlsrelay_CApath = ...

    sasl-passwd:
        [relayhost.example]:587 aladdin:open sesame

    transport:
        example.com tlsrelay:[relayhost.example]:587
        example.org tlsrelay:[relayhost.example]:587
        example.net tlsrelay:[relayhost.example]:587
        ...

    tls-policy:
        [relayhost.example]:587 secure

    master.cf:
        # ==========================================================================
        # service type  private unpriv  chroot  wakeup  maxproc command + args
        #               (yes)   (yes)   (no)    (never) (100)
        # ==========================================================================
        tlsrelay  unix  -       -       n       -       -       smtp
            -o smtp_tls_CApath=$tlsrelay_CApath
            -o smtp_tls_CAfile=$tlsrelay_CAfile
            ...

> It either not using fallback relay, complain that it requires wrappermode=yes,
> or says that there were timeout waiting for server greeting.

If the set of problem destinations is dynamic, or the failure sporadic,
and a direct attempt makes sense, then:

    main.cf:
        indexed = ${default_database_type}:${config_directory}/
        #
        # Enable SASL, with plaintext passwords sent only
        # to TLS authenticated servers.
        #
        smtp_sasl_auth_enable = yes
        smtp_sasl_security_options = noplaintext, noanonymous
        smtp_sasl_tls_security_options = $smtp_sasl_security_options
        smtp_sasl_tls_verified_security_options = noanonymous
        smtp_sasl_password_maps = ${indexed}sasl-passwd
        #
        # Per-destination security policy
        #
        smtp_tls_policy_maps = ${indexed}tls-policy
        #
        # Small fixed set of trusted CAs (5 or less, ideally one), if known
        # applicable to the relayhost
        #
        smtp_tls_CAfile = ...
        #
        # Otherwise, one of the usual kitchen sink "bundles", but set
        # empty if relayhost will not change CAs unexpectedly.
        #
        smtp_tls_CApath = ...

    tls-policy:
        [relayhost.example]:587 secure

    master.cf:
        # ==========================================================================
        # service type  private unpriv  chroot  wakeup  maxproc command + args
        #               (yes)   (yes)   (no)    (never) (100)
        # ==========================================================================
        smtp      unix  -       -       n       -       -       smtp
            -o smtp_fallback_relay=[relayhost.example]:587
            #
            # Last resort, soft bounce, if direct path rejects, but this also
            # soft fails hard errors from the relay.
            #
            # Better: <http://www.postfix.org/postconf.5.html#smtp_reply_filter>.
            #
            # -o soft_bounce=yes

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

Re: smtp_fallback_relay TLS with authentication - possible?

Andrey Repin-2
Greetings, Viktor Dukhovni!

> On Thu, Nov 29, 2018 at 02:59:35AM +0300, Andrey Repin wrote:

>> The premise is this:
>> 1. All delivery should be handled directly, but...

>     #
>     relayhost =

That's not directly, that's "through relay".

>> 2. Some of our clients are rejecting mail using particularly idiotic RBL,
>>    however...

> Are the rejects 4XX or 5XX?

220-relay6.hosting.reg.ru ESMTP Postfix
521 5.7.1 Service unavailable; client [213.134.200.30] blocked using b.barracudacentral.org

>> 3. I have a relay server that usually works ok, although slower, but...

> You really should be more precise here.  Is the relay server doing STARTTLS
> (on either port 25 or 587) or implicit TLS (port 465)?

>> 4. Relay server requires TLS and authentication.

> What flavour of TLS?  STARTTLS (TLS after SMTP) or implicit TLS
> (SMTP after TLS)?

TLS as in - explicit TLS (port 465).

>> Now, I've successfully configured dumb relayhost= with TLS and auth.
>> But I'm failing to mate it with either relay_transport= or
>> smtp_fallback_relay=

> If the failures are confined to a mostly stable set of domains and are
> not infrequent, then you want to always route these domains to the
> relay via:

>     transport:
>         example.com     tlsrelay:[relayhost.example]:587
>         example.org     tlsrelay:[relayhost.example]:587
>         example.net     tlsrelay:[relayhost.example]:587
>         ...

>     master.cf:
>         #
> ==========================================================================
>         # service type  private unpriv  chroot  wakeup  maxproc command + args
>         #               (yes)   (yes)   (no)    (never) (100)
>         #
> ==========================================================================
>         tlsrelay  unix  -       -       n       -       -       smtp
>             -o smtp_tls_CApath=$tlsrelay_CApath
>             -o smtp_tls_CAfile=$tlsrelay_CAfile
>             ...

Hm. I was near that solution, but you are right that it is only applicable to
a known set of domains.

>> It either not using fallback relay, complain that it requires wrappermode=yes,
>> or says that there were timeout waiting for server greeting.

> If the set of problem destinations is dynamic, or the failure sporadic,
> and a direct attempt makes sense, then:

>     master.cf:
>         #
> ==========================================================================
>         # service type  private unpriv  chroot  wakeup  maxproc command + args
>         #               (yes)   (yes)   (no)    (never) (100)
>         #
> ==========================================================================
>         smtp      unix  -       -       n       -       -       smtp
>             -o smtp_fallback_relay=[relayhost.example]:587

Should use 465...
Which requires wrappermode=yes.
Which subsequently break any direct delivery.


--
With best regards,
Andrey Repin
Thursday, November 29, 2018 4:01:41

Sorry for my terrible english...

Reply | Threaded
Open this post in threaded view
|

Re: smtp_fallback_relay TLS with authentication - possible?

Viktor Dukhovni
On Thu, Nov 29, 2018 at 04:21:44AM +0300, Andrey Repin wrote:

> >> 1. All delivery should be handled directly, but...
>
> >     #
> >     relayhost =
>
> That's not directly, that's "through relay".

By ensuring that "relayhost = " (empty), the initial delivery is
direct.

> > Are the rejects 4XX or 5XX?
>
> 220-relay6.hosting.reg.ru ESMTP Postfix
> 521 5.7.1 Service unavailable; client [213.134.200.30] blocked using b.barracudacentral.org

Well, the barracuda RBL is not generally considered particularly
aggressive.  If your MTA is routinely listed there, and you're not
spamming, you should work with Barracude to get de-listed.

> >> 4. Relay server requires TLS and authentication.
>
> > What flavour of TLS?  STARTTLS (TLS after SMTP) or implicit TLS
> > (SMTP after TLS)?
>
> TLS as in - explicit TLS (port 465).

That's actually called "implicit" TLS:

    https://tools.ietf.org/html/rfc8314#section-3

> Hm. I was near that solution, but you are right that it is only applicable to
> a known set of domains.

Is that your case or do you see the issue with an unpredictable set
of destinations?

> >         smtp      unix  -       -       n       -       -       smtp
> >             -o smtp_fallback_relay=[relayhost.example]:587
>
> Should use 465...

The "smtp_tls_wrapper_mode" setting in Postfix is per-transport
(via master.cf overrides), and has no per-destination analogue in
the TLS policy table.  Nor is this inferred from the port number.

So yes, you can't have wrapper mode for just the fallback relay.
Which means that your relayhost would have to suppor STARTTLS.

> Which requires wrappermode=yes.
> Which subsequently break any direct delivery.

Yes, good luck, assuming you're sending email users want and not
unsolicited bulk email.  If the latter, then Yahoo's refusal to
accept the email is eminently reasonable.

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

Re: smtp_fallback_relay TLS with authentication - possible?

Andrey Repin-2
Greetings, Viktor Dukhovni!

> On Thu, Nov 29, 2018 at 04:21:44AM +0300, Andrey Repin wrote:

>> >> 1. All delivery should be handled directly, but...
>>
>> >     #
>> >     relayhost =
>>
>> That's not directly, that's "through relay".

> By ensuring that "relayhost = " (empty), the initial delivery is
> direct.

Ah, right. Sorry for confusion.

>> > Are the rejects 4XX or 5XX?
>>
>> 220-relay6.hosting.reg.ru ESMTP Postfix
>> 521 5.7.1 Service unavailable; client [213.134.200.30] blocked using b.barracudacentral.org

> Well, the barracuda RBL is not generally considered particularly
> aggressive.  If your MTA is routinely listed there, and you're not
> spamming, you should work with Barracude to get de-listed.

If only it was possible to "work with". They have no contacts whatsoever,
only a laggy "delisting" form that once in a blue moon show you some "tracking
ID" that you can't use for anything.
And the only reason I could come up with that my IP ended in it is that I have
had no mail sent to port 25 from this IP in eight years.

>> >> 4. Relay server requires TLS and authentication.
>>
>> > What flavour of TLS?  STARTTLS (TLS after SMTP) or implicit TLS
>> > (SMTP after TLS)?
>>
>> TLS as in - explicit TLS (port 465).

> That's actually called "implicit" TLS:

>     https://tools.ietf.org/html/rfc8314#section-3

>> Hm. I was near that solution, but you are right that it is only applicable to
>> a known set of domains.

> Is that your case or do you see the issue with an unpredictable set
> of destinations?

I can't predict, which other destination would use that stupid RBL.

>> >         smtp      unix  -       -       n       -       -       smtp
>> >             -o smtp_fallback_relay=[relayhost.example]:587
>>
>> Should use 465...

> The "smtp_tls_wrapper_mode" setting in Postfix is per-transport
> (via master.cf overrides), and has no per-destination analogue in
> the TLS policy table.  Nor is this inferred from the port number.

> So yes, you can't have wrapper mode for just the fallback relay.
> Which means that your relayhost would have to suppor STARTTLS.

It does not, I just double checked with the owner.

>> Which requires wrappermode=yes.
>> Which subsequently break any direct delivery.

> Yes, good luck, assuming you're sending email users want and not
> unsolicited bulk email.

I don't send unsolicited bulk email at all.
I didn't send any email at all to begin with, I only recently removed hard
outgoing block on port 25, and only for a single intranet host, where I'm
setting up the server. Lo and behold, my IP is in RBL with no way to get it
out of there.
All I've learned about RBL in the last decade is that they are all either
racket, ransom or worse.

> If the latter, then Yahoo's refusal to accept the email is eminently
> reasonable.

I don't know what Yahoo have to do with this problem, but I'll take your
word for it.


--
With best regards,
Andrey Repin
Thursday, November 29, 2018 5:16:04

Sorry for my terrible english...

Reply | Threaded
Open this post in threaded view
|

Re: smtp_fallback_relay TLS with authentication - possible?

Viktor Dukhovni
> On Nov 28, 2018, at 9:25 PM, Andrey Repin <[hidden email]> wrote:
>
>> The "smtp_tls_wrapper_mode" setting in Postfix is per-transport
>> (via master.cf overrides), and has no per-destination analogue in
>> the TLS policy table.  Nor is this inferred from the port number.
>
>> So yes, you can't have wrapper mode for just the fallback relay.
>> Which means that your relayhost would have to suppor STARTTLS.
>
> It does not, I just double checked with the owner.

In that case, you'd need to configure stunnel or similar to listen
on a local loopback port and proxy it to port 465 on the remote
host, via an authenticated upstream TLS connection (avoid the legacy
"verify = 2", it is not secure).

With that, your fallback relay can be just cleartext SMTP to a local
port which stunnel will encrypt in transit.  You'd need to enable
plaintext auth without TLS, since Postfix won't know about stunnel
doing TLS on the wire.

Another alternative, avoiding stunnel is to forward the mail to
a fallback Postfix instance that then sends everything via the
relay (using wrapper_mode).

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: smtp_fallback_relay TLS with authentication - possible?

Andrey Repin-2
Greetings, Viktor Dukhovni!

>> On Nov 28, 2018, at 9:25 PM, Andrey Repin <[hidden email]> wrote:
>>
>>> The "smtp_tls_wrapper_mode" setting in Postfix is per-transport
>>> (via master.cf overrides), and has no per-destination analogue in
>>> the TLS policy table.  Nor is this inferred from the port number.
>>
>>> So yes, you can't have wrapper mode for just the fallback relay.
>>> Which means that your relayhost would have to suppor STARTTLS.
>>
>> It does not, I just double checked with the owner.

> In that case, you'd need to configure stunnel or similar to listen
> on a local loopback port and proxy it to port 465 on the remote
> host, via an authenticated upstream TLS connection (avoid the legacy
> "verify = 2", it is not secure).

> With that, your fallback relay can be just cleartext SMTP to a local
> port which stunnel will encrypt in transit.  You'd need to enable
> plaintext auth without TLS, since Postfix won't know about stunnel
> doing TLS on the wire.

> Another alternative, avoiding stunnel is to forward the mail to
> a fallback Postfix instance that then sends everything via the
> relay (using wrapper_mode).

Yes, I came to the same conclusion. Not the most secure, but probably only
working solution without too much overhead.
Thanks for your help.


--
With best regards,
Andrey Repin
Thursday, November 29, 2018 5:57:10

Sorry for my terrible english...

Reply | Threaded
Open this post in threaded view
|

Re: smtp_fallback_relay TLS with authentication - possible?

A. Schulze
In reply to this post by Viktor Dukhovni

Viktor Dukhovni:


> So yes, you can't have wrapper mode for just the fallback relay.


Hello,

I had a similar problem some time ago and also found what you sumarize now.

I'm still using 587+STARTTLS but that "break" our `more general rule`  
to prefer implicit TLS over STARTTLS

So, at least I would now announce that it would be nice to have  
something like this:

master.cf
   smtp      unix  -       -       n       -       -       smtp
     -o smtp_fallback_relay=[relayhost.example]:465
     # not yet existing option :-)
     -o smtp_fallback_relay_wrappermode=on

Andreas


Reply | Threaded
Open this post in threaded view
|

Re: smtp_fallback_relay TLS with authentication - possible?

Andrey Repin-2
Greetings, A. Schulze!

>> So yes, you can't have wrapper mode for just the fallback relay.


> Hello,

> I had a similar problem some time ago and also found what you sumarize now.

> I'm still using 587+STARTTLS but that "break" our `more general rule`  
> to prefer implicit TLS over STARTTLS

> So, at least I would now announce that it would be nice to have  
> something like this:

> master.cf
>    smtp      unix  -       -       n       -       -       smtp
>      -o smtp_fallback_relay=[relayhost.example]:465
>      # not yet existing option :-)
>      -o smtp_fallback_relay_wrappermode=on

I think, a more transparent solution would be to extend influence of
preferences set in smtp_tls_policy_maps to the wrappermode setting, or have a
new dedicated flag in this file to the same meaning.

As it is right now, the smtp_tls_wrappermode setting is more a nuisance than a
solution to any problem, and should be either removed or lowered in its
necessity.

P.S.
Stunnel works like a charm.


--
With best regards,
Andrey Repin
Thursday, November 29, 2018 20:12:04

Sorry for my terrible english...