headers
Mikel Lindsaar | 1 Nov 2007 02:35
Picon
Gravatar

Non destructive folding/unfolding (ie, no insertion of whitespace in unfolding)


Hello list,

This is my first post, so I apologise if this has already been
covered.  I searched through the full text archive file of ietf-822
(after going through the full itef-smtp archive file) and could not
find a concrete answer to my question.

I am improving/fixing bugs in a Email library for Ruby - I didn't
originally write the library, so I am being very careful in any
changes I make.

One situation I have is where a X-header field and Reply-To field has
a single piece of text that is longer than the 78 octet limit, but has
no white space break.

For example:

Reply-To: <1234-1234-1234-1234-1234-1234-1234-1234-1234 <at> me-some-host-over-here.org>

The library currently folds this line as:

Reply-To:CRLF
LWSP<1234-1234-1234-1234...blah-with-no-further-fold

Now, I have two questions.

1) I believe that putting the CRLF immediately after the : in the
header field name is in violation of 2822 specifically that the header
line should contain the name, a colon, the field and terminated by a
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bill McQuillan | 1 Nov 2007 08:24
Picon
Favicon

Re: Non destructive folding/unfolding (ie, no insertion of whitespace in unfolding)


On Wed, 2007-10-31, Mikel Lindsaar wrote:

> For example:

> Reply-To: <1234-1234-1234-1234-1234-1234-1234-1234-1234 <at> me-some-host-over-here.org>

> The library currently folds this line as:

> Reply-To:CRLF
> LWSP<1234-1234-1234-1234...blah-with-no-further-fold

Quoting RFC-2822:

2.1.1. Line Length Limits

   There are two limits that this standard places on the number of
   characters in a line. Each line of characters MUST be no more than
   998 characters, and SHOULD be no more than 78 characters, excluding
   the CRLF.

I would say that the above Reply-To is a good reason to take advantage of
the SHOULD and extend the line beyond 78 characters.

I also believe that the example of folding by the existing library is
accceptable and does not violate RFC-2822.

> I saw one mention of doing this:

> Reply-To: <1234-1234-1234-1234-1234-12\CRLF
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Smith | 1 Nov 2007 11:48
Picon
Favicon

Re: Non destructive folding/unfolding (ie, no insertion ofwhitespace in unfolding)


At 01:35 01/11/2007, Mikel Lindsaar wrote:

>Hello list,
>
>This is my first post, so I apologise if this has already been
>covered.  I searched through the full text archive file of ietf-822
>(after going through the full itef-smtp archive file) and could not
>find a concrete answer to my question.
>
>I am improving/fixing bugs in a Email library for Ruby - I didn't
>originally write the library, so I am being very careful in any
>changes I make.
>
>One situation I have is where a X-header field and Reply-To field has
>a single piece of text that is longer than the 78 octet limit, but has
>no white space break.
>
>For example:
>
>Reply-To: 
><1234-1234-1234-1234-1234-1234-1234-1234-1234 <at> me-some-host-over-here.org>
>
>The library currently folds this line as:
>
>Reply-To:CRLF
>LWSP<1234-1234-1234-1234...blah-with-no-further-fold
>
>Now, I have two questions.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 Nov 2007 11:03
Picon
Picon

Re: Non destructive folding/unfolding (ie, no insertion of whitespace in unfolding)


Mikel Lindsaar wrote:

> The library currently folds this line as:

> Reply-To:CRLF
> LWSP<1234-1234-1234-1234...blah-with-no-further-fold

That depends, if you replace LWSP by one or more WSP
it's correct, if you allow another CRLF in LWSP it's broken.

> I believe that putting the CRLF immediately after the : in the
> header field name is in violation of 2822

NAK, wild guess, maybe you confused "header field" with
"header line".  The "header field" consists of the "header
field name" (incl. colon) followed by the "header field body"
(could be empty). The "header field body" can be "folded"
resulting in more than one line, and you can always insert
FWS (e.g. CRLF + WSP) behind the colon.

For values of "always" excluding NetNews articles, where
you can't fold a "header field" before the first non-WSP in
the "header field body", and where you need a "magic SP"
behind the colon (CRLF does not pass as "magic SP" ;-)

 Frank
Permalink | Reply | 0 comments |
headers
Qian Sun | 5 Nov 2007 08:09
Favicon

New Disposition type: Inline Subordinate


Hello 'email people'

RFC 2183 defines two basic disposition types, i.e. "inline" and "attachment".
But sometimes we need a more elaborate presentation than the existing disposition 
types. For example, the current advertisement way in Email or Webpage is very 
"evil", sometimes it is difficult for the users to distinguish the real contents 
from advertisement, and this is disgusting or confusing. Nowadays many email 
service providers insert advertisements in the user's email. The inserted 
advertisements normally are displayed at the end of the email, but sometimes the 
boundary between advertisements and other real contents is not clear. So that 
the recipient may be misunderstanding, the advertisements might be regarded as 
the real contents the sender writes.

However, advertisement is absolutely necessary for the development of internet 
and mobile applications. In order not to interfere with users much, the technology 
for sending advertisement kindly is needed. Email, MMS, IM and SIP messages may 
use MIME as their content body, the advertisement could also be inserted into 
the message body as a MIME content. Maybe a new disposition type can be defined 
to help users distinguish the advertisement and the real contents. Its definition 
is like this:

A bodypart should be marked "inline-subordinate" if it is intended to be displayed automatically upon
display of the message, but it should not block other displayed bodyparts, e.g., bodyparts with a regular
"inline" disposition type. It is RECOMMENDED that the client render the content marked by
inline-subordinate in a separate place away from other inline contents.

Opinion?

Cheers,
(Continue reading)

Permalink | Reply | 4 comments |
headers
ned+ietf-822 | 5 Nov 2007 20:26

Re: New Disposition type: Inline Subordinate


> Hello 'email people'

> RFC 2183 defines two basic disposition types, i.e. "inline" and "attachment".
> But sometimes we need a more elaborate presentation than the existing disposition
> types. For example, the current advertisement way in Email or Webpage is very
> "evil", sometimes it is difficult for the users to distinguish the real contents
> from advertisement, and this is disgusting or confusing. Nowadays many email
> service providers insert advertisements in the user's email. The inserted
> advertisements normally are displayed at the end of the email, but sometimes the
> boundary between advertisements and other real contents is not clear. So that
> the recipient may be misunderstanding, the advertisements might be regarded as
> the real contents the sender writes.

> However, advertisement is absolutely necessary for the development of internet
> and mobile applications. In order not to interfere with users much, the technology
> for sending advertisement kindly is needed. Email, MMS, IM and SIP messages may
> use MIME as their content body, the advertisement could also be inserted into
> the message body as a MIME content. Maybe a new disposition type can be defined
> to help users distinguish the advertisement and the real contents. Its definition
> is like this:

> A bodypart should be marked "inline-subordinate" if it is intended to be
> displayed automatically upon display of the message, but it should not block
> other displayed bodyparts, e.g., bodyparts with a regular "inline" disposition
> type. It is RECOMMENDED that the client render the content marked by
> inline-subordinate in a separate place away from other inline contents.

> Opinion?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Arnt Gulbrandsen | 5 Nov 2007 21:22
Favicon

Re: New Disposition type: Inline Subordinate


ned+ietf-822 <at> mrochek.com writes:
> OK, [...]

Thanks. I wanted to say all that, but was too tired to write clearly.

There is one more thing. The hucksters who are gluing advertising onto 
other people's outgoing mail may reasonably be assumed to do it in HTML 
too (if not now then soon), by inserting a new <div>...</div> in 
existing messages and adding some CSS. It is unreasonable to assume 
that they'll prefer to use separate and labelled bodyparts.

Arnt
Permalink | Reply | 1 comment |
headers
Hector Santos | 5 Nov 2007 22:40
Favicon

Re: New Disposition type: Inline Subordinate


Arnt Gulbrandsen wrote:
> 
> ned+ietf-822 <at> mrochek.com writes:
>> OK, [...]
> 
> Thanks. I wanted to say all that, but was too tired to write clearly.
> 
> There is one more thing. The hucksters who are gluing advertising onto 
> other people's outgoing mail may reasonably be assumed to do it in HTML 
> too (if not now then soon), by inserting a new <div>...</div> in 
> existing messages and adding some CSS. It is unreasonable to assume that 
> they'll prefer to use separate and labelled bodyparts.
> 
> Arnt

What I find fascinating is that this gentleman's belief or sense it a 
industry right to advertise on the back of others and mailers should 
pass thru unprohibited foregoing any receiver and/or user safety measures.

Right. With todays email clients, its not really a requirement to have 
MIME based text/html context tags.  The body is detected and rendered 
accordingly.  Yahoo and others wrap their outgoing user mail with <div> 
advertisment windows.  I recall back in the late eighties how this 
created a STRIPPING WAR among mailers.  One added, One Stripped! The 
irony is is that the stripper only worked when you paid the vendor :-)

Fortunately, the email clients are getting better with such things, such 
as blocking image webbots by default. TBIRD controls this very nicely, 
as well as controlling phishing HTML links that have display domain and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pete Resnick | 5 Nov 2007 12:20

Re: Non destructive folding/unfolding (ie, no insertion of whitespace in unfolding)


On 11/1/07 at 12:35 PM +1100, Mikel Lindsaar wrote:

>One situation I have is where a X-header field and Reply-To field 
>has a single piece of text that is longer than the 78 octet limit, 
>but has no white space break.
>
>For example:
>
>Reply-To: 
><1234-1234-1234-1234-1234-1234-1234-1234-1234 <at> me-some-host-over-here.org>
>
>The library currently folds this line as:
>
>Reply-To:CRLF
>LWSP<1234-1234-1234-1234...blah-with-no-further-fold

That's OK.

>Now, I have two questions.
>
>1) I believe that putting the CRLF immediately after the : in the 
>header field name is in violation of 2822 specifically that the 
>header line should contain the name, a colon, the field and 
>terminated by a CRLF.  Would this be a correct interpretation?

No. Following every colon after the header field is "[CFWS]". It's OK 
to fold there.

>2) Irregardless of (1), what is the correct handling of a piece of
(Continue reading)

Permalink | Reply | 0 comments |
headers
SM | 5 Nov 2007 23:48

Re: New Disposition type: Inline Subordinate


Hi Qian,
At 23:09 04-11-2007, Qian Sun wrote:
>RFC 2183 defines two basic disposition types, i.e. "inline" and "attachment".
>But sometimes we need a more elaborate presentation than the 
>existing disposition
>types. For example, the current advertisement way in Email or Webpage is very
>"evil", sometimes it is difficult for the users to distinguish the 
>real contents
>from advertisement, and this is disgusting or confusing. Nowadays many email
>service providers insert advertisements in the user's email. The inserted
>advertisements normally are displayed at the end of the email, but 
>sometimes the
>boundary between advertisements and other real contents is not clear. So that
>the recipient may be misunderstanding, the advertisements might be 
>regarded as
>the real contents the sender writes.

If the sender does not want his/her message to be misunderstood 
because of advertisements, he/she could use a service which doesn't 
insert such content.

>However, advertisement is absolutely necessary for the development 
>of internet
>and mobile applications. In order not to interfere with users much, 
>the technology

I doubt that advertisement is absolutely necessary for the 
development of the Internet.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane