Question regarding smtp_per_record_deadlne parameter

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

Question regarding smtp_per_record_deadlne parameter

J Doe
Hello,

I currently have a server that is configured as a mail forwarding domain [1].  Using example.com as an example:

    /etc/postfix/main.cf
        virtual_alias_domains = example.com
        virtual_alias_maps = hash:/etc/postfix/virtual

    /etc/postfix/virtual
        [hidden email] [hidden email]

As such, the SMTP client is used to forward the messages to each user’s existing Gmail addresses.

I was reading more about the smtp client parameters and read about smtp_per_record_deadline.  In postconf(5) it states that the time limits are changed and that this “...limits the impact from hostile peers that trickle data one byte at a time”

Since my peer for the smtp client is always Gmail, this isn’t an issue for me, but I was wondering - why does this default to “no” ?  I note the warning in postconf(5) that states for slow network connections this can cause problems with TLS, but I am assuming that this doesn’t apply to most configurations.  

Why wouldn’t I want this normally enabled ?

Thanks,

- J

Sources
[1] www.postfix.org/VIRTUAL_README.html
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding smtp_per_record_deadlne parameter

Noel Jones-2
On 12/4/2017 3:35 PM, J Doe wrote:

> Hello,
>
> I currently have a server that is configured as a mail forwarding domain [1].  Using example.com as an example:
>
>     /etc/postfix/main.cf
>         virtual_alias_domains = example.com
>         virtual_alias_maps = hash:/etc/postfix/virtual
>
>     /etc/postfix/virtual
>         [hidden email] [hidden email]
>
> As such, the SMTP client is used to forward the messages to each user’s existing Gmail addresses.
>
> I was reading more about the smtp client parameters and read about smtp_per_record_deadline.  In postconf(5) it states that the time limits are changed and that this “...limits the impact from hostile peers that trickle data one byte at a time”
>
> Since my peer for the smtp client is always Gmail, this isn’t an issue for me, but I was wondering - why does this default to “no” ?  I note the warning in postconf(5) that states for slow network connections this can cause problems with TLS, but I am assuming that this doesn’t apply to most configurations.  
>
> Why wouldn’t I want this normally enabled ?
>
> Thanks,
>
> - J
>
> Sources
> [1] www.postfix.org/VIRTUAL_README.html
>


This messes with timeouts in a non-obvious manner, and can cause
legit slow-but-working connections to fail, especially if they use TLS.

Don't enable this unless you are actively experiencing a
slow-connection denial of service, which are pretty rare.




  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding smtp_per_record_deadlne parameter

Wietse Venema
Noel Jones:

> On 12/4/2017 3:35 PM, J Doe wrote:
> > Hello,
> >
> > I currently have a server that is configured as a mail forwarding domain [1].  Using example.com as an example:
> >
> >     /etc/postfix/main.cf
> >         virtual_alias_domains = example.com
> >         virtual_alias_maps = hash:/etc/postfix/virtual
> >
> >     /etc/postfix/virtual
> >         [hidden email] [hidden email]
> >
> > As such, the SMTP client is used to forward the messages to each user?s existing Gmail addresses.
> >
> > I was reading more about the smtp client parameters and read about smtp_per_record_deadline.  In postconf(5) it states that the time limits are changed and that this ?...limits the impact from hostile peers that trickle data one byte at a time?
> >
> > Since my peer for the smtp client is always Gmail, this isn?t an issue for me, but I was wondering - why does this default to ?no? ?  I note the warning in postconf(5) that states for slow network connections this can cause problems with TLS, but I am assuming that this doesn?t apply to most configurations.  
> >
> > Why wouldn?t I want this normally enabled ?

It's not safe to make this the Postfix default, but you're welcome
to override that if you are sure that connections will never be
slow.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding smtp_per_record_deadlne parameter

J Doe
Hi Noel and Wietse,

Thank you for your prompt feedback.

I think (in the quest to explore this more fully), I will try enabling this for a short term and see what sort of TLS issues I may have.  The server I described in previous mails is low volume so I believe it’s ideal for testing something like this.

If anyone’s interested, I can always report back to the list about it.

- J

> On Dec 4, 2017, at 7:39 PM, Wietse Venema <[hidden email]> wrote:
>
> Noel Jones:
>>> On 12/4/2017 3:35 PM, J Doe wrote:
>>> Hello,
>>>
>>> I currently have a server that is configured as a mail forwarding domain [1].  Using example.com as an example:
>>>
>>>    /etc/postfix/main.cf
>>>        virtual_alias_domains = example.com
>>>        virtual_alias_maps = hash:/etc/postfix/virtual
>>>
>>>    /etc/postfix/virtual
>>>        [hidden email] [hidden email]
>>>
>>> As such, the SMTP client is used to forward the messages to each user?s existing Gmail addresses.
>>>
>>> I was reading more about the smtp client parameters and read about smtp_per_record_deadline.  In postconf(5) it states that the time limits are changed and that this ?...limits the impact from hostile peers that trickle data one byte at a time?
>>>
>>> Since my peer for the smtp client is always Gmail, this isn?t an issue for me, but I was wondering - why does this default to ?no? ?  I note the warning in postconf(5) that states for slow network connections this can cause problems with TLS, but I am assuming that this doesn?t apply to most configurations.  
>>>
>>> Why wouldn?t I want this normally enabled ?
>
> It's not safe to make this the Postfix default, but you're welcome
> to override that if you are sure that connections will never be
> slow.
>
>    Wietse

Reply | Threaded
Open this post in threaded view
|

Re: Question regarding smtp_per_record_deadlne parameter

Noel Jones-2
On 12/5/2017 11:30 AM, J Doe wrote:
> Hi Noel and Wietse,
>
> Thank you for your prompt feedback.
>
> I think (in the quest to explore this more fully), I will try enabling this for a short term and see what sort of TLS issues I may have.  The server I described in previous mails is low volume so I believe it’s ideal for testing something like this.
>
> If anyone’s interested, I can always report back to the list about it.
>
> - J

If you're only connecting to google over a decent internet link, I
doubt you'll see any effect whatsoever.  Kinda like me using polar
bear bait in Tennessee.



  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding smtp_per_record_deadlne parameter

J Doe

> On Dec 5, 2017, at 1:46 PM, Noel Jones <[hidden email]> wrote:
>
> If you're only connecting to google over a decent internet link, I
> doubt you'll see any effect whatsoever.  Kinda like me using polar
> bear bait in Tennessee.
>
>  -- Noel Jones

Hi Noel,

That actually reminded me of something that crossed my mind, today - I forgot about the inherently dynamic nature of routing.

Even though my server is within North America and it is extremely likely that I am hitting the closest node of Google’s GMail servers in North America, as routes are updated over time, there’s the possibility of the mail going over a poor connection in a worst case scenario.

I know that’s less likely given the North American scenario, but it helped me understand even more why this setting would not be enabled by default.

- J

PS - Polar bear bait in Tennessee is actually very effective against the rare and elusive country music polar bear, a breed seldom seen but known to frequent those parts on vacation, in search of some tunes . . .
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding smtp_per_record_deadlne parameter

Viktor Dukhovni


> On Dec 5, 2017, at 10:24 PM, J Doe <[hidden email]> wrote:
>
> That actually reminded me of something that crossed my mind, today - I forgot about the inherently dynamic nature of routing.
>
> Even though my server is within North America and it is extremely likely that I am hitting the closest node of Google’s GMail servers in North America, as routes are updated over time, there’s the possibility of the mail going over a poor connection in a worst case scenario.
>
> I know that’s less likely given the North American scenario, but it helped me understand even more why this setting would not be enabled by default.

Note that distance alone would not typically cause any problems here,
the deadline time is applier per *line* from the client, whether an
SMTP command, or line of body content, and Postfix limits such lines
to 4096 bytes (storing partial lines in the queue file as needed to
support longer logical lines).

So to fail the deadline timer a sender would have to be unable to
deliver 4096 bytes in ~300s (no stress) or 10s (stress).  Either
way, that's enough time to stream 4k from the Moon at any plausible
bandwidth.  I don't think that deadline timers are nearly as risky
as one might conclude from the disclaimers, it is just that they have
not been as widely tested, so operational experience is limited.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Question regarding smtp_per_record_deadlne parameter

Wietse Venema
Viktor Dukhovni:

>
>
> > On Dec 5, 2017, at 10:24 PM, J Doe <[hidden email]> wrote:
> >
> > That actually reminded me of something that crossed my mind, today - I forgot about the inherently dynamic nature of routing.
> >
> > Even though my server is within North America and it is extremely likely that I am hitting the closest node of Google?s GMail servers in North America, as routes are updated over time, there?s the possibility of the mail going over a poor connection in a worst case scenario.
> >
> > I know that?s less likely given the North American scenario, but it helped me understand even more why this setting would not be enabled by default.
>
> Note that distance alone would not typically cause any problems here,
> the deadline time is applier per *line* from the client, whether an
> SMTP command, or line of body content, and Postfix limits such lines
> to 4096 bytes (storing partial lines in the queue file as needed to
> support longer logical lines).
>
> So to fail the deadline timer a sender would have to be unable to
> deliver 4096 bytes in ~300s (no stress) or 10s (stress).  Either
> way, that's enough time to stream 4k from the Moon at any plausible
> bandwidth.  I don't think that deadline timers are nearly as risky
> as one might conclude from the disclaimers, it is just that they have
> not been as widely tested, so operational experience is limited.

With TLS turned on, the deadline is enforced per TLS message, which
can be up to 16kbytes. 16kbytes in 10s would be difficult with a
dialup or low-tech cellular network.

        Wietse

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding smtp_per_record_deadlne parameter

J Doe
Hi Wietse,

> On Dec 6, 2017, at 8:00 AM, Wietse Venema <[hidden email]> wrote:
>
> Viktor Dukhovni:
>
> With TLS turned on, the deadline is enforced per TLS message, which
> can be up to 16kbytes. 16kbytes in 10s would be difficult with a
> dialup or low-tech cellular network.
>
>    Wietse
>
>    Wietse

I am guessing that would extend to most SATCOM connections (Iridium, etc.), as well ?

Thanks,

- J
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding smtp_per_record_deadlne parameter

Viktor Dukhovni


> On Dec 6, 2017, at 3:33 PM, J Doe <[hidden email]> wrote:
>
> I am guessing that would extend to most SATCOM connections (Iridium, etc.), as well ?

Satellite relays aren't necessarily low bandwidth, that's often not a problem,
what you can't avoid is high(er) latency[1].

--
        Viktor.

[1] "Money can buy bandwidth, but latency is forever".

                        -- John Mashey