> On 12 May 2023, at 14:40, Paul Gregg via mailop <mailop@mailop.org> 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.
> jjjjAnother 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
