From: "Michał Górny" <mgorny@gentoo.org>
To: mlmmj@mlmmj.org
Subject: [mlmmj] Subscription confirmation address length vs RFC 5321
Date: Thu, 13 Oct 2016 13:10:00 +0000 [thread overview]
Message-ID: <20161013151000.3b8848ae.mgorny@gentoo.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]
Hello, everyone.
We've recently had a report that one of our users was unable to confirm
subscription to our mailing lists [1]. It turns out, that in some cases
the length of the local part of the subscription address exceeds
the limit of 64 characters imposed by RFC 5321 (SMTP) [2].
While it didn't cause any major issues so far, it seems that a growing
number of new mail providers are actually enforcing more strict
policies and refusing to send e-mail with the length exceeding limits
imposed by the RFC.
FWICS, the local part of the subscription address is constructed
of the following segments:
mailing-list-name "+confsub-" 16-random-hex "-" sender-address
Out of this, the middle segments already take 26 of 64 allowed octets.
The longest name in our mailing lists has 26 characters. If we round
that up to 32, we already get 58 of 64 which leaves practically no room
for the sender address. I think the sender address can legally be up
to 64+1+255 = 320 characters (unless I'm missing some additional
restriction).
Of course, I'm talking about the limits here. Commonly, the mailing
list names and sender addresses will be shorter but they are still
barely fitting in the 64 octets allowed by the RFC. Therefore, I'd like
to ask about the possibility of shortening the subscription addresses.
My first thought would be to remove the sender address part. I think we
should be able to reasonably assume the 16 random hex digits should be
unique enough to reduce the possibility of collision and the sender
address is stored inside the file anyway.
What do you think?
[1]:https://bugs.gentoo.org/show_bug.cgi?id=596794
[2]:https://tools.ietf.org/html/rfc5321
--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]
next reply other threads:[~2016-10-13 13:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-13 13:10 Michał Górny [this message]
2016-10-17 5:10 ` [mlmmj] Subscription confirmation address length vs RFC 5321 Ben Schmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161013151000.3b8848ae.mgorny@gentoo.org \
--to=mgorny@gentoo.org \
--cc=mlmmj@mlmmj.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).