Re: [mailop] Thoughts on envelope address local-part length limits
Dňa 15. mája 2023 17:09:17 UTC používateľ Brandon Long via mailop napísal: >The full namespace is also not available, our experience was that relying >on case in that portion of the >address was problematic, as there were many systems who would lowercase the >address before using it. While my system doesn't support SMTPUTF8 (dovecot MDA), thus i have no experiences with that nor 4bit chars are in our language, but in worst case, the 64 bytes can be only 16 UTF-8 chars. And 16 chars is not enough for my system already... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
On Fri, May 12, 2023 at 12:44 PM John Levine via mailop wrote: > It appears that Bill Cole via mailop < > mailop-20160...@billmail.scconsult.com> said: > >On 2023-05-12 at 09:40:14 UTC-0400 (Fri, 12 May 2023 13:40:14 +) > >Paul Gregg via mailop > >is rumored to have said: > > > >> I suspect with verp/bounce addressing widely in use now, 64 octets > >> just isn't enough these days. > > > >Hogwash. 64 mail-safe octets is adequate for every domain to give a > >unique printable(!) deliverable local-part to every elementary particle > >in the universe. It's a namespace adequate for ANYTHING > > If only. You run out of octets pretty quickly when you are doing hacks > like the IETF's anti-DMARC workaround which turns > mailop-20160...@billmail.scconsult.com into > mailop-20160228=40billmail.scconsult@dmarc.ietf.org Yes, VERP and SRS are the two most obvious cases where their design inherently doesn't work with the limit (encoding the full email address into the mailbox portion) You'd need to either get fancy with the domain portion, which has its own complications (multi-level star DNS?) or use a lookup table. The full namespace is also not available, our experience was that relying on case in that portion of the address was problematic, as there were many systems who would lowercase the address before using it. Brandon ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
Your sentence does sound to me that it's fine for senders to not adhere to these limits and be able to complain about receivers who would block those messages. I'm on the other side would state that in a more sarcastic way, like "You can totally ignore these limits but have no right to complain if others reject you because of it." With a stronger emphasis on the "You should not do it!", instead of only stating you can do it for your own outbound stuff, referencing Postels Law, and therefore implicitly stating that rejecting "invalid" message stream is kind of bad behavior. / Tobias -Original Message- From: mailop On Behalf Of Slavko via mailop Sent: Monday, May 15, 2023 2:39 PM To: mailop Subject: Re: [mailop] Thoughts on envelope address local-part length limits Dňa 15. mája 2023 7:44:07 UTC používateľ Tobias Herkula via mailop napísal: >Be careful with references to Postels robustness principle and look >into that >https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance >(formally known as "postel-was-wrong") And if you reference 4.5.3.1, >you should not omit > >"Objects larger than these sizes SHOULD be avoided when possible." >And >"Clients MAY attempt to transmit these, but MUST be prepared for a server to >reject them if they cannot be handled by it." > >With the substantial critique on the robustness principle and the underlying >hierarchy of MUST, SHOULD and MAY from rfc2119, these two paragraphs out of >rfc5321#4.5.3.1 will push the minimum/maximum discussion into the obey the >limit corner and not the "do as you like" corner, but that's only my humble >opinion. And how this differs from what i wrote: If you really want, apply mentioned limits to your outgoing messages... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
> On 14 May 2023, at 18:03, Paul Gregg via mailop wrote: > > On Fri, May 12, 2023 at 05:54:28PM +, Slavko via mailop wrote: >> Dňa 12. mája 2023 13:40:14 UTC používateľ Paul Gregg via mailop >> napísal: >> >>> 4.5.3.1. Size Limits and Minimums >> >> When you read RFC, you MUST read all, not only interesting parts. >> Yes, sometime it is hard, but notice the sentence in this section: >> >> Every implementation MUST be able to receive objects of at >> least these sizes. >> >> I understand that these limits are not maximum which can be >> used, but rather minimum which have to be supported. That >> is shown in the same section latter: >> >> To the maximum extent possible, implementation techniques >> that impose no limits on the length of these objects should be >> used. >> >> It IMO clearly suggests to not limit these things. > > I'm not here to throw stones at semantic reasoning, but it is really > difficult to read "The maximum total length of " to mean "support > this at a minumum but feel free to blow way past it". > > My original question was if the 64 octet limit is pointless now. > Seems like it is. Likely, if you want to deliver wanted mail. As a postmaster or as an email software developer that’s a big part of your job. But given this issue was particularly visible because you completely misread RFC 5321 - to the extent you think all email addresses start with the “<“ character - and started rejecting a lot of entirely compliant mail because of that misunderstanding you may want to wait a while before doing any more RFC rules lawyering. Cheers, Steve___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
Dňa 15. mája 2023 7:44:07 UTC používateľ Tobias Herkula via mailop napísal: >Be careful with references to Postels robustness principle and look into that >https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance (formally >known as "postel-was-wrong") >And if you reference 4.5.3.1, you should not omit > >"Objects larger than these sizes SHOULD be avoided when possible." >And >"Clients MAY attempt to transmit these, but MUST be prepared for a server to >reject them if they cannot be handled by it." > >With the substantial critique on the robustness principle and the underlying >hierarchy of MUST, SHOULD and MAY from rfc2119, these two paragraphs out of >rfc5321#4.5.3.1 will push the minimum/maximum discussion into the obey the >limit corner and not the "do as you like" corner, but that's only my humble >opinion. And how this differs from what i wrote: If you really want, apply mentioned limits to your outgoing messages... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
Be careful with references to Postels robustness principle and look into that https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance (formally known as "postel-was-wrong") And if you reference 4.5.3.1, you should not omit "Objects larger than these sizes SHOULD be avoided when possible." And "Clients MAY attempt to transmit these, but MUST be prepared for a server to reject them if they cannot be handled by it." With the substantial critique on the robustness principle and the underlying hierarchy of MUST, SHOULD and MAY from rfc2119, these two paragraphs out of rfc5321#4.5.3.1 will push the minimum/maximum discussion into the obey the limit corner and not the "do as you like" corner, but that's only my humble opinion. / Tobias -Original Message- From: mailop On Behalf Of Slavko via mailop Sent: Friday, May 12, 2023 7:54 PM To: mailop Subject: Re: [mailop] Thoughts on envelope address local-part length limits Dňa 12. mája 2023 13:40:14 UTC používateľ Paul Gregg via mailop napísal: >4.5.3.1. Size Limits and Minimums When you read RFC, you MUST read all, not only interesting parts. Yes, sometime it is hard, but notice the sentence in this section: Every implementation MUST be able to receive objects of at least these sizes. I understand that these limits are not maximum which can be used, but rather minimum which have to be supported. That is shown in the same section latter: To the maximum extent possible, implementation techniques that impose no limits on the length of these objects should be used. It IMO clearly suggests to not limit these things. IMO, one have to consider, that there was more resorce constrained HW in time of that RFC and even nowadays there can be embeded systems with no GBs of RAM (and so). If that is not your case, simple do not limit on that, or limit on values which can be harmfull for you (eg. file system mailbox name length limits, or so). If you really want, apply mentioned limits to your outgoing messages only. Do you know: be strict on what you send, and be liberal on what you receive. But if you really not need them, applying these limits is wasting of resorces, for checking, for develop rules, for testing, for maintaining, for support responses... When you apply these limits, you will not prevent SPAMs, nor phishings, nor scams, only ugly addresses and we have bigger problems than ugly addresses :-) regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
It appears that Paul Gregg via mailop said: >My original question was if the 64 octet limit is pointless now. >Seems like it is. No, not quite. One time I asked Ned Freed why the Oracle MTA he supported, which is widely used in corporate systems, enforced those limits. He told me that it was heavily threaded and the storage allocator used fixed size chunks, which makes sense. He also didn't think that enforcing the limits was much of a problem for the mail recipients wanted to receive. So like I said, if it's easy to allow longer lengths, sure, go ahead, but don't count on it when you're sending to other people. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
On Fri, May 12, 2023 at 05:54:28PM +, Slavko via mailop wrote: > Dňa 12. mája 2023 13:40:14 UTC používateľ Paul Gregg via mailop > napísal: > > >4.5.3.1. Size Limits and Minimums > > When you read RFC, you MUST read all, not only interesting parts. > Yes, sometime it is hard, but notice the sentence in this section: > > Every implementation MUST be able to receive objects of at > least these sizes. > > I understand that these limits are not maximum which can be > used, but rather minimum which have to be supported. That > is shown in the same section latter: > > To the maximum extent possible, implementation techniques > that impose no limits on the length of these objects should be > used. > > It IMO clearly suggests to not limit these things. I'm not here to throw stones at semantic reasoning, but it is really difficult to read "The maximum total length of " to mean "support this at a minumum but feel free to blow way past it". My original question was if the 64 octet limit is pointless now. Seems like it is. PG ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
On 2023-05-12 at 16:52:38 UTC-0400 (Fri, 12 May 2023 13:52:38 -0700) Brandon Long via mailop is rumored to have said: On Fri, May 12, 2023 at 8:54 AM Bill Cole via mailop wrote: On 2023-05-12 at 09:40:14 UTC-0400 (Fri, 12 May 2023 13:40:14 +) Paul Gregg via mailop is rumored to have said: I suspect with verp/bounce addressing widely in use now, 64 octets just isn't enough these days. Hogwash. 64 mail-safe octets is adequate for every domain to give a unique printable(!) deliverable local-part to every elementary particle in the universe. It's a namespace adequate for ANYTHING And yet IP6 went with 128 for some reason... Are you conflating bits with mail-safe octets (~6 bits each)? There are about 400 bits of information available in the 512-bit container of a 64-character local-part. Each domain has a namespace for sender local parts that is 3 times as large (bitwise) as the whole human race has for IPv6 addresses. as if there are other concerns than being able to compress the information into as few bits as possible. No need to programmatically compress data to use the space efficiently, just be good at naming. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
On Fri, May 12, 2023 at 8:54 AM Bill Cole via mailop wrote: > On 2023-05-12 at 09:40:14 UTC-0400 (Fri, 12 May 2023 13:40:14 +) > Paul Gregg via mailop > is rumored to have said: > > > I suspect with verp/bounce addressing widely in use now, 64 octets > > just > > isn't enough these days. > > Hogwash. 64 mail-safe octets is adequate for every domain to give a > unique printable(!) deliverable local-part to every elementary particle > in the universe. It's a namespace adequate for ANYTHING > And yet IP6 went with 128 for some reason... as if there are other concerns than being able to compress the information into as few bits as possible. Brandon ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
It appears that Bill Cole via mailop said: >On 2023-05-12 at 09:40:14 UTC-0400 (Fri, 12 May 2023 13:40:14 +) >Paul Gregg via mailop >is rumored to have said: > >> I suspect with verp/bounce addressing widely in use now, 64 octets >> just isn't enough these days. > >Hogwash. 64 mail-safe octets is adequate for every domain to give a >unique printable(!) deliverable local-part to every elementary particle >in the universe. It's a namespace adequate for ANYTHING If only. You run out of octets pretty quickly when you are doing hacks like the IETF's anti-DMARC workaround which turns mailop-20160...@billmail.scconsult.com into mailop-20160228=40billmail.scconsult@dmarc.ietf.org I also know people who do much fancier versions of timestamped addresses like the ones you use. Yeah, if you're a good enough programmer you can compress it and base36 encode or you can do what I do and put the magic into the domain, e.g. mailop-20160...@billmail.scconsult.com.dmarc.fail, it but again, if only. On the one hand, I don't think people get to complain if their overlong addresses can't be delivered, but I also think that in the common case that it's easy to handle longer addresses, you should do so. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
Dňa 12. mája 2023 13:40:14 UTC používateľ Paul Gregg via mailop napísal: >4.5.3.1. Size Limits and Minimums When you read RFC, you MUST read all, not only interesting parts. Yes, sometime it is hard, but notice the sentence in this section: Every implementation MUST be able to receive objects of at least these sizes. I understand that these limits are not maximum which can be used, but rather minimum which have to be supported. That is shown in the same section latter: To the maximum extent possible, implementation techniques that impose no limits on the length of these objects should be used. It IMO clearly suggests to not limit these things. IMO, one have to consider, that there was more resorce constrained HW in time of that RFC and even nowadays there can be embeded systems with no GBs of RAM (and so). If that is not your case, simple do not limit on that, or limit on values which can be harmfull for you (eg. file system mailbox name length limits, or so). If you really want, apply mentioned limits to your outgoing messages only. Do you know: be strict on what you send, and be liberal on what you receive. But if you really not need them, applying these limits is wasting of resorces, for checking, for develop rules, for testing, for maintaining, for support responses... When you apply these limits, you will not prevent SPAMs, nor phishings, nor scams, only ugly addresses and we have bigger problems than ugly addresses :-) regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
> On 12 May 2023, at 14:40, Paul Gregg via mailop wrote:
>
> I'd like to start a discussion on folks opinions(*) on enforcing
> Envelope Sender/Recipient local-part length limits.
>
> *opinions - because no mail operator seems to agree what it should be.
>
> For context, RFC5321 defines local-part (the bit of an envelope address
> to the left of the @ in an email address as) in the Size Limits and
> Minimums section as:
> 4.5.3.1. Size Limits and Minimums
> ...
> 4.5.3.1.1. Local-part
>
> The maximum total length of a user name or other local-part is 64
> octets.
>
>
> You'll find lots of people talking about this if you google, but they
> mostly seem to refer to RFC822 (and subsequents) not being explicit
> (obviously missing the point that 822 is about the Headers while 821 is
> for SMTP protocol).
But 5321’s BNF refers to 5322 for things like atext, so you do need to
read both to understand the syntax.
> 821, 2821, 5321 and errata have increasingly clarified this towards:
> - local-part max is 64 bytes (including the <) so really 63 octets
No, the “<“ is not part of the local part, rather the argument to MAIL FROM
consists of the source mailbox between “<“ and “>” brackets. The source
mailbox is your normal local-part@domain, where the maximum total length of
a user name or other local-part is 64 octets.
i.e. a 64 octet local part is valid.
MAIL FROM:<{between 1 and 64 octets of dot-string or quoted-string}@{reasonable
hostname}>
> - domain max is 255 octets
> - max total path is 256 octets
>
> We (Proofpoint Essentials) recently began enforcing <64 octets for the
> local-part of an envelope address. However, we are seeing a lot of
> senders using way longer than this.
>
> For example, looking at yesterday's traffic, 90% use 64 octets (so 65
> when you include the <)
I have seen multiple reports of emails with valid return-paths being rejected
by proofpoint endpoints over the past day or so.
> Another 3-4% live in the 65-69 octets range
> 2% at 73/74 octets...
> The largest was 217 octets
If it’s 65 or more characters you can legitimately reject it and still be
talking
SMTP, but you will find some VERP strings longer than that, and will end
up rejecting wanted mail.
If it’s 64 characters or less it’s valid per RFC, and if you reject it as an
invalid
sender address you’re the end of the transaction that’s no respecting the
RFCs.
>
> None of these are 'user' addresses, they're all bounce identification,
> verp / recipient identifying or look like exchange distro list with AD
> encodings. They come from some big names, amazon, salesforce, etc.
>
> I suspect with verp/bounce addressing widely in use now, 64 octets just
> isn't enough these days.
>
> So, my question(s) to mailop - Is the 'local-part' definition no longer
> fit for purpose? Has that horse already bolted? Do you impose any limit
> and if so, what?
Unless it’ll cause security or stability issues it’s reasonable to be liberal in
what you accept from others, especially if not doing so would mean rejecting
email that your customers would like to receive. Doubly so if you’re not
extremely sure that your interpretation of the RFC limits is correct.
Cheers,
Steve
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
On 2023-05-12 at 09:40:14 UTC-0400 (Fri, 12 May 2023 13:40:14 +) Paul Gregg via mailop is rumored to have said: I suspect with verp/bounce addressing widely in use now, 64 octets just isn't enough these days. Hogwash. 64 mail-safe octets is adequate for every domain to give a unique printable(!) deliverable local-part to every elementary particle in the universe. It's a namespace adequate for ANYTHING Bulk mailers are just lazy and their median cluefullness is remarkably low. So, my question(s) to mailop - Is the 'local-part' definition no longer fit for purpose? Has that horse already bolted? It's fine. The bozos ignoring it will have the low-grade background of corner-case failures they richly deserve. Competitive pressures on basic technical competence issues are GOOD. Do you impose any limit Yes. and if so, what? It varies. This is one of those cases where obscurity is good. I will say that anyone using longer envelope senders knows (OR SHOULD KNOW) that they are evading bounces. By operating outside of the formal rules, they invite hostile reactions outside of the formal rules. Senders should not construct local-parts longer than 63 characters for use in SMTP. The fact that it often works at some sites should not be taken as evidence that it can or should work everywhere all the time. OTOH, what you do in headers is mostly your own business, except when it starts to correlate to spamminess. Of course, if you want replies to work, you won't put out-of-spec addresses where they might be replied to. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Thoughts on envelope address local-part length limits
I'd like to start a discussion on folks opinions(*) on enforcing Envelope Sender/Recipient local-part length limits. *opinions - because no mail operator seems to agree what it should be. For context, RFC5321 defines local-part (the bit of an envelope address to the left of the @ in an email address as) in the Size Limits and Minimums section as: 4.5.3.1. Size Limits and Minimums ... 4.5.3.1.1. Local-part The maximum total length of a user name or other local-part is 64 octets. You'll find lots of people talking about this if you google, but they mostly seem to refer to RFC822 (and subsequents) not being explicit (obviously missing the point that 822 is about the Headers while 821 is for SMTP protocol). 821, 2821, 5321 and errata have increasingly clarified this towards: - local-part max is 64 bytes (including the <) so really 63 octets - domain max is 255 octets - max total path is 256 octets We (Proofpoint Essentials) recently began enforcing <64 octets for the local-part of an envelope address. However, we are seeing a lot of senders using way longer than this. For example, looking at yesterday's traffic, 90% use 64 octets (so 65 when you include the <) Another 3-4% live in the 65-69 octets range 2% at 73/74 octets... The largest was 217 octets None of these are 'user' addresses, they're all bounce identification, verp / recipient identifying or look like exchange distro list with AD encodings. They come from some big names, amazon, salesforce, etc. I suspect with verp/bounce addressing widely in use now, 64 octets just isn't enough these days. So, my question(s) to mailop - Is the 'local-part' definition no longer fit for purpose? Has that horse already bolted? Do you impose any limit and if so, what? Thanks, PG ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
