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 Are there practical length limits with respect to current SMTP clients and servers? Stephan
Stephan Wehner 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
>
> Are there practical length limits with respect to current SMTP clients
> and servers?
Stephen,
The display name is not used in SMTP. Only the actual address is used
at the SMTP level.
However, in the message 5322 headers itself, the MUA, mail readers,
display systems, etc, will use the display name extracted from
5322.From and 5322.To
The only practical limit I can think of is:
old days: 80 character limit or 72 to limit single line console display:
12345......................80
From: display-name
For the new days with gui, I guess that would be dependent on the GUI
(Continue reading)> 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. > 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
On Sat, Sep 18, 2010 at 8:51 AM, Ned Freed <ned.freed <at> mrochek.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(Continue reading)
> On Sat, Sep 18, 2010 at 8:51 AM, Ned Freed <ned.freed <at> mrochek.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.(Continue reading)
On Mon, Sep 20, 2010 at 12:44 PM, Ned Freed <ned.freed <at> mrochek.com> wrote: > >> 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 ) > Dream on. That's not how things work in th real world. Lots of intermediaries > perform all sorts of processing of header fields. The legality or illegality of > doing this is mostly irrelevant, since you have to deal with what's out there, > not what the standards-writers hoped would be out there, but even then, > specific header modifications are specifically condoned by vaiorus standards, > e.g., MIME downgrading. > In the specific case of To: fields, an obvious one is for submission servers to > rewrite addresses to eliminae short form names and other local crap. > The answer is no, you cannot count on it. > >> I would think only >> the total email length limit would come >> into play, which is usually pretty large (measured in MB) > > Again, you're dreaming if you think this is true. Alright, let's look at an alternative to what I'm trying to do. How is it with using Optional Fields (section 3.6.8). Are they safewith respect to "intermediaries perform[ing] all sorts of processing of header fields"?(Continue reading)
> Alright, let's look at an alternative to what I'm trying to do. Perhaps you should describe what you're trying to do. It's very difficult to make suggesions without knowing the semantics you're trying to get. > How is it with using Optional Fields (section 3.6.8). Are they safewith respect > to "intermediaries perform[ing] all sorts of processing of header fields"? First of all, the semantics of display-names and optional headers are very different. A display-name is always associated with a header address. If whatever you're doing needs to track along with header addresses, then optional fields do not offer a solution, because agents that mess with header addresses won't know to make the corresponding change in your private information fields. OTOH, if whatever you're doing isn't associated with header addresses, then you shouldh't have tried to cram the information into a display-name to begin with. Now, as for using optional fields, the answer is that as long as you pick one nobody else is using for something, I'd say they're safe up to 4K octets or so. (You can also use more than one if you need the space.) Beyond that you may start running into implementation limits again. Putting a vendor name in the field name is often a good plan - it makes it far less likely some else will use it for something different. You'll need to properly fold the field if it is very long, and you should be tolerant of folding changes. Ned(Continue reading)
Stephan Wehner wrote: >> Again, you're dreaming if you think this is true. > > Alright, let's look at an alternative to what I'm trying to do. > > How is it with using Optional Fields (section 3.6.8). Are they safe with respect > to "intermediaries perform[ing] all sorts of processing of header fields"? > > Stephan I think we all work on the premise that "passthru" mail is "safe." That has been the rule of thumb. But you never know what mail flows, paths and channels exist and do all sorts of things. In our system, there is a heterogeneous network transformation to a common structure and from there are XYZ transformations back into XYZ network or channels or no transformations at all. You never know what has been filtered or persistent with optional fields. -- -- Hector, Engineering & Technical Support Santronics Software, Inc. http://www.santronics.com (sales) http://www.winserver.com (support) http://www.winserver.com/AupInfo (Online AUP Help) Office: 305-248-3204(Continue reading)
RSS Feed
