On Sat, Sep 18, 2010 at 8:51 AM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
Section 3.4. Address Specification of RFC2822 specifies
name-addr = [display-name] angle-addr
What are the length limits on the display-name field? I take it a long
display-name
value would simply be folded as described under 2.2.3. Long Header Fields
AFAICT the relevant specifications impose no limits on the size of the
display-name. What implementations actually do is another matter, of course. I
believe I've encountered limits as low as 64 octets. I certainly wouldn't
recommend putting in stuff longer than 100 or so octets and expect it to pass
through everything intact.
Thanks a lot for your replies, Ned and Hector!
Indeed, I tracked down the display-name rule in
display-name = phrase
phrase = 1*word / obs-phrase
where 1*word implies no length limit (RFC 2234)
When I asked about clients, I meant clients that connect to the mail
server to send an email message, not end-user
or display clients. For example, qmail-remote, and gateways when
passing a message to another server. Here
I thought the To: header being within the message they would not touch
it, or parse it and just pass it on, so
that "trace fields are prepended to the message" (A.4 in the Appendix )
Would such clients leave a display-name unchanged? I would think only
the total email length limit would come
into play, which is usually pretty large (measured in MB)
Stephan
Are there practical length limits with respect to current SMTP clients
and servers?
Given that there are clients which don't show users the display-name at all, I
suppose the practical length limit could be seen as zero. Those clients that
do
display this information often allocated a fairly narrow field to it, so I
wouldn't count on anything more than 30-40 characters (not octets) being
visible.
Ned
--
Stephan Wehner
-> http://stephan.sugarmotor.org (blog and homepage)
-> http://loggingit.com
-> http://www.thrackle.org
-> http://www.buckmaster.ca
-> http://www.trafficlife.com
-> http://stephansmap.org -- http://blog.stephansmap.org
-> http://twitter.com/stephanwehner / @stephanwehner