headers
Martin Duerst | 1 Nov 05:51
Picon
Favicon

provisional registration: Archived-At for email


This is a proposal for a provisional registration of the Archived-At
header field for email, sent here for the two-week review according
to RFC 3864.

    Header field name:
       Archived-At

    Applicable protocol:
       mail (RFC 2822)

    Status:
       provisional

    Author/Change controller:
       Martin Duerst, W3C/Keio University, duerst <at> w3.org

    Specification document(s):
       http://www.w3.org/2004/10/archived-at/draft-duerst-archived-at-02.txt

    Related information:
       It is planned to advance this registration to
       permanent by advancing the internet-draft to an RFC.
       The syntax of the header field may change.

Regards,    Martin.
Permalink | Reply | 0 comments |
headers
Graham Klyne | 1 Nov 11:14

Re: the gap regarding Archived-At


At 14:27 30/10/04 -0400, Bruce Lilly wrote:
> > Yes. One issue is that if there are a lot of comments fields,
> > the user will have difficulties to choose the right one.
>
>The same could be said of archived-at and x-archived-at.

I gave some further thought to the issue of Achived-At vs a general comment 
field and, based on my experience, come to the view:

- [X-]Archived-At as currently used does not specifically need to be a 
structured field in the RFC822 sense, but

- it is useful to use a separate header field name because this can be used 
by an MUA as a basis for determining whether or not to display the field 
value.  My MUA, which certainly has no knowledge of this specific header 
field, still allows me to do this much.  Using a generic comment field 
would obviate this benefit.

In saying this, I don't deny Keith's point about MUAs also being able to 
use the field -- I'm just responding further the earlier question about 
utility of the field as currently proposed.

#g
--

BTW, Bruce, your use of reply-to header fields is confusing me -- you 
nearly didn't get a directly addressed copy of this message.  Did you 
really mean this?:
[[
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruce Lilly | 1 Nov 14:19
Picon

Re: a header authentication scheme


On Sun October 31 2004 01:54, Laird Breyer wrote:

> > Given a message with a valid Received field; it's trivial; simply
> > construct a Processed field accordingly and insert it where
> > desired, eliding any preexisting "processed" field that corresponds
> > to the Received field.  W/o any Received field; forge one and
> > insert it and a corresponding "processed" field where desired.
> 
> I'm afraid none of this is yet convincing as a successful attack. 
> 
> You must be able to forge the Processed field before the message
> contains the pertinent Received field, otherwise you're not actually
> forging anything of value. In fact, quoting existing Received fields
> is legal, and marks your location correctly. 

You have missed the points; at any point a party can
a) s/result-tag="spam"/result-tag="ham"/
b) insert a Received field, then insert a "processed" field referring
    to that Received field, with any desired "processed" field content
N.B. neither tactic would be effective if MIME security multiparts
were used.

> If you forge an appropriate Received field as well, you still have no
> control over the Received fields added by the subsequent receiving
> systems

Again, you have missed a crucial point; there may be no
"subsequent receiving systems", and even if there are
there might be no added Received fields.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Arnt Gulbrandsen | 1 Nov 16:45
Picon
Favicon
Gravatar

Re: a header authentication scheme


Claus Assmann writes:
> On Fri, Oct 22, 2004, Arnt Gulbrandsen wrote:
>>  Step 1. I'd send five messages to nosuchuser <at> do.ma.in and wait for 
>>  the bounces. For each of them, I'd compute the delay from my 
>>  sending time (using my clock) to the receiving MTA's receive time. 
>>  Next, I'd average the five values.
>
> Where do you get the time of the server? Many MTAs don't accept mail 
> for unknown recipients, so it's your MTA that generates the bounce.

I don't suppose it matters, since even in the best case, there's very 
little entropy in the time-date value, so id has to be better.

But since you ask: Usually I can get time and timezone from the SMTP 
server's banner. I can also often guess based on its geographical 
location (which I can guess from IP address). This won't get me the 
delay, but if all I want is to spam n million recipients, assuming 
[1,15> is pretty good. Few MTAs are faster, few are slower.

Arnt
Permalink | Reply | 0 comments |
headers
Bruce Lilly | 1 Nov 16:47
Picon

Use of Reply-To


On Mon November 1 2004 05:14, Graham Klyne wrote:

> BTW, Bruce, your use of reply-to header fields is confusing me -- you 
> nearly didn't get a directly addressed copy of this message.  Did you 
> really mean this?:
> [[
> From: Bruce Lilly <blilly <at> erols.com>
> Reply-To: Martin Dürst <duerst <at> w3.org>,
>     ietf-822 <ietf-822 <at> imc.org>
> ]]

Yes, that's intentional (i am subscribed to the list; therefore
don't need a separate copy, and discussion should probably
go to the list; Martin had requested copies of the discussion
of Archived-At as he is not subscribed to ietf-822) -- the use
of Reply-To for lists is documented in RFC 822 and its
predecessors, and has been recently discussed on ietf-822.
[The Reply-To field had better have RFC 2047 encoding
rather than raw 8-bit characters, though]
Permalink | Reply | 0 comments |
headers
Bruce Lilly | 1 Nov 16:56
Picon

