After smtps rejection, fails falling back to smtp (TLS) (Postfix 3.1.0)

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

After smtps rejection, fails falling back to smtp (TLS) (Postfix 3.1.0)

Dominic Raferd
I am using Postfix 3.1.0 and following instructions at http://www.postfix.org/TLS_README.html#client_smtps to set up for sending some (recipient dependent) emails via smtps (whereas others go over TLS to a different relay server). This uses the transport_maps settings in main.cf, a transport file (hashed) and special routing (relay-smtps) in master.cf.

This works - when the onward smtps server accepts the emails. However in my case this doesn't always happen -  basically they sometimes block when we are over quota. So when it fails, Postfix falls back using the hosts specified in main.cf's smtp_fallback_relay (*not* relayhost, which is used for emails that don't have a match in the transport list).

All well and good. But I find that after smtps rejection, the fallback_relay hosts (both) always fail too with message like:

warning: TLS library problem: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:

With effect that the email cannot be sent at all.

In short like this:
    /etc/postfix/main.cf
        transport_maps = hash:/etc/postfix/transport
        relayhost = [smtp.sendxxxx.net]
        smtp_fallback_relay = [relay.gradxxxx.net] [smtp.sendxxxx.net]

    /etc/postfix/transport and /etc/postfix/main.cf - as specified at http://www.postfix.org/TLS_README.html#client_smtps for Postfix >= 3.0

However if I remove the initial attempt to use smtps (i.e. comment out transport_maps and reload postfix), then relayhost and fallback_relays work perfectly.

I've tried a raft of different settings without success. Any suggestions gratefully received.

Dominic


Reply | Threaded
Open this post in threaded view
|

Re: After smtps rejection, fails falling back to smtp (TLS) (Postfix 3.1.0)

Viktor Dukhovni
On Wed, Sep 14, 2016 at 01:11:53PM +0100, Dominic Raferd wrote:

> I am using Postfix 3.1.0 and following instructions at
> http://www.postfix.org/TLS_README.html#client_smtps to set up for sending
> some (recipient dependent) emails via smtps (whereas others go over TLS to
> a different relay server).

Otherwise also called "TLS wrapper mode" in which a TLS handshake
takes place immediately after the TCP 3-way hanshake, and the SMTP
session runs inside TLS.  Note that:

        smtp_tls_wrappermode = yes

is a global setting for the transport, that is, it depends only
on the transport used, not the nexthop domain.

>  So when it fails, Postfix falls back using the hosts
> specified in main.cf's smtp_fallback_relay (*not* relayhost, which is used
> for emails that don't have a match in the transport list).

It does not matter whether "smtp_fallback_relay" is in main.cf or
in master.cf specified per transport.   Either way, the fallback
delivery always uses the same transport agent used for the primary
nexthop.  Which means that smtp_fallback_relay will use smtps,
when the primary nexthop uses smtps.  This does not depend on
the nexthop destination's port number.

What you're looking for is a new feature, in which wrapper mode is
enabled conditionally, only when the port is 465, and not when it
is some other port.  That code has not been written.

It is hard to imagine why an MSA on port 465 would implement quotas.
Generally, port 465 MSAs just do outbound submission, and not
inbound mailbox delivery.  Is there some provider that's mixing
up these services?  Is this configuration self-inflicted?

If the primary MSA provider also supports STARTTLS on port 587,
use that instead, and don't enable TLS wrapper mode.

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

Re: After smtps rejection, fails falling back to smtp (TLS) (Postfix 3.1.0)

Dominic Raferd
Thanks for your quick reply Viktor. OK now I understand that what I am trying to do can't be done. If someone could implement the feature you suggest (wrapper mode is enabled conditionally, only when the port is 465, and not when it is some other port) that would of course be ideal.

Background: smtp.virginmedia.net imposes some absurdly small limit on the number of emails it will relay, I suppose because they deem it a residential service. The reason I am trying to do this is that our 'normal' relay server signs all emails (dkim) and this is good for emails we are sending out but not good for emails we are receiving in (because these can include all sorts of spam, and the signing falsely indicates them to be from us), so I wanted to use Virgin's smtp server - which doesn't re-sign emails - just to handle these incoming emails (and pass them on to our real external mailboxes). Clearly I have to think again!

Apologies for double-posting my original question, I thought the first one had not got through.

Dominic

On 14 September 2016 at 13:30, Viktor Dukhovni <[hidden email]> wrote:
On Wed, Sep 14, 2016 at 01:11:53PM +0100, Dominic Raferd wrote:

> I am using Postfix 3.1.0 and following instructions at
> http://www.postfix.org/TLS_README.html#client_smtps to set up for sending
> some (recipient dependent) emails via smtps (whereas others go over TLS to
> a different relay server).

Otherwise also called "TLS wrapper mode" in which a TLS handshake
takes place immediately after the TCP 3-way hanshake, and the SMTP
session runs inside TLS.  Note that:

        smtp_tls_wrappermode = yes

is a global setting for the transport, that is, it depends only
on the transport used, not the nexthop domain.

>  So when it fails, Postfix falls back using the hosts
> specified in main.cf's smtp_fallback_relay (*not* relayhost, which is used
> for emails that don't have a match in the transport list).

It does not matter whether "smtp_fallback_relay" is in main.cf or
in master.cf specified per transport.   Either way, the fallback
delivery always uses the same transport agent used for the primary
nexthop.  Which means that smtp_fallback_relay will use smtps,
when the primary nexthop uses smtps.  This does not depend on
the nexthop destination's port number.

What you're looking for is a new feature, in which wrapper mode is
enabled conditionally, only when the port is 465, and not when it
is some other port.  That code has not been written.

It is hard to imagine why an MSA on port 465 would implement quotas.
Generally, port 465 MSAs just do outbound submission, and not
inbound mailbox delivery.  Is there some provider that's mixing
up these services?  Is this configuration self-inflicted?

If the primary MSA provider also supports STARTTLS on port 587,
use that instead, and don't enable TLS wrapper mode.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: After smtps rejection, fails falling back to smtp (TLS) (Postfix 3.1.0)

Dominic Raferd
On 14 September 2016 at 13:42, Dominic Raferd <[hidden email]> wrote:

> Thanks for your quick reply Viktor. OK now I understand that what I am
> trying to do can't be done. If someone could implement the feature you
> suggest (wrapper mode is enabled conditionally, only when the port is 465,
> and not when it is some other port) that would of course be ideal.
>
> Background: smtp.virginmedia.net imposes some absurdly small limit on the
> number of emails it will relay, I suppose because they deem it a residential
> service. The reason I am trying to do this is that our 'normal' relay server
> signs all emails (dkim) and this is good for emails we are sending out but
> not good for emails we are receiving in (because these can include all sorts
> of spam, and the signing falsely indicates them to be from us), so I wanted
> to use Virgin's smtp server - which doesn't re-sign emails - just to handle
> these incoming emails (and pass them on to our real external mailboxes).
> Clearly I have to think again!
>
> Apologies for double-posting my original question, I thought the first one
> had not got through.
>
> Dominic
>
> On 14 September 2016 at 13:30, Viktor Dukhovni <[hidden email]>
> wrote:
>>
>> On Wed, Sep 14, 2016 at 01:11:53PM +0100, Dominic Raferd wrote:
>>
>> > I am using Postfix 3.1.0 and following instructions at
>> > http://www.postfix.org/TLS_README.html#client_smtps to set up for
>> > sending
>> > some (recipient dependent) emails via smtps (whereas others go over TLS
>> > to
>> > a different relay server).
>>
>> Otherwise also called "TLS wrapper mode" in which a TLS handshake
>> takes place immediately after the TCP 3-way hanshake, and the SMTP
>> session runs inside TLS.  Note that:
>>
>>         smtp_tls_wrappermode = yes
>>
>> is a global setting for the transport, that is, it depends only
>> on the transport used, not the nexthop domain.
>>
>> >  So when it fails, Postfix falls back using the hosts
>> > specified in main.cf's smtp_fallback_relay (*not* relayhost, which is
>> > used
>> > for emails that don't have a match in the transport list).
>>
>> It does not matter whether "smtp_fallback_relay" is in main.cf or
>> in master.cf specified per transport.   Either way, the fallback
>> delivery always uses the same transport agent used for the primary
>> nexthop.  Which means that smtp_fallback_relay will use smtps,
>> when the primary nexthop uses smtps.  This does not depend on
>> the nexthop destination's port number.
>>
>> What you're looking for is a new feature, in which wrapper mode is
>> enabled conditionally, only when the port is 465, and not when it
>> is some other port.  That code has not been written.
>>
>> It is hard to imagine why an MSA on port 465 would implement quotas.
>> Generally, port 465 MSAs just do outbound submission, and not
>> inbound mailbox delivery.  Is there some provider that's mixing
>> up these services?  Is this configuration self-inflicted?
>>
>> If the primary MSA provider also supports STARTTLS on port 587,
>> use that instead, and don't enable TLS wrapper mode.
>>
>> --
>>         Viktor.

If anyone else needs it, the workaround way to get 'conditional
wrapper mode' - i.e. relay-dependent wrapper mode, suitable if one
relay requires smtps (465) but other relays don't - is to use stunnel
(on Debian/Ubuntu: apt-get install stunnel4), as suggested for Postfix
<3.0 at http://www.postfix.org/TLS_README.html. This still works for
Postfix >=3.0.