DevHeads.net

Question regarding smtp_per_record_deadlne parameter

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
<a href="mailto: ... at example dot com"> ... at example dot com</a> <a href="mailto:users-gmail- ... at gmail dot com">users-gmail- ... at gmail dot com</a>

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] <a href="http://www.postfix.org/VIRTUAL_README.html" title="www.postfix.org/VIRTUAL_README.html">www.postfix.org/VIRTUAL_README.html</a>

Comments

Re: Question regarding smtp_per_record_deadlne parameter

By Noel Jones at 12/04/2017 - 18:47

On 12/4/2017 3:35 PM, J Doe wrote:

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

Re: Question regarding smtp_per_record_deadlne parameter

By Wietse Venema at 12/04/2017 - 20:39

Noel Jones:
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

Re: Question regarding smtp_per_record_deadlne parameter

By J Doe at 12/05/2017 - 13:30

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

Re: Question regarding smtp_per_record_deadlne parameter

By Noel Jones at 12/05/2017 - 14:46

On 12/5/2017 11:30 AM, J Doe 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

Re: Question regarding smtp_per_record_deadlne parameter

By J Doe at 12/05/2017 - 23:24

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

Re: Question regarding smtp_per_record_deadlne parameter

By Viktor Dukhovni at 12/06/2017 - 00:26

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.

Re: Question regarding smtp_per_record_deadlne parameter

By Wietse Venema at 12/06/2017 - 09:00

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

Re: Question regarding smtp_per_record_deadlne parameter

By J Doe at 12/06/2017 - 16:33

Hi Wietse,

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

Thanks,

- J

Re: Question regarding smtp_per_record_deadlne parameter

By Viktor Dukhovni at 12/06/2017 - 16:40

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