Re: the gap regarding Archived-At


An update on MUA/browser capabilities:

Kmail does seem to be able to handle IMAP URIs including those
that specify a particular message; via the File -> Open -> Network
dialog, a URI can be typed or pasted, and Kmail will open the
specified message.   I suspect that it wouldn't be terribly
difficult to modify Kmail to recognize IMAP URIs and open any
specified message in a new window, but as of now that capability
doesn't exist.

I can't find any similar capability in Mozilla, Evolution, or Sylpheed.
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 1 Nov 17:44
Picon
Picon

Re: Angle brackets surrounding Content-ID


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

>On Fri October 22 2004 07:45, Charles Lindsey wrote:

>> A file in mbox format cannot contain a news article.

>The newsreader rn and its derivatives and a number of other
>newsreaders save news articles in that format, and can read
>messages (which might be "news" messages or "mail" messages)
>in that format.

Then Pray Tell what it puts in the "^From " line (that usually contains
the envelope From address plus a time stamp).

Any why is rn saving articles in the first place (or is that for some
archiving facility)? Last time I used rn, it worked online, acquiring
articles on demand from a server, either directly or via NNTP.

>> There are plenty of hooks within IMAP to enable an implementor to
>> distinguish Email from Netnews.

>No.

>> For example, it is customary to store news 
>> articles in folders within a "#news" hierarchy.

>> Messages also carry flags 
>> with them which can be used to distinguish various classes of message.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Lindsey | 1 Nov 18:09
Picon
Picon

Re: Angle brackets surrounding Content-ID


In <E4C18AF6-2530-11D9-A198-000A95B17A80 <at> gmx.de> Martin Trautmann <traut <at> gmx.de> writes:

>On 2004-Oct-22, at 13:45, Charles Lindsey wrote:

>> A file in mbox format cannot contain a news article. If the file is in
>> some "mbox-like" format, then it is up to the implementor of the 
>> format to
>> make provision.

>Why can't it be mbox files? There's lots of postings that I archive 
>locally. It looks to me like a news article in mbox format. What's the 
>difference?

An mbox file contains '^From ' lines that contain the envelope From
address, plus a time stamp. Since news articles don't have any envelope,
they cannot be stored in pure mbox files.

I have no doubt that files in a similar style to mbox can be used to
hold news articles (the mbox format is noted for lack of any rigid
definition anywhere), but in that case I would expect the news articles
for have a '^From ' line formatted in some different way that could be
used to distinguish them from any email messages that might have got mixed
in.

>On the other hand Newsgroups would qualify as a good news indicator - 
>while the message may have been Cc-ed and thus is in fact an email.

Exactly.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Charles Lindsey | 1 Nov 17:52
Picon
Picon

Re: Angle brackets surrounding Content-ID


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

>On Fri October 22 2004 07:54, Charles Lindsey wrote:

>> But once the domain name has been copied into the id-right

>There is no "copying" involved; RFC 2822 recommends that
>id-right *be* a domain name, full stop.

>> (whether in 
>> upper or lower case) it is no longer a domain name for any protocol
>> purpose.

>Says who? Certainly not RFC 2822.

>>  its only purpose is to be compared for identity
>> with other <id-right>s for the removal of duplicates, for threading, etc.

>No, Charles; the original message in this discussion mentioned
>content identifiers, which explicitly use RFC 822 syntax. There
>was no mention of "removal of duplicates" or "threading" or
>anything vaguely similar.

This thread has developed a long way since its original Subject was set.

You agreed that RFC 2822 had (intentionally or otherwise) changed the
semantics of <msg-id>s with regard to the case-sensitivity of whatever
came after the '@'. I said that I considered the change to be an
improvement, and you have been harranguing me ever since for being so
(Continue reading)

Permalink | Reply | 7 comments |
headers
Keith Moore | 1 Nov 18:41
Picon

Re: Angle brackets surrounding Content-ID


> An mbox file contains '^From ' lines that contain the envelope From
> address, plus a time stamp. 

there's no standard specification for mbox files.  and from the earliest
days that mbox files were used it was not unusual for the "From_" line
to contain a meaningless username like uucp.

Keith
Permalink | Reply | 0 comments |

Gmane