headers
Bruce Lilly | 1 Feb 2005 18:00
Picon

Re: Mandatory From field, anonymity, and hacks


On Mon January 31 2005 16:35, Charles Lindsey wrote:
> 
> In <200501292355.38762.blilly <at> erols.com> Bruce Lilly <blilly <at> erols.com> writes:
> 
> >On Sat January 29 2005 04:23, Hector Santos wrote:

> >No, MTAs are not supposed to alter the message content except
> >to add trace fields (Received, Return-Path).  MSAs are permitted
> >to make specific modifications.
> 
> Have you ever tried sending a message with no Message-ID through sendmail?

Sendmail acts as an MSA; what's your point (if you have one)?

> >> Technically, a message needs no headers at all.
> 
> >No, a message must have a message header, and that message
> >header must have at least one header field.  See RFC 822
> >section 4.1, RFC 2822 sections 3.5 & 3.6, and RFC 2046
> >section 5.2.1.
> 
> I see nothing in those places that requires "at least one header field"
> except for the provision that certain header fields are not optional, and
> hence must be present.

Duh.

> But since you seem prepared to reduce the number of 
> required header fields, then you are in no position to object when Hector
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bruce Lilly | 1 Feb 2005 18:09
Picon

Re: Mandatory From field, anonymity, and hacks


On Mon January 31 2005 16:27, Charles Lindsey wrote:
> 
> In <200501281744.43383.blilly <at> erols.com> Bruce Lilly <blilly <at> erols.com> writes:
> 
> >On Fri January 28 2005 11:07, Charles Lindsey wrote:

> >> 1. Is it really necessary to modify RFC 822 and well as RFC 2822?
> 
> >Yes.
> 
> Why?

RFC 2026.

> As clearly stated in the "Scope" section on RFC 2822, the "Internet
> Message Format" applies first and foremost to "electronic mail".

That is not what RFC 2822 says; it speaks of a "framework", using
language that has remained unchanged from RFC 822, RFC 733, etc.,
several of which predate adoption of the message format by other
RFCs (e.g. 850).

> >That is certainly possible via a number of existing mechanisms
> >(From field with an "effective and useful for replies" [RFC 2821
> >section 3.8.4] mailbox, a standard Comments or Organization (for
> >Usenet specifically) field w/o a  mailbox, or indication in the
> >body of the message), or an extension field which is not an
> >address field could be defined.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hector Santos | 1 Feb 2005 18:36
Favicon

Re: Mandatory From field, anonymity, and hacks


----- Original Message -----
From: "Bruce Lilly" <blilly <at> erols.com>
To: "ietf-822" <ietf-822 <at> imc.org>
Cc: "Charles Lindsey" <chl <at> clerew.man.ac.uk>
Sent: Tuesday, February 01, 2005 12:00 PM
Subject: Re: Mandatory From field, anonymity, and hacks

> He did not "suggest[...] the possibility"; he flatly (and incorrectly)
> claimed that none were needed.  But, I suppose this is just another
> instance of the (in)famous Lindsey reading comprehension problem
> rearing its head.

Bruce,  you incorrectly read the statements I made as well so lightning up.
You made a proposal. Be ready for comments

There many different types of software in the loop and I don't think you
have taken into account how they will behave when one or more of the RFC
headers (depending on which one you are based on) is not present.

The fact is most if not all major mail servers do not require a RFC header
to be present in the DATA block.  This is NOT to suggest they are not
required.  The MSA will add an RFC.  The question I raised is what is what
is the expected  behavior or what is deemed a valid RFC header.

I don't wish to go thru the different and conflictive requirements as they
evolved in the last two decades. But you now are proposing a new (relaxed)
requirement, that wasn't there in the first place.

In that vain, your proposals is not harmful.  But again, the difference is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 2 Feb 2005 12:03
Picon
Picon

Re: Mandatory From field, anonymity, and hacks


In <200502011200.33116.blilly <at> erols.com> Bruce Lilly <blilly <at> erols.com> writes:

>On Mon January 31 2005 16:35, Charles Lindsey wrote:
>> 
>> Have you ever tried sending a message with no Message-ID through sendmail?

>Sendmail acts as an MSA; what's your point (if you have one)?

Sendmail is widely used as an MTA, and has been since long before separate
MSAs were thought of.

May I suggest that you submit a message to this list containing no From
field and no Message-ID field, and let us see exactly what ends up in
various people's mailboxes.

>> False premise, leading to false conclusion.

>Excuse me?

You are excused.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 2 Feb 2005 12:12
Picon
Picon

Re: Mandatory From field, anonymity, and hacks


In <200502011209.47798.blilly <at> erols.com> Bruce Lilly <blilly <at> erols.com> writes:

>On Mon January 31 2005 16:27, Charles Lindsey wrote:

>RFC 2821 is part of the core Internet protocol suite, and
>its section 3.8.4 requirements are indeed serious.
> 
>> But can you
>> point to some realistic scenario (or, better, some actual MUA) in which
>> something might actually break if such a modified header were to arrive at
>> an agent?

>See RFC 2821 section 3.8.4.

That section of RFC 2821 is concerned only with gatewaying. What we are
discussing is ordinary mail produced by ordinary MUAs and remaining in the
SMTP environment until final delivery. Please answer the question with
respect to that environment.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Permalink | Reply | 0 comments |
headers
Martin Duerst | 14 Feb 2005 13:55
Picon
Favicon

Updating the mailto URI scheme for better I18N


Dear Email Experts,

I have just submitted draft-duerst-mailto-bis-00.txt to the Internet
Drafts Editor. Here's the abstract:

    This document defines the format of Uniform Resource Identifiers
    (URI) for designating electronic mail addresses.  The syntax of
    'mailto' URIs from [RFC2368] is extended to be compatible with IRIs
    ([RFC3987]) for better internationalization.

You can find a full copy at
http://lists.w3.org/Archives/Public/uri/2005Feb/0013.html.

Comments are welcome. The list for discussing URI schemes, including
this one, is uri <at> w3.org (subscribing by sending a mail with subject
'subscribe' to uri-request <at> w3.org).

Regards,    Martin.

P.S.: Just in case, this already works in at least one browser (Opera)
Permalink | Reply | 0 comments |
headers
Martin Duerst | 18 Feb 2005 07:23
Picon
Favicon

Re: the gap regarding Archived-At


Hello Keith,

I'm just working now on another version of my draft.
I'll address your points below.

At 05:38 04/10/29, Keith Moore wrote:
 >
 >okay, I find myself coming to some somewhat uncomfortable conclusions:
 >
 >1. There really are significant differences between
 >    a) how email clients would use archived-at,
 >    b) how humans would use it to cut-and-paste into HTML, and
 >    c) how web browsers would use it.
 >
 >    These differences are significant enough that I'm wondering if we
 >    really do want separate archived-at fields for web use and email use,
 >    or tags on the archived-at field that indicates whether the message
 >    is in original format and/or if other messages in the same collection
 >    can also be accessed.

I think a single header can go a long way. If it turns out
that it's not enough, we (you?) can always create another one.

 >2. For archived-at to be useful by email clients generally requires
 >    one or two of the following, in addition to the obvious client
 >    support for the protocol and server support for the message format:
 >
 >    - mail archives that support IMAP access (or possibly NNTP)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Duerst | 18 Feb 2005 08:09
Picon
Favicon

Re: New Internet Draft: draft-duerst-archived-at-00.txt


At 23:05 04/10/26, Bruce Lilly wrote:
 >On Mon October 25 2004 00:42, Martin Duerst wrote:
 >>
 >> I tried to adapt the syntax below to the changes I made.
 >> The problem with URIs/URI references is solved by RFC2396bis.
 >> I don't think [FWS] and *WSP are needed, the syntax given for
 >> similar headers in RFC 2822 doesn't explicitly mention these,
 >> either.
 >>
 >> Regards,    Martin.
 >
 >Actually, RFC 2822 does include [FWS] etc., but they are part of
 >the lower-level construct specifications, so aren't readily apparent
 >when looking only at the field definitions; they do become visible
 >if one expands "domain", "dot-atom", "date-time", etc.  That
 >does not apply to the constructs used in the proposed field, since
 >the ABNF for those constructs does not explicitly include [FWS]
 >etc.  Incidentally, the successor to RFC 2822 may change in that
 >respect; a proposed revised grammar has been discussed on the
 >ietf-822 list.
 >
 >Given the draft ABNF
 >
 >       archived-at = "Archived-At:" '<' URI '>' CRLF ; URI not empty
 >
 >and the example implicit in the text
 >
 >    As an example, the URI
 >    "http://www.w3.org/mid/0I5U00G08DFGCR <at> mailsj-v1.corp.adobe.com",
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Duerst | 18 Feb 2005 08:48
Picon
Favicon

Re: the gap regarding Archived-At


Hello Bruce,

Please see below.

At 02:05 04/10/31, Bruce Lilly wrote:
 >On Thu October 28 2004 19:54, Keith Moore wrote:
 >
 >> >   A message may contain an arbitrary
 >> >    number of Comments fields.  However, it does not solve the
 >> >    problem of the incompatibility with RFC 2046 message/partial.
 >>
 >> could you explain that supposed incompatibility again?
 >
 >Fragmentation/reassembly is defined in RFC 2046 section 5.2.2 and
 >its subsections.  The issue was discussed in some detail on the ietf-822
 >mailing list in June 2003 and again very briefly regarding specific
 >field (References, In-Reply-To, and Resent-Message-ID) in September
 >2004.  Briefly, the fragmentation/reassembly process distributes
 >original (unfragmented) message header fields between the header
 >of the first fragment and the header of the encapsulated message
 >(which appears within the message/partial wrapper in the first
 >fragment; reassembly combines fields from those two headers to
 >produce a facsimile of the original message from fragment messages.
 >RFC 2046 lists specific fields which are taken from the encapsulated
 >header -- MIME Content- fields, Subject, Message-ID, Encrypted,
 >and MIME-version -- that list is amended by RFCs 2298/3798 to
 >include Disposition-Notification-To, Disposition-Notification-Options,
 >and Original-Recipient; these fields are the ones which pertain
 >specifically  to the unfragmented original message as opposed to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Duerst | 18 Feb 2005 08:24
Picon
Favicon

Re: New Internet Draft: draft-duerst-archived-at-00.txt


At 23:22 04/10/26, Bruce Lilly wrote:
 >On Sun October 24 2004 22:46, Martin Duerst wrote:
 >
 >> I have added a very clear sentence saying that the field MUST only be
 >> created if the message is actually being made available at the URI given
 >> in the header field. Do you think that this should say anything more?
 >
 >Since (unlike Reply-To and Sender) the proposed field plays no
 >role in message protocols, but is simply a way of conveying
 >additional information, "MUST" may be too strong.

Good point, added a reference to RFC 2119 and changed "MUST"
to "SHOULD".

Regards,    Martin.

 >RFC 2119
 >specifically states that it must not be used except to ensure
 >interoperation or to avoid network damage (retransmissions,
 >etc.).  Incidentally, it is customary to include some boilerplate
 >text referring to the RFC 2119-defined terms and to include
 >RFC 2119 as a normative reference when making use of those
 >terms.  Of course if you intentionally did not reference RFC
 >2119 because you intend your use of "MUST", "MUST NOT",
 >"SHOULD", "SHOULD NOT" and "MAY" to have different
 >meanings than the ones ascribed by RFC 2119, that raises
 >the question of precisely what meaning *is* intended.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane