Re: [Emailcore] Ticket #14: G.7.8. Review different size limits

Michael Peddemors <michael@linuxmagic.com> Fri, 16 July 2021 15:52 UTC

Return-Path: <michael@linuxmagic.com>
X-Original-To: emailcore@ietfa.amsl.com
Delivered-To: emailcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC553A3BD6 for <emailcore@ietfa.amsl.com>; Fri, 16 Jul 2021 08:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmQIf8HIlzit for <emailcore@ietfa.amsl.com>; Fri, 16 Jul 2021 08:52:44 -0700 (PDT)
Received: from mail-ob.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id D820D3A0913 for <emailcore@ietf.org>; Fri, 16 Jul 2021 08:52:42 -0700 (PDT)
Received: (qmail 31307 invoked from network); 16 Jul 2021 15:52:40 -0000
Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (AES128-GCM-SHA256 encrypted) SMTP (d99f7f72-e64d-11eb-9f59-c35c2591458d); Fri, 16 Jul 2021 08:52:40 -0700
To: emailcore@ietf.org
References: <20210715221921.C6E9F239F6B6@ary.qy> <8b551cf1-131b-cf43-5e61-cabf6fb9e2e6@tana.it> <01S1GPHZJUWQ005PTU@mauve.mrochek.com>
From: Michael Peddemors <michael@linuxmagic.com>
Organization: LinuxMagic Inc.
Message-ID: <af9b647f-bf21-82f9-174c-5c9698460f26@linuxmagic.com>
Date: Fri, 16 Jul 2021 08:52:40 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <01S1GPHZJUWQ005PTU@mauve.mrochek.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-MagicMail-OS: Linux 2.2.x-3.x
X-MagicMail-UUID: d99f7f72-e64d-11eb-9f59-c35c2591458d
X-MagicMail-Authenticated: michael@wizard.ca
X-MagicMail-SourceIP: 104.128.144.8
X-MagicMail-RegexMatch: 0
X-MagicMail-EnvelopeFrom: <michael@linuxmagic.com>
X-Archive: Yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/TqtdMRRq4s9DsGZyKMKIUSTjnfA>
Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits
X-BeenThere: emailcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EMAILCORE proposed working group list <emailcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emailcore>, <mailto:emailcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emailcore/>
List-Post: <mailto:emailcore@ietf.org>
List-Help: <mailto:emailcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emailcore>, <mailto:emailcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jul 2021 15:52:58 -0000

Vote against changing existing limits, it is not just MTA's that have to 
deal with this, but many email analytics programs etc..

But I agree that we should consider some 'best practices' size limits on 
headers..

Can we start looking at existing limits in more details?

But as I think John pointed out, creators of HTML messages have long be 
operating with poor practices.  Have even seen some messages where the 
whole HTML part was on a single line. But we could have a SHOULD 
indication of max line limits, while a long line is 'technically' not an 
issue, there are many practical examples why it is not preferred, eg 
string matching in long lines, not to mention simple things like viewing 
a message source and how ugly difficult this is when the message creates 
a very long scroll window.

On 2021-07-16 8:34 a.m., Ned Freed wrote:
>> On Fri 16/Jul/2021 00:19:21 +0200 John Levine wrote:
>> > It appears that Viktor Dukhovni  <emailcore@ietf.org> said:
>> >>> On 15 Jul 2021, at 4:16 pm, John Levine <johnl@taugh.com> wrote:
>> >>>
>> >>> PS: I don't feel strongly about lifting the 1000 octet limit but I 
>> would like
>> >>> to understand how widely it's enforced by mail receivers.
>> >>
>> >>On the receiving side Postfix does not enforce any physical
>> >>line length limits on message body lines, ...
>> >
>> > I realize qmail isn't very popular any more, although you will find
>> > it hiding in the guts of a lot of packaged mail systems.  For incoming
>> > messages, it's all dynamic and there's no length limits.  For outgoing
>> > messages it politely wraps headers to 80 bytes but leaves bodies alone.
> 
> 
>> Courier has similar limits on submission.  Some 100000 for the whole 
>> header
>> (configurable since 2007, BOFHHEADERLIMIT) and 5000 bytes line length 
>> limit.
> 
> It's really quite unfortunate that there's no limit specified on header
> size, since sending a huge header is yet another way to exhaust resources
> on a poorly implemented MTA.
> 
> However, adding one is clearly beyond the scope of what we're allowed to
> do in emailcore. Even a change to make the limits we have "real" is pushing
> it.
> 
>                  Ned
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> -- 
>> Emailcore mailing list
>> Emailcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/emailcore
> 



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.