Re: Question regarding smtp_per_record_deadlne parameter
> On Dec 6, 2017, at 3:33 PM, J Doewrote: > > 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
Re: Question regarding smtp_per_record_deadlne parameter
Hi Wietse, > On Dec 6, 2017, at 8:00 AM, Wietse Venemawrote: > > 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
Re: Question regarding smtp_per_record_deadlne parameter
Viktor Dukhovni: > > > > On Dec 5, 2017, at 10:24 PM, J Doewrote: > > > > 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
Re: Question regarding smtp_per_record_deadlne parameter
> On Dec 5, 2017, at 10:24 PM, J Doewrote: > > 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.
Re: Question regarding smtp_per_record_deadlne parameter
> On Dec 5, 2017, at 1:46 PM, Noel Joneswrote: > > 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 . . .
Re: Question regarding smtp_per_record_deadlne parameter
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
Re: Question regarding smtp_per_record_deadlne parameter
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 Venemawrote: > > 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 >>>u...@example.com users-gmail-addr...@gmail.com >>> >>> 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
Re: Question regarding smtp_per_record_deadlne parameter
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 > > u...@example.com users-gmail-addr...@gmail.com > > > > 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
Re: Question regarding smtp_per_record_deadlne parameter
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 > u...@example.com users-gmail-addr...@gmail.com > > 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
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 u...@example.com users-gmail-addr...@gmail.com 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