[Remops] Description of an 'Anonymous Internet Message Format'

[Christian Danner]

Hi Michael,

I hope it's o.k. to reply via the remops mailing list.

On Tue, 4 Jul 2006 20:45:55 +0200, you wrote:

>On Mon, 03 Jul 2006 12:10:53 +0200, in local.lists.remops you wrote:
>
>> on the occasion of my findings concerning specific header
>> patterns resp. fingerprints provided by message envelopes in
>> general, and the partially very emotional debate on that topic
>> at a.p.a-s., I developed a paper with recommendations on how to
>> make anon messages more uniform, supported by Zax and Thomas J.
>> Boschloo, and reinsured about the validity of that strategy by
>> Richard Christman, the author of Quicksilver. I'm truly pleased
>> by their support and have to thank them a lot for those efforts.
>
>Did you post this on apas? Did not find it :(

The initial posting was 
  Message-ID: <UPVH5RCN38888.5371643519 at anonymous.poster>
I published a list of client specific patterns with
  Message-ID: <QUUQFQCS38893.4921180556 at anonymous.poster>
You find an analysis of a randomly chosen thread in
  Message-ID: <8TROXKCT38894.7142824074 at anonymous.poster>

>> 3.2.3. Header field names
>> 
>> The names of header fields included in the list in paragraph
>> 3.2.1 have to be written exactly as shown. With header fields,

Correction: ... 3.2.2 have ...

>> which are not included in the list, the first letter of the
>> name, as well as the first letter directly following any non
>> letter character, has to be capitalized. All other letters have
>> to be written in lower case.
>
>I'd clarify again that MIME-Version and Message-ID are the only exceptions
>from this rule (since they are written differently in paragraph 3.2.1).

Isn't it clear enough with the first sentence expressing that the
names in the list 'have to be written _exactly_ as shown', and
'Message-ID' being one of the examples.

>> 3.2.4. Header field arguments
>> 
>> 3.2.4.1 Common recommendations
>> 
>> Date resp. time parameters have to be converted to their UTC
>> representation, like
>> 
>>   Mon, 28 Jun 2004 09:39:02 +0000 (UTC)
>
>- include day-of-week? (I'd say yes)
>- leading zero in day (if one-digit)? (I'd say no)

ACK (according to RFC 2822).

>- timezone comment? (I'd say no, although it is present above)

ACK.

>- strip all other comments!

The example now reads

   Mon, 8 Jun 2004 09:39:02 +0000

>> 3.2.4.3 Address lists
>> 
>> Double quotes surrounding the name within an address argument as
>> well as unnecessary LESS THAN and GREATER THAN characters around
>> addresses should be removed, if allowed by the RFCs. 
>
>unnecessary quoted-string in local part should of course be avoided, too
>(It should be avoided according to the RFC, but better mention it again).
>
>i. e. not "example"@example.com but example at example.com

Done: ... surrounding the name resp. the local-part within ...

>> The domain
>> name part of the address has to be written in lower cases, the
>> potentially case-sensitive mailbox local-part [RFC 2821 2.4] has
>> to stay untouched (should the occasion arise, overriding the
>> first-character-in-upper-case rule), the words have to be
>> separated by no more than a single SPACE. The single items of an
>> address list should be separated by a COMMA followed by one
>> SPACE character.
>
>mailbox groups (like 
>"From: niceguys: foo at example, bar at example; badguys: baz at example;") SHOULD
>be avoided (and broken up if present), since most email clients cannot
>produce them. The empty mailbox group (undisclosed-recipients:;) is an
>exception, of course.

Good point. I added:

Mailbox groups should be desintegrated into their single components,
unless they themselves are necessary for a correct delivery or
represent information relevant for the recipient.

>> Also according to the rules would be
>> 
>>   To: John.Doe at machine.example, paul.pan at 98.87.219.55, Pete Pan
>> <Pete.Pan at 98.87.219.55>, harvey at 209.214.12.258
>
>Erm, IP addresses SHOULD be written in square brackets according to
>RFC2822. Better keep that.
>
>harvey@[209.214.12.258]

You're right. RFC 2821 states, that address-literals have to be
surrounded by square brackets. Corrected:

  To: John.Doe at machine.example, paul.pan@[98.87.219.55], Pete Pan
<Pete.Pan@[98.87.219.55]>, harvey@[209.214.12.258]


>> Leading and trailing spaces have to be removed. One single SPACE
>> character has to separate the header argument from the header
>> field name.
>
>> 4. MIME boundary character sequence
>
>Any suggestions about charsets to choose for MIME headers or how to use
>encoded-words in headers? User agents are quite creative in that respect.
>
>Of course, using us-ascii (and not encoding any headers) ist most
>anonymous, so always use us-ascii if only 7-bit characters are present, and
>use the preferred MIME name if another charset is required. Do not declare
>us-ascii/8bit, but us-ascii/7bit. If not needed (i.e. text/plain ASCII), do
>not use MIME headers at all.

I inserted the following universally valid statement into the 'Body
Section':


3.1.2. Character sets

In order to avoid revealing information about her/his location, the
originator of a message is urged to select the most restrictive
character set possible. If that isn't 7bit ASCII, which doesn't have
to be declared within a plain text message, the referred character set
should be defined within a MIME 'Content-Type' field.


Or better to simply add that information to 3.1.1.?


Kind regards

Christian Danner

OmniMix .. protect your privacy
http://www.danner-net.de/om.htm