Subject: Re: drums2?
From: "Charles Lindsey" <[email-masked]>
To: [email-masked]
Date: Fri, 23 Aug 2002 14:27:58 GMT
Newsgroups: local.mime
List-Id: <ietf-822.imc.org>

In <[email-masked]> Chris Newman <[email-masked]> writes:

>No.  Although in 2822 we deprecated the most problematic constructs 
>(particularly the ones permitted in 822 but not in 821).  It's risky to 
>retroactively declare previously compliant constructs to be incompliant, 
>even if we didn't know of any specific implementations.  So this is a case 
>where what's legal by the standard is a superset including constructs which 
>are not a good idea to use.

>If you're curious, here's a writeup I did of special characters in email 
>addresses:

Yes that looks like a good survey. It contains all that is really
necessary for those who invent mailbox names for their own servers. Life
would be much simpler if we could tell them all the excluded cases were to
be considered obsolete (I.e. MUST accept, but SHOULD NOT use for new
names).

And it would also be useful to be deciding what escape character you are going
to use in those punycoded local-parts.

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:1828
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: 2822 section 3.6.4 (Message-ID generation)
Date: Fri, 23 Aug 2002 14:23:39 GMT
Lines: 44
Sender: [email-masked]

In <[email-masked]> Arnt Gulbrandsen <[email-masked]> writes:

>Hi,

>2822 suggests (section 3.6.4, page 25) using IP address, system time and 
>something like a unix pid for message-ids. I'm not entirely happy with 
>that advice: It says the msg-id MUST be unique, but goes on to suggest 
>an algorithm that does not generate unique results any more.

Interestingly, we are having that same debate on Usefor at the moment (for
at least the second time this year).

Currently, Usefor says the same. The msg-id MUST be unique. Reason?
Because RFC 2822 says so, and we didn't want to be different, even though
what is demanded is technically impossible.

>The observation that "no two hosts use the same domain name or IP 
>address at the same time" is regrettably not true. Addresses like 
>192.168.100.100 are in use by countless machines, and that two of them 
>might send mail at the same time, from the same "pid", isn't 
>far-fetched. Granted, it's not something that'll happen every five 
>minutes, but the net is big and keeps growing.

But actually, that is a good reason for that MUST. It says that people who
own multiple servers with the same domain need to be aware that the
suggested algorithm is insufficient in their case (though it is fine for
most people). The "MUST" says it is _their_ problem and _their_
responsibility to fix it.

Usefor got as far as writing a draft for an informational RFC on the
subject. We may well get it out and dust it down once our main document is
out of the way.

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:1827
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: drums2?
Date: Fri, 23 Aug 2002 14:15:17 GMT
Lines: 18
Sender: [email-masked]

In <[email-masked]> Arnt Gulbrandsen <[email-masked]> writes:

>I have a suggestion for the latter one: Every email address in use may 
>be presumed to receive spam, so just buy a MILLIONS CD and see what's 
>on it.

You think the email addresses on a MILLIONS CD are all "in use"? :-) .

-- 
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: [email-masked]      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

Date: Thu, 22 Aug 2002 15:48:51 -0700 (PDT)
Subject: Re: drums2?
From: "WJCarpenter" <[email-masked]>
To: <[email-masked]>
Importance: Normal
Sender: [email-masked]

> By the way, some spammers appear to be becoming aware of subaddresses,
> stripping them off before sending their email. :-(

This amount of clue is partly offset by the spammers who send email to
various old message-IDs found in mailing list archives and the like.

-- 
[email-masked] (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3

Date: Thu, 22 Aug 2002 15:53:03 -0400
From: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: drums2?
Sender: [email-masked]

Me too. Fortunately, my mail provider lets me use either "=" or "+" as a 
subaddress character. It's when BOTH of those don't work that I get 
really upset.

I've successfully gotten some web sites to fix their ages so that they 
handle the + addresses okay.

By the way, some spammers appear to be becoming aware of subaddresses, 
stripping them off before sending their email. :-(

	Tony Hansen
	[email-masked]

Keith Moore wrote:
> for what it's worth, I've run into several web forms that cannot deal
> with addresses containing +  either because they forbid it explicitly
> (either in javascript or on the server side) or because they don't 
> translate + into %2B when encoding it in a URL that gets sent back to the
> client.

From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: 2822 section 3.6.4 (Message-ID generation)
Date: Fri, 23 Aug 2002 02:05:12 +0530
Sender: [email-masked]

Hi,

2822 suggests (section 3.6.4, page 25) using IP address, system time and 
something like a unix pid for message-ids. I'm not entirely happy with 
that advice: It says the msg-id MUST be unique, but goes on to suggest 
an algorithm that does not generate unique results any more.

The observation that "no two hosts use the same domain name or IP 
address at the same time" is regrettably not true. Addresses like 
192.168.100.100 are in use by countless machines, and that two of them 
might send mail at the same time, from the same "pid", isn't 
far-fetched. Granted, it's not something that'll happen every five 
minutes, but the net is big and keeps growing.

The same applies to localhost.localdomain and OS-default hostnames like 
good old darkstar.frop.org.

Ideally, a revised document should suggest using a secure hash of the 
message text on the LHS and the ip or domain on the RHS. At least it 
should warn of the problems caused by 192.168/16 and its friends.

(I hope this message doesn't reopen an old DRUMS wound.)

--Arnt

From: Arnt Gulbrandsen <[email-masked]>
To: Charles Lindsey <[email-masked]>
Subject: Re: drums2?
Cc: [email-masked]
Date: Thu, 22 Aug 2002 23:47:21 +0530
Sender: [email-masked]

If you want to argue that some user-agents should be broken and some 
e-mail adress made invalid, it's your job to find out which 
user-agents/addresses are affected.

I have a suggestion for the latter one: Every email address in use may 
be presumed to receive spam, so just buy a MILLIONS CD and see what's 
on it.

--Arnt (using an affected user-agent)

From: Keith Moore <[email-masked]>
To: Chris Newman <[email-masked]>
cc: [email-masked]
Subject: Re: drums2? 
Date: Thu, 22 Aug 2002 13:54:58 -0400
Sender: [email-masked]

for what it's worth, I've run into several web forms that cannot deal
with addresses containing +  either because they forbid it explicitly
(either in javascript or on the server side) or because they don't 
translate + into %2B when encoding it in a URL that gets sent back to the
client.

Keith

Date: Thu, 22 Aug 2002 10:17:17 -0700
From: Chris Newman <[email-masked]>
Subject: Re: drums2?
To: Charles Lindsey <[email-masked]>, [email-masked]
Sender: [email-masked]

begin  quotation by Charles Lindsey on 2002/8/22 15:45 +0000:
> In <[email-masked]> Keith Moore
> <[email-masked]> writes:
>> 2. invalidate a huge number of existing user agents by creating a new
>> syntax for local parts that is incompatible with the old one.
>
> Do we actually know what part of the huge range of possibilities within
> the present syntax of local-part are actually in regular use in existing
> user agents or in actual email addresses?

No.  Although in 2822 we deprecated the most problematic constructs 
(particularly the ones permitted in 822 but not in 821).  It's risky to 
retroactively declare previously compliant constructs to be incompliant, 
even if we didn't know of any specific implementations.  So this is a case 
where what's legal by the standard is a superset including constructs which 
are not a good idea to use.

If you're curious, here's a writeup I did of special characters in email 
addresses:

Special Characters in Email Addresses

Summary: This discusses why it's safest to stick to alphanumerics when
creating email addresses on a system.  A set of five "conditionally safe"
characters (_.-=+) are reasonable to use in the middle of an address on
most systems, although if the system's primary subaddress delimiter is one
of these, it should be forbidden.

RFC 822 permits all ASCII characters in email local-parts. RFC 2822
permits all but NUL (ASCII 0x00).  But just because a character is
permitted doesn't mean it will interoperate in practice.  The morass of
escape characters, quoting schemes and encoding schemes which impact
various parts of real-world email systems make most US-ASCII punctuation
characters problematic in practice.

Always Safe Characters: a-z A-Z 0-9
  US-ASCII alphanumerics are always safe in email address local-parts.
  Systems are permitted to be case-sensitive, but most are case-insensitive
  in practice.

Conditionally Safe Characters (avoid at beginning of local part): _.-=+
  '_' is almost always safe, but I've seen it have special meaning at the
      beginning of a local part.  Many sites use a First_Last@domain
      naming scheme so it's likely to work.
  '.' is safe between words, but requires quoting at beginning, end or if
      doubled.  Many sites use a First.Last@domain naming scheme, so it's
      likely to work.  The CMU Cyrus server uses it as a mailbox hierarchy
      delimiter, so it's forbidden in user names on that system.
  '-' is safe on systems which don't use it as a subaddress delimiter.  On
      systems which do use it as a subaddress delimiter (qmail), it'd be
      safer not to use it in user names.  Many sites use it in non-human
      mailbox names (e.g. mailing lists).  Primary subaddress use is for
      mailing list "-request" and "-owner" suffixes (RFC 2142).
  '=' is safe on most systems which don't use it as a subaddress delimiter.
      But it is a URL reserved character (see below).
  '+' is safe on most systems which don't use it as a subaddress delimiter.
      It is the primary subaddress delimiter for iPlanet Messaging Server,
      SIMS, PMDF and CMU Cyrus (among others).  It shouldn't be used when
      creating an email address for a user on these systems, but should be
      permitted in address lists and general-purpose email address entry
      forms.  Note that it is a URL reserved character and I've seen it
      cause problems on some ill-designed web forms with an email address
      entry field.  These web forms should be fixed.

Confusing: ~`
  When email addresses are written down, these characters are likely to
  be confused with other characters (~ with - and ` with ').  Thus they
  are best avoided for human factors reasons.  In addition, not everyone
  is familiar with the word 'tilde'.  While '+' and 't' can also
  be confused, I haven't had any problems in practice since I started
  accentuating the horizontal line and reducing the vertical line when
  writing '+'.

Path Delimiter: /
  May be safe as long as it is not the first character (it sometimes
  indicates direct-file delivery as a leading character).  Many Unix
  systems forbid it in user mailbox names since the names are stored
  unquoted in the filesystem and '/' is the delimiter.  Sometimes used
  as a subaddress delimiter (e.g. RFC 2846), but not by iMS.

Shell Metacharacters: $&*?!~^()[]{}"'\|
  Internet mail is often stored in Unix directories whose name is the
  unquoted user name.  Thus characters which have special meanings to Unix
  shells are discouraged because they raise security issues on some
  Unix-based mail systems.  '*', '?', and '|' are most dangerous, while
  some of the others ('~') are not a big deal when not used at the
  beginning of a user name.

URL Reserved Characters (RFC 2396): ;/?:@&=+$,
  These have special syntactic meaning in various portions of generic URL
  syntax and thus some web systems will choose to encode them when they're
  used for something other than their URL-specific meaning.  Thus they
  might introduce errors.

URL Excluded (RFC 2396): {}|\^[]`<>#%" Controls (0x00-0x1F, 0x7F), SPACE 
(0x20)
  The standard requires these to be encoded in URLs, and many webmail
  services or email address entry forms are likely to make mistakes when
  its necessary to encode or decode these characters.

Email quoting required (RFC 821/822): ()<>[]@,:;"\
  Also Controls (ASCII 0x00-1F, 0x7F) and SPACE (ASCII 0x20)
  These all require quoted local-parts which some systems don't
  implement according to the standards (e.g. Exchange), so their use
  is discouraged.  @, " and \ are particularly problematic.

Eight-bit (RFC 821, RFC 2821):
  Characters with the high bit set are not permitted by current email
  standards. In the future, standards may be changed to permit _only_
  UTF-8 when negotiated, likely with a downconversion to a 7-bit
  encoding scheme yet to be determined (likely the same one used for
  international domain names).

C: NUL (ASCII 0x00)
  The NUL character is used to terminate C/C++ strings.  Since the majority
  of Internet software is written in C/C++, NUL won't work on most mail
  systems.  RFC 822 permits it, but RFC 2822 forbids it.

Local Routing character conventions: !%@
  These have been used to express routing on local systems.  Their use in
  user email addresses is thus discouraged to be extra safe given the
  concerns they raise.

IMAP modified UTF-7 (RFC 2060): &
  The '&' character is the escape character for IMAP modified UTF-7.
  Thus it is likely to cause problems in user names on an IMAP-based
  mailstore.

LDAP search filter specials (RFC 2254): *()\ and NUL
  More systems, including iPlanet Messaging Server, are using LDAP to
  locally route email.  These five characters need to be quoted in LDAP
  search filters, but the traditional LDAP C SDK makes this step easy to
  forget.

Javascript: '"\
  Most client-side web form validation is done using Javascript.  Thus the
  primary quoting characters in Javascript may be problematic in email
  addresses.

To: [email-masked]
Xref: clerew local.mime:1812
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: drums2?
Date: Thu, 22 Aug 2002 15:45:32 GMT
Lines: 19
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>2. invalidate a huge number of existing user agents by creating a new syntax
>   for local parts that is incompatible with the old one.

Do we actually know what part of the huge range of possibilities within
the present syntax of local-part are actually in regular use in existing
user agents or in actual email addresses?

-- 
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: [email-masked]      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

To: [email-masked]
Subject: Re: MIME boundary strings
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 22 Aug 2002 07:42:26 -0700
Lines: 27
Sender: [email-masked]

Adrian 'Dagurashibanipal' von Bidder <[email-masked]> writes:
> On Thu, 2002-08-22 at 15:26, Russ Allbery wrote:

>> Most versions of Eudora also have an interesting bug wherein when
>> forming nested multiparts, some percentage of the time the exterior
>> boundary will be a prefix of the interior boundary.  I think they've
>> finally fixed this in the latest release.

> Just curiosity: isn't it a requirement that the boundary be on a line on
> its own? Then the brokenness would really be in the MIME parsers that
> misbehaved on such things.

Possibly, but on the other hand RFC 2046 is pretty explicit:

   As stated previously, each body part is preceded by a boundary
   delimiter line that contains the boundary delimiter.  The boundary
   delimiter MUST NOT appear inside any of the encapsulated parts, on a
   line by itself or as the prefix of any line.  This implies that it is
   crucial that the composing agent be able to choose and specify a unique
   boundary parameter value that does not contain the boundary parameter
   value of an enclosing multipart as a prefix.

Cyrus will misparse such broken boundaries unless you patch it, although
it's an easy patch.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Subject: Re: MIME boundary strings
From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: [email-masked]
Date: 22 Aug 2002 16:08:20 +0200
Sender: [email-masked]

--=-alOhR/xU2Tv3BaZT+Of2
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-08-22 at 15:26, Russ Allbery wrote:

> Most versions of Eudora also have an interesting bug wherein when forming
> nested multiparts, some percentage of the time the exterior boundary will
> be a prefix of the interior boundary.  I think they've finally fixed this
> in the latest release.

Just curiosity: isn't it a requirement that the boundary be on a line on
its own? Then the brokenness would really be in the MIME parsers that
misbehaved on such things.

cheers
-- vbi

--=20
secure email with gpg                      http://fortytwo.ch/gpg

WARNING: keyserver.kjsl.com *only* carries a valid copy of my key

--=-alOhR/xU2Tv3BaZT+Of2
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

Signature policy: http://fortytwo.ch/gpg/policy/email.20020822

--=-alOhR/xU2Tv3BaZT+Of2--

To: [email-masked]
Subject: Re: MIME boundary strings
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 22 Aug 2002 06:26:38 -0700
Lines: 38
Sender: [email-masked]

Jacob Palme <[email-masked]> writes:

> MIME specifies that the boundary string between body parts must be a
> string which does not occur in the body part itself. This goal can be
> achieved in two ways:

> (a) Try out different boundary string, until a string can
>      be found which does not occur.

Gnus uses this method, FWIW.  It also uses sane boundary strings
(combinations of - and =) that actually look like boundaries to people who
see the raw message, rather than the alphanumeric mess that most clients
use and that confuses the eye when looking at the raw message.

(I've long been of the opinion that MIME wouldn't have encountered as much
resistance as it did if the early implementors had used sane boundary
markers and not reiterated the default headers at the beginning of each
part; in other words, if they'd given some thought to how the message
looked to non-MIME-compliant readers.)

> (b) Select a sufficiently long random boundary string,
>      that the probability that it occurs in the body
>      part is negligible. This method is not really
>      permitted according to RFC 2046.

> I have an impression that many mail programs use method (b). And that
> some use method (b) but do not even select a really random boundary
> string.

I have the same impression.

Most versions of Eudora also have an interesting bug wherein when forming
nested multiparts, some percentage of the time the exterior boundary will
be a prefix of the interior boundary.  I think they've finally fixed this
in the latest release.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Arnt Gulbrandsen <[email-masked]>, Jacob Palme <[email-masked]>
Subject: Re: MIME boundary strings
Date: Thu, 22 Aug 2002 14:46:10 +0200
Cc: [email-masked]
Content-Description: clearsigned data
Sender: [email-masked]

On Thursday 22 August 2002 13:20, Arnt Gulbrandsen wrote:
> That's one possible strategy. There are three that I know of:
>
> a) if using quoted-printable, quote something.
> b) if using format=flowed, rewrap differently
> c) if nothing else helps, use base64 for that body-part
>
> Basically, the boundary strings should be treated like "From " or
> ".". A good MUA avoids those strings at the beginnings of lines. IMO,
> avoiding n strings isn't harder than avoiding 2.
<snip>

n strings? Just include '-' in the "From ", "." list.

But base64 and qp encoded body parts are no problem, since you just need 
to include "=_" in the boundary string, which cannot be part of a qp or 
b64 encoded stream (from rfc2046 ;-)

For 7bit or 8bit, you need to actually do something, though, if you want 
to make it perfect. But IMO,
  "=_" + base64encode( time(0) rand() rand() ) 
(ie. a time_t followed by a 64bit random number) is reasonable enough.

Marc

- -- 
Mutig warf sich die kleine Überwachungskamera zwischen Täter und Opfer!
                                        --Rena Tangens / FoeBuD e.V.

From: Arnt Gulbrandsen <[email-masked]>
To: Jacob Palme <[email-masked]>
Subject: Re: MIME boundary strings
Cc: [email-masked]
Date: Thu, 22 Aug 2002 16:50:05 +0530
Sender: [email-masked]

That's one possible strategy. There are three that I know of:

a) if using quoted-printable, quote something.
b) if using format=flowed, rewrap differently
c) if nothing else helps, use base64 for that body-part

Basically, the boundary strings should be treated like "From " or ".". A 
good MUA avoids those strings at the beginnings of lines. IMO, avoiding 
n strings isn't harder than avoiding 2.

A good MUA also quotes properly, which I can't right now ;) Sorry about 
that.

--Arnt

Date: Thu, 22 Aug 2002 13:02:57 +0200
To: Arnt Gulbrandsen <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: MIME boundary strings
Cc: [email-masked]
Sender: [email-masked]

At 15:20 +0530 02-08-22, Arnt Gulbrandsen wrote:
>c) pick some boundary string and make sure that one doesn't occur.

Do you mean by changing the content of the body part, if
necessary, making "invisible" changes so that the user sees
the same thing, for example by using QUOTED-PRINTABLE
"=[hexvalue]" for a character which normally does not need
to be hexcoded!
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Arnt Gulbrandsen <[email-masked]>
To: Jacob Palme <[email-masked]>
Subject: Re: MIME boundary strings
Cc: [email-masked]
Date: Thu, 22 Aug 2002 15:20:41 +0530
Sender: [email-masked]

There's a third way (which I use, btw):

c) pick some boundary string and make sure that one doesn't occur.

--Arnt

Date: Thu, 22 Aug 2002 11:27:15 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: MIME boundary strings
Sender: [email-masked]

MIME specifies that the boundary string between body parts
must be a string which does not occur in the body part
itself. This goal can be achieved in two ways:

(a) Try out different boundary string, until a string can
     be found which does not occur.

(b) Select a sufficiently long random boundary string,
     that the probability that it occurs in the body
     part is negligible. This method is not really
     permitted according to RFC 2046.

I have an impression that many mail programs
use method (b). And that some use method (b) but
do not even select a really random boundary string.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Wed, 21 Aug 2002 09:29:39 -0700 (PDT)
From: [email-masked]
Subject: Re: drums2?
To: Dave Crocker <[email-masked]>
Cc: Keith Moore <[email-masked]>, Charles Lindsey <[email-masked]>, [email-masked]
Sender: [email-masked]

> At 11:45 AM 8/21/2002 -0400, Keith Moore wrote:
> >choice #2 loses big time.

> Keith, et al,

> Big time enough to prompt me to suggest that we adhere to Pete's
> suggestion, namely that we decline to pursue this topic further, until
> there is a demonstration of a) substantially more support for such a
> massive change, and b) enough detail concerning the proposal to be able to
> assess the likely damage.

FWIW, I am in complete agreement with both Dave and Pete.

				Ned

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, "Charles Lindsey" <[email-masked]>, [email-masked]
Subject: Re: drums2? 
Date: Wed, 21 Aug 2002 12:15:12 -0400
Sender: [email-masked]

> >choice #2 loses big time.
> 
> Keith, et al,
> 
> Big time enough to prompt me to suggest that we adhere to Pete's
> suggestion, namely that we decline to pursue this topic further, until
> there is a demonstration of a) substantially more support for such a
> massive change, and b) enough detail concerning the proposal to be able to
> assess the likely damage.

Pete's suggestion was a good one.

Keith

Date: Wed, 21 Aug 2002 08:58:34 -0700
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: drums2? 
Cc: "Charles Lindsey" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 11:45 AM 8/21/2002 -0400, Keith Moore wrote:
>choice #2 loses big time.

Keith, et al,

Big time enough to prompt me to suggest that we adhere to Pete's 
suggestion, namely that we decline to pursue this topic further, until 
there is a demonstration of a) substantially more support for such a 
massive change, and b) enough detail concerning the proposal to be able to 
assess the likely damage.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: drums2? 
Date: Wed, 21 Aug 2002 11:45:21 -0400
Sender: [email-masked]

> Yes, you can do a nasty kludge like that, but it would be far better to
> review the definition of local-part, and decide on a sensible structure
> that carefully excluded the encoded forms.

we have two choices:

1. define a convention for I18N-ed local parts which is compatible with 
   current syntax and invalidates an infintesimal number of existing local-parts
2. invalidate a huge number of existing user agents by creating a new syntax
   for local parts that is incompatible with the old one.

choice #2 loses big time.

Keith

Date: Tue, 20 Aug 2002 22:11:49 -0500
To: "Charles Lindsey" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: drums2?
Cc: [email-masked]
Sender: [email-masked]

On 8/20/02 at 9:03 PM +0000, Charles Lindsey wrote:

>Yes, you can do a nasty kludge like that, but it would be far better 
>to review the definition of local-part, and decide on a sensible 
>structure that carefully excluded the encoded forms.

This was the same argument that was made against MIME: We can do the 
nasty kludge, but wouldn't it be better to simply decide on a 
sensible structure and re-do mail properly. That argument met the 
same fate that this one will.

Charles is the only one arguing for this position. I see no point in 
continuing this conversation unless there is reason to believe that 
others are in favor of resetting 2822. Otherwise, let's move on, 
please.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated

To: [email-masked]
Xref: clerew local.mime:1806
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: drums2?
Date: Tue, 20 Aug 2002 21:03:31 GMT
Lines: 30
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> You need therefore some foolproof way to distinguish between an encoded
>> local-part and an unencoded one. This means placing some restriction on
>> local-parts as presently defined.

>you do the same thing that IDN did:

>- you pick an encoding that is extremely unlikely to have been used in 
>  a real local-part.

>- you *always* use the encoded form on the wire.

>it doesn't require a change to the message format.

Yes, you can do a nasty kludge like that, but it would be far better to
review the definition of local-part, and decide on a sensible structure
that carefully excluded the encoded forms.

-- 
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: [email-masked]      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

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: drums2? 
Date: Mon, 19 Aug 2002 13:52:10 -0400
Sender: [email-masked]

> You need therefore some foolproof way to distinguish between an encoded
> local-part and an unencoded one. This means placing some restriction on
> local-parts as presently defined.

you do the same thing that IDN did:

- you pick an encoding that is extremely unlikely to have been used in 
  a real local-part.

- you *always* use the encoded form on the wire.

it doesn't require a change to the message format.

Keith

To: [email-masked]
Xref: clerew local.mime:1804
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: drums2?
Date: Mon, 19 Aug 2002 10:02:10 GMT
Lines: 38
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>I don't see why introducing I18N into the local-part need restrict the
>syntax or flexibliity for non-I18Ned local-parts.  As long as the I18N'ed
>local-parts are a subset of the current syntax then I don't see why this
>needs to affect 2822 or its successor.

Suppose an encoding is defined for local-parts (perhaps some form of
stringprep followed by punycode).

Suppose X is the original local-part in some strange charset, and Y is the
result of encoding it.

Then Y is also a valid local-part in its own right under the present
syntax, otherise there is no guarantee it will get transported (for
example, the output of punycode is always a valid local-part AIUI).

Then when you receive Y, how do you tell whether it was an encoding of X,
or whether it really was intended to use that crazy-looking Y as the
local-part of the address?

You need therefore some foolproof way to distinguish between an encoded
local-part and an unencoded one. This means placing some restriction on
local-parts as presently defined.

My own preference would be to limit genuine local parts to tokens, and to
arrange that the encoded form was not a token. But there are other ways.

-- 
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: [email-masked]      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

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: drums2? 
Date: Sun, 18 Aug 2002 15:56:20 -0400
Sender: [email-masked]

> >it is highly unlikely that IDNs will change the email syntax.
> 
> OTOH, any attempt to bring Internationalization into the local-part will
> almost certainly onvolve some restriction on its present flexibility, as I
> showed when we discussed this a few weeks back. That needs to be looked
> into before we cast it into concrete in its present form.

I don't see why introducing I18N into the local-part need restrict the
syntax or flexibliity for non-I18Ned local-parts.  As long as the I18N'ed
local-parts are a subset of the current syntax then I don't see why this
needs to affect 2822 or its successor.

From: "Bart Schaefer" <[email-masked]>
Date: Sun, 18 Aug 2002 19:22:28 +0000
Comments: In reply to Dave Crocker <[email-masked]> "Re: Mime = Spam?" (Aug 18, 11:05am)
To: [email-masked]
Subject: Re: Mime = Spam?
Sender: [email-masked]

On Aug 18, 11:05am, Dave Crocker wrote:
} 
} At 07:46 PM 8/18/2002 +0200, Jacob Palme wrote:
} >It is interesting to note that many of the advanced
} >features of MIME give spam points.
} 
} spam filter rulesets are typically derived from a kind of statistic 
} analysis of a group of messages that are considered to be spam.

Worse is that a number of sites are rejecting all multipart/alternative
messages as having "dangerous executable attachments" -- presumably
because of the Klez virus -- even when there are no executable parts.

Date: Sun, 18 Aug 2002 11:05:02 -0700
To: Jacob Palme <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Mime = Spam?
Cc: [email-masked]
Sender: [email-masked]

At 07:46 PM 8/18/2002 +0200, Jacob Palme wrote:
>It is interesting to note that many of the advanced
>features of MIME give spam points.

spam filter rulesets are typically derived from a kind of statistic 
analysis of a group of messages that are considered to be spam.

the actual statistics that are valid depend upon the recipient.  some rules 
that are correct for the 'average' recipient will be entirely wrong for one 
or another individual recipient.

hence one of the requirements for a serious spam filtering product is a 
means of training the rules set easily -- where easily means easily for an 
average end-user.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850

Date: Sun, 18 Aug 2002 19:46:26 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Mime = Spam?
Sender: [email-masked]

The antispam service I am using are giving the following
properties of a message spam points:

No. of
spam
points   Property of message
--------+----------------------------------
40       Subject contains =?iso-
40       Any header contains charset=ISO-8859-1
10       Any header contains Content-Transfer-Encoding: 8bit
15       Any header contains =?
40       Any header contains Content-Type: text/html; charset="ks_c_5601-1987"

A message with a total spam points larger than a
user-chosen limit, somewhere around 80, is regarded as spam.

In addition to the above points, the service also, of
course, give spam points for certain words like "mortgage"
or "teen".

In order to get the service working for me, I have
eliminated the first two items listed above for messages in
the Swedish language. I detect the Swedish language by the
occurence of two common Swedish words, the Swedish words
for "I" and "and" in the body of a message.

I have also had to change the service for some words which
are spam-indicators in English but not in Swedish, such as
"slut" which in Swedish means "end".

It is interesting to note that many of the advanced
features of MIME give spam points.

I read somewhere that it is the game and porn producers
who are pushing technology forwards nowadays, rather
than more serious usage of technology.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sun, 18 Aug 2002 08:52:34 -0500
To: "Charles Lindsey" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: drums2?
Cc: [email-masked]
Sender: [email-masked]

On 8/17/02 at 8:16 PM +0000, Charles Lindsey wrote:

>OTOH, any attempt to bring Internationalization into the local-part will
>almost certainly onvolve some restriction on its present flexibility, as I
>showed when we discussed this a few weeks back. That needs to be looked
>into before we cast it into concrete in its present form.

No, it doesn't need to be looked into. A future document is welcome 
to put a restriction on local-part in order to internationalize it. 
That will still leave these new international local-parts legal in 
the old system. That's fine.

The IETF documents current practice. We don't predict the future. 
Certainly not in Draft Standards. If you don't understand this, see 
RFC 2026.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: [email-masked]
Xref: clerew local.mime:1801
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: drums2?
Date: Sat, 17 Aug 2002 20:16:12 GMT
Lines: 25
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> OTOH, if a major change in email is shortly going to happen, namely hte
>> internationalization of addr-specs, then it does not seem to be the right
>> time to be bringing out a new standard that merely re-establishes the old
>> system.

>it is highly unlikely that IDNs will change the email syntax.

OTOH, any attempt to bring Internationalization into the local-part will
almost certainly onvolve some restriction on its present flexibility, as I
showed when we discussed this a few weeks back. That needs to be looked
into before we cast it into concrete in its present form.

- 
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: [email-masked]      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

Date: Fri, 16 Aug 2002 15:06:38 -0400
From: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: drums2?
Sender: [email-masked]

Yeah, I should have included ietf-smtp to begin with. Easily corrected. :-)

	Tony

Pete Resnick wrote:
> 
> I think the question of 2821 should be brought to ietf-smtp. There may 
> be more issues to deal with on it.

Date: Fri, 16 Aug 2002 11:51:23 -0700
To: Tony Hansen <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: drums2?
Cc: [email-masked]
Sender: [email-masked]

How about our formulating a detailed statement of what work needs to be 
done.  Think of it as a pre-charter-writing exercise.  From that, we can 
get an exact sense of the amount of work to be done.

Make a few small edits and reviewing them for consensus does not require a 
working group.  If we think there is likely to be any serious debating, 
then we probably do need a wg.

d/

At 01:46 PM 8/16/2002 -0400, Tony Hansen wrote:
>Before that question can be asked, and assuming that this is the right 
>time, we should be asking if we need a WG to do this work? Can it be done 
>WG-less?
>
>         Tony
>
>Chris Newman wrote:
>>Given that I'm burned out from being past Drums chair and really don't 
>>have the time to spare, are you volunteering to chair the effort?
>
>----------
>Dave Crocker  <mailto:[email-masked]>
>Brandenburg InternetWorking  <http://www.brandenburg.com>
>tel +1.408.246.8253;  fax +1.408.850.1850

Date: Fri, 16 Aug 2002 13:34:11 -0500
To: Tony Hansen <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: drums2?
Cc: [email-masked]
Sender: [email-masked]

On 8/16/02 at 1:46 PM -0400, Tony Hansen wrote:

>Chris Newman wrote:
>>Given that I'm burned out from being past Drums chair and really 
>>don't have the time to spare, are you volunteering to chair the 
>>effort?
>
>Before that question can be asked, and assuming that this is the 
>right time, we should be asking if we need a WG to do this work? Can 
>it be done WG-less?

With regard to 2822, I think this is the right time (or it least in 
can be in the next few weeks) and it can be done WG-less. Coming up 
with someone to do the implementation review is the interesting 
question, especially if Chris doesn't have the time to do it.

I think the question of 2821 should be brought to ietf-smtp. There 
may be more issues to deal with on it.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 16 Aug 2002 13:46:43 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: drums2?
Sender: [email-masked]

Before that question can be asked, and assuming that this is the right 
time, we should be asking if we need a WG to do this work? Can it be 
done WG-less?

	Tony

Chris Newman wrote:
> Given that I'm burned out from being past Drums chair and really don't 
> have the time to spare, are you volunteering to chair the effort?

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: drums2? 
Date: Fri, 16 Aug 2002 13:20:14 -0400
Sender: [email-masked]

> OTOH, if a major change in email is shortly going to happen, namely hte
> internationalization of addr-specs, then it does not seem to be the right
> time to be bringing out a new standard that merely re-establishes the old
> system.

it is highly unlikely that IDNs will change the email syntax.

Keith

Date: Fri, 16 Aug 2002 11:51:43 -0500
To: "Charles Lindsey" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: drums2?
Cc: [email-masked]
Sender: [email-masked]

On 8/16/02 at 11:24 AM +0000, Charles Lindsey wrote:

>Well reclassifying a few items into or out of the obsolete category is not
>necessarily "new technical work" is it? Surely that is just tidying up.

Nope, that's new technical work. A Draft Standards documents existing 
practice. It doesn't say how things should be.

>OTOH, if a major change in email is shortly going to happen, namely hte
>internationalization of addr-specs, then it does not seem to be the right
>time to be bringing out a new standard that merely re-establishes the old
>system.

Two things:

1. This is the way the IETF works. We add on to the old system with 
new Proposed Standards, we document the old system with Draft and 
Full Standards. It seems perfectly "right". Other standards bodies 
might operate differently.

2. If there is a major change in e-mail, it better happen in a way 
that doesn't invalidate the old system. That was what was great about 
MIME: Every MIME message is a perfectly valid 822 message, only it 
was interpreted differently. Documenting the old system (and it's not 
a "new standard") is *exactly* what needs to happen if there is going 
to be a major change: It should be perfectly clear for the proposed 
change what will conform to the current system.

This is "IETF 101" stuff. Moving to Draft Standard *removes* stuff 
from the spec that doesn't correspond to reality. It *never* adds or 
changes stuff. Perhaps your message is a good indicator that we 
haven't been moving things to Draft Standard nearly enough lately.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: [email-masked]
Xref: clerew local.mime:1793
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: drums2?
Date: Fri, 16 Aug 2002 11:24:09 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> Dave Crocker <[email-masked]> writes:

>At 09:36 AM 8/15/2002 +0000, Charles Lindsey wrote:
>>I think it might be wiser to wait until the Internationalization issues
>>have been settled, or at least become clearer. For that we need IDN up and
>>deployed in the real world. We also need to look carefully at local-parts
>>to see whether they need to be restricted further (or at least have some
>>features moved to the obsolete section).

>you are talking about doing new technical work.  that's not what moving to 
>Draft is for.

Well reclassifying a few items into or out of the obsolete category is not
necessarily "new technical work" is it? Surely that is just tidying up.

OTOH, if a major change in email is shortly going to happen, namely hte
internationalization of addr-specs, then it does not seem to be the right
time to be bringing out a new standard that merely re-establishes the old
system.

-- 
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: [email-masked]      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

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], IETF fax WG <[email-masked]>
Subject: Message Disposition Notification:  Second request for implementat ion status
Date: Fri, 16 Aug 2002 07:02:53 -0500
Sender: [email-masked]

The IESG has requested a more detailed implementation report for the advancement of the message disposition notification protocol to Draft Standard.  The current documentation of this protocol is <draft-vaudreuil-mdnbis-03.txt>, which is intended to replace proposed standard RFC 2298.  The current version of the protocol and the submitted interoperability report is based on a call for implementation information solicited and compiled after the London IETF meeting last year.   I appreciate the responses to the previous query for information on this protocol late last year.  Unfortunately, the bar has been raised on implementation reports and I need more detailed information than was previously collected.

If you can authoritatively respond on the capabilities of a contemporary implementation of this protocol, please reply to the questions below.  I will compile the responses into documentation sufficient to advance this seemingly mature protocol to draft standard.

Information is requested from three classes of systems based on their role in the protocol chain:  MDN requesting UA's (including gateways), MDN Generating UA's (including gateways), MDN receiving UA's (Including gateways), and final-delivery MTA's.

Thank you.  All responses will be appreciated.

Greg Vaudreuil

P.S., My appologies for cross-posting this message to multiple lists.  I want to ensure that we get a responses from the many communities that have made use of this protocol.

----------------------------

Please identify the following line-items in such a reply.

1) Name of software, vendor, and version upon which this response is based
   a) Approximately when was this feature introduced into a public release?

2) MDN Requesting user agent behaviors

  a) Client sends disposition-notification-to header:  (Y/N)

  b) Client sends disposition-notifications-options header (Y/N)
       b1) Client sends request for proprietay options (describe)

  c) Message disposition header is placed in inner message when used with message partial (Y/N/NA)
	Please indicate N/A if the UA or gateway does not generate message partial constructs

3) Final MTA behaviors

  a) Final MTA (Delivery process) copies ORCPT parameter from RCPT-TO command into Original-Recipient
          header of message upon deposit

4) MDN Generating UA

  a) MDN report is generated upon request (Y/N). If yes, which fields are populated:
         Reporting-UA 
	   mdn-gateway-field
	   original-recipient-field
	   final-recipient-field
	   original-message-id-field
	   disposition-field
	   failure-field
	   error-field
	   warning-field
	         extension-field

b) Which disposition modes are supported / generated:
	Manual action
	automatic action
            MDN-sent-manually
	MDN-sent-automatically   

c) Which disposition types are generated
	displayed
	deleted

d) Are any extension fields generated?

5) MDN Receiving user agent behavior

   a) Which of the following fields are presented to the user or converted into a foreign format via gateway

         Reporting-UA 
	   mdn-gateway-field
	   original-recipient-field
	   final-recipient-field
	   original-message-id-field
	   disposition-field
	   failure-field
	   error-field
	   warning-field
	         extension-field

6) Interoperability Experience

Please list those implementations that are known to interoperate with this implementation.  Please describe what if any known interoperability problems are know with the MDN protocol and this implementation.

Date: Thu, 15 Aug 2002 10:44:40 -0700 (PDT)
From: [email-masked]
Subject: Re: drums2?
To: Pete Resnick <[email-masked]>
Cc: [email-masked], Tony Hansen <[email-masked]>, [email-masked]
Sender: [email-masked]

> > A new version of 2822 may be needed as well.

> It does. I've got a list of small errors that need to be corrected. I
> should be able to come up for air in a few weeks and perhaps start on
> the revision. It really shouldn't take too long.

> > I suspect 2822bis would be able to move to draft.

> I agree. Who gets to do the implementation review for this?

The way this is normally done is to have somebody write down a list of features
specified in the document. Then a call goes out and implementors respond with a
line by line list of the stuff they implement.

Constructing the list is something of an art. Making it too general is bad --
you cannot just say "Yes/No implement everything in the document". But too much
detail is also bad -- you don't want to check for every line of ABNF, for
example.

I'd suggest breaking 2822 down into functional areas and having one entry on
the list for each.

The usual people who do this are the chairs or former chairs of the WG which
produced the specification, but in practice anyone with the necessary expertise
can do it. I did the list for NOTARY, for example.

				Ned

Date: Thu, 15 Aug 2002 08:38:04 -0700
To: "Charles Lindsey" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: drums2?
Cc: [email-masked]
Sender: [email-masked]

At 09:36 AM 8/15/2002 +0000, Charles Lindsey wrote:
>I think it might be wiser to wait until the Internationalization issues
>have been settled, or at least become clearer. For that we need IDN up and
>deployed in the real world. We also need to look carefully at local-parts
>to see whether they need to be restricted further (or at least have some
>features moved to the obsolete section).

you are talking about doing new technical work.  that's not what moving to 
Draft is for.

new technical works requires a specification to start at Proposed.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: drums2? 
Date: Thu, 15 Aug 2002 10:06:19 -0400
Sender: [email-masked]

> I think it might be wiser to wait until the Internationalization issues
> have been settled, or at least become clearer. 

I strongly disagree.  That's a huge can of worms that would set back the
entire effort many years if we made it critical path for advancement 2821/2822.

To: [email-masked]
Xref: clerew local.mime:1789
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: drums2?
Date: Thu, 15 Aug 2002 09:36:59 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

>> 2821/2822 are "Proposed Standards" and have been out for 1.5 years now.
>> What will it take to move them forward to Draft Standard?

>At a minimum a new version of 2821 needs to be prepared. A new version
>of 2822 may be needed as well.

>I suspect 2822bis would be able to move to draft. I think it is unlikely
>that 2821bis will be able to.

I think it might be wiser to wait until the Internationalization issues
have been settled, or at least become clearer. For that we need IDN up and
deployed in the real world. We also need to look carefully at local-parts
to see whether they need to be restricted further (or at least have some
features moved to the obsolete section).

And we also need to review the whole of the obsolete section to see
whether any parts of it could be dropped.

-- 
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: [email-masked]      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

Date: Wed, 14 Aug 2002 22:32:40 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: drums2?
Cc: Tony Hansen <[email-masked]>, [email-masked]
Sender: [email-masked]

On 8/14/02 at 1:37 PM -0700, [email-masked] wrote:

>>2821/2822 are "Proposed Standards" and have been out for 1.5 years 
>>now. What will it take to move them forward to Draft Standard?
>
>A new version of 2822 may be needed as well.

It does. I've got a list of small errors that need to be corrected. I 
should be able to come up for air in a few weeks and perhaps start on 
the revision. It really shouldn't take too long.

>I suspect 2822bis would be able to move to draft.

I agree. Who gets to do the implementation review for this?

>>P.S. If 2821 and 2822 need to be reissued, it might also be nice if 
>>they could be done in time to get the numbers 3821 and 3822. My 
>>estimate is that those numbers will be reached in about 23 months. 
>>That should give us enough time to work on them, if we started now. 
>>:-)
>
>Good point ;-)

We could get close to 3422 or maybe 3522 for Draft. I think we should 
shoot for 3822 for Full Standard. :-) (SMTP is SMTP, but the mail 
format really is 822!)

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 14 Aug 2002 20:29:33 -0700
To: Philip Hazel <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Party Time?
Cc: [email-masked]
Sender: [email-masked]

At 08:59 AM 8/13/2002 +0100, Philip Hazel wrote:
>Today is the 20th anniversary of the publication of RFC 822 (821 just
>says "August"). I thought the list might be interested in this trivia.

Personally, I think the more historic data was publication on 21 Nov 77 of 
RFC733.

1.  It was the first accepted codification for email and most of its 
constructs are still part of Internet mail.  So it is reasonable to say 
that standardized Internet mail is about to have its 25th birthday.

2.  It was the first RFC to have a formal status of standard.  There was 
quite a bit of work behind getting permission to add that word to the 
title, and quite a bit of community reaction to its appearance.

3.  822 is really only a refinement of 733.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850

Date: Wed, 14 Aug 2002 13:37:27 -0700 (PDT)
From: [email-masked]
Subject: Re: drums2?
To: Tony Hansen <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 2821/2822 are "Proposed Standards" and have been out for 1.5 years now.
> What will it take to move them forward to Draft Standard?

At a minimum a new version of 2821 needs to be prepared. A new version
of 2822 may be needed as well.

I suspect 2822bis would be able to move to draft. I think it is unlikely
that 2821bis will be able to.

> We've had
> considerably longer than 1.5 years to get operational experience with
> them, and I KNOW that there are lots of interoperational instances of each.

> 	Tony Hansen
> 	[email-masked]

> P.S. If 2821 and 2822 need to be reissued, it might also be nice if they
> could be done in time to get the numbers 3821 and 3822. My estimate is
> that those numbers will be reached in about 23 months. That should give
> us enough time to work on them, if we started now. :-)

Good point ;-)

				Ned

Date: Wed, 14 Aug 2002 16:11:08 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: drums2?
Sender: [email-masked]

2821/2822 are "Proposed Standards" and have been out for 1.5 years now. 
What will it take to move them forward to Draft Standard? We've had 
considerably longer than 1.5 years to get operational experience with 
them, and I KNOW that there are lots of interoperational instances of each.

	Tony Hansen
	[email-masked]

P.S. If 2821 and 2822 need to be reissued, it might also be nice if they 
could be done in time to get the numbers 3821 and 3822. My estimate is 
that those numbers will be reached in about 23 months. That should give 
us enough time to work on them, if we started now. :-)

Date: Tue, 13 Aug 2002 08:59:42 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: [email-masked]
Subject: Party Time?
Sender: [email-masked]

Today is the 20th anniversary of the publication of RFC 822 (821 just
says "August"). I thought the list might be interested in this trivia.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

To: [email-masked]
Xref: clerew local.mime:1783
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: RHijacked Addresses
Date: Mon, 12 Aug 2002 09:18:51 GMT
Lines: 20
Sender: [email-masked]

In <p05111a0fb97a161e0af0@[165.227.249.18]> Paul Hoffman / IMC <[email-masked]> writes:

>And you blame this lack of interoperability on the S/MIME spec, not 
>on the six-part "profile" put out by the German government? Somehow, 
>I suspect it is the latter....

I think it arises principally from the well-know inadequacies of X509, and
from inconsistent attempts to add new "features" to X509 certificates.

-- 
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: [email-masked]      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

Date: Fri, 9 Aug 2002 18:01:39 -0700
To: Marc Mutz <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: RHijacked Addresses
Cc: [email-masked]
Sender: [email-masked]

And you blame this lack of interoperability on the S/MIME spec, not 
on the six-part "profile" put out by the German government? Somehow, 
I suspect it is the latter....

--Paul Hoffman, Director
--Internet Mail Consortium

To: [email-masked]
Subject: Re: RHijacked Addresses
Sensitivity: 
From: Nick Shelness<[email-masked]>
Date: Sat, 10 Aug 2002 13:04:31 +0100
Sender: [email-masked]

In an earlier note, I wrote

> This situation is made worse by legal prohibitions on providing plugable 

> crypto interfaces. It would be technically easy for S/MIME and other 
> application to employ a set of APIs (even better we could standardize 
> them) to crypto packages. Sadly, this remains illegal in many countries 
> including USA.

I thought that before I get flamed, I need to provide a little bit more 
detail/context.

1. Vendors are not prohibited from supporting plug-ins that access an 
email message on the occurrence of certain events (for example, on 
submission, and when being opened for display), when these plug-ins can be 
shown to have meaningful non-crypto purposes. It is recognized that these 
plug-ins can also be employed to perform crypto processing on outbound and 
inbound messages. Outlook and Notes/Domino plug-ins have been developed by 
third parties to do just this. In general these have not been particularly 
reliable or successful in the market.

2. Microsoft received a dispensation (which others may now have also 
received), which allowed them to provide support for pure crypto plug-ins. 
This dispensation required them to only allow plug-ins to be employed that 
had been approved by the NSA. This restriction is enforced by requiring 
crypto plug-ins to be signed using a special Microsoft key. This signature 
is verified when the plug-in is first called. Though I recently heard (via 
hearsay rather than a reliable source)that the NSA has approved additional 
plug-ins (including possibly one for Germany), for a long time they had 
approved only one. Under this circumstance, there was not much point in 
other vendors following MS' lead.

Nick

Nick Shelness
Independent Technology Consultant
Fellow - Differéntis Ltd.
Advisor - Oak Investment Partners

Contact Details
   Office Tel: +44 (0) 1828 640 632
   Office Fax: +44 (0) 1828 640 647
   Internet email: [email-masked]
   Short message: +44 7753 566460 or [email-masked]
   AOL instant messaging: NickShelness
   MSN instant messaging: [email-masked]
   Yahoo instant messaging: NickShelness
   Snail mail: The Old Mill, Meigle, Perthshire, PH12 8TJ, UK

To: [email-masked]
Subject: Re: RHijacked Addresses
Sensitivity: 
From: Nick Shelness<[email-masked]>
Date: Sat, 10 Aug 2002 12:08:30 +0100
Sender: [email-masked]

> <snip how S/MIME works>
>
> OK, I knew all this. What's your point?

No! What I described is not how S/MIME works. S/MIME is a protocol for the 
exchange of signed and encrypted messages and/or MIME parts. What I 
described is the security environment in which S/MIME implementations have 
to operate. What I, and I think Paul, have been trying to say is that 
S/MIME (the protocol) is not broken, and that S/MIME implementations from 
MS, NS, and IBM running in a common security environment (in practice, the 
basic environment specified by the standard) inter-operate well. The 
problem, which I think you are identifying, and with which I, and I think 
Paul, completely agree is the absence of a common security environment, or 
rather the presence of so many different ones. This situation is made 
worse by legal prohibitions on providing plugable crypto interfaces. It 
would be technically easy for S/MIME and other application to employ a set 
of APIs (even better we could standardize them) to crypto packages. Sadly, 
this remains illegal in many countries including USA.

Nick

Nick Shelness
Independent Technology Consultant
Fellow - Differéntis Ltd.
Advisor - Oak Investment Partners

Contact Details
   Office Tel: +44 (0) 1828 640 632
   Office Fax: +44 (0) 1828 640 647
   Internet email: [email-masked]
   Short message: +44 7753 566460 or [email-masked]
   AOL instant messaging: NickShelness
   MSN instant messaging: [email-masked]
   Yahoo instant messaging: NickShelness
   Snail mail: The Old Mill, Meigle, Perthshire, PH12 8TJ, UK

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Nick Shelness <[email-masked]>, [email-masked]
Subject: Re: RHijacked Addresses
Date: Sat, 10 Aug 2002 11:35:03 +0200
Content-Description: clearsigned data
Sender: [email-masked]

On Saturday 10 August 2002 11:08, Nick Shelness wrote:
> Mark,

Nicc ;-)

<snip how S/MIME works>

OK, I knew all this. What's your point?

Marc

- -- 
If free-software authors lose the right to disclaim all warranties and
find themselves getting sued over the performance of the programs
they've written, they'll stop contributing free software to the world.
 -- Bruce Perens: Open Sources: Voices from the Open Source Revolution

To: [email-masked]
Subject: Re: RHijacked Addresses
Sensitivity: 
From: Nick Shelness<[email-masked]>
Date: Sat, 10 Aug 2002 10:08:48 +0100
Sender: [email-masked]

Mark,

> The ISIS/MTTv2 standard consists of six parts, see
> http://www.secorvo.de/publikat/mttspc20.zip.
> The one most applicable to S/MIME is surely "Profiles for Certificates 
> and CRLs". It describes on 45 pages whata certificate needs to contain 
> and where. Same for CRLs.
> 
> I translate for you the first few paragraphs of the summary:
> 
> Q> The stucture of the present document essentially follows that of PKIX 

> Q> document "Cerificate and CRL Profile" [PKIX-PRO 98], which specifies 
> Q> a profile for an internet-PKI. [...]
> Q>
> Q> The profiles are based on the current standard X.509v3 [ITU-T X.509 
> Q. 97], while the v1.1 standard is based on X.509v1. The current
> Q> standard allows to insert an unlimited number of additional fields in 

> Q> a certificate (certificate extensions) and in CRLs. Therefore, for 
> Q> interop's sake, a suitable selection needs to be carried out. The 
> Q> profiles serve primarily this purpose.
> Q>
> Q> Certificates and CRLs need to include all essential information that 
> Q> is needed for validity checks of digital signatures and keys. Hence
> Q> there exists a close relationship between said information and the 
> Q> validity model(?) used.
> Q>
> Q> The validity model contained in the present document defines under 
> Q> which circumstances a digital signature will be considered valid. 
> Q> This ensures that all MailTrusT components employ the same check 
> Q> procedures.
> Q>
> Q> A prerequisite for validity checks is the presence of all needed 
> Q> certificates and CRLs. Obtaining these objects will generally depend 
> Q> on information contained in the certificates. This is also covered by 

> Q> the present document.
> Q>
> Q> The spec is divided into the following chapters:
> Q> 2. definitions
> Q> 3. certificate formats: A profile is defined for certifiates in a
> Q>    MailTrusT PKI.
> Q> 4. CRL format: A profile is defined for CRLs in a MailTrusT PKI
> Q> 5. validity model
> Q> 6. check of certificate path
> 
> IIRC, this doc needs to concern itself with such seemingly trivial 
> things as "where do I find the email address to which this certificate 
> is bound?" for a given certificate...
> 

Whoa. You've changed the subject here.

The question of how an application (in this case S/MIME) interfaces to 
security credentials is important. When employed in conjunction with soft 
certificates (a string of bits encoding a certificate and a private key), 
the application needs to perform crypto processing either directly, or via 
a collocated crypto library. When employed in conjunction with hard 
certificates (smart cards), certificate based crypto processing is by 
definition performed on the smart card. The private key never leaves the 
card, and data to be encrypted/decrypted using that key is instead 
streamed through the smart card. The good news is that a standard has been 
defined that provide a common interface (PKCS13) to hard certificates and 
allows encryption/decryption and other associated functions (PIN 
provision) to be performed. The major email vendors have either added or 
are in the process of adding PKCS13 based hard certificate support to 
their S/MIME products. There are of course other proprietary interfaces 
available, both from smart card vendors, and the likes of Microsoft 
(pccard) which muddy the waters. Also, and this is a much hornier problem, 
an application (again S/MIME) that needs to verify a certificate provided 
by a correspondent, has to verify that this certificate and any other 
certificates employed to sign that certificate are correctly signed and 
have not been revoked. The latter requires access to a suitably up-to-date 
Certificate Revocation List (CRL). You are correct in stating that this 
particular aspect of crypto technology is currently a mess, and as a 
result, unless their crypto library supports CRL checking against some ad 
hoc form of CRL repository, it doen't get done.

Nick

Nick Shelness
Independent Technology Consultant
Fellow - Differéntis Ltd.
Advisor - Oak Investment Partners

Contact Details
   Office Tel: +44 (0) 1828 640 632
   Office Fax: +44 (0) 1828 640 647
   Internet email: [email-masked]
   Short message: +44 7753 566460 or [email-masked]
   AOL instant messaging: NickShelness
   MSN instant messaging: [email-masked]
   Yahoo instant messaging: NickShelness
   Snail mail: The Old Mill, Meigle, Perthshire, PH12 8TJ, UK

From: "Ken Hirsch" <[email-masked]>
To: <[email-masked]>
Subject: Re: RHijacked Addresses
Date: Fri, 9 Aug 2002 22:16:43 -0400
Sender: [email-masked]

> > What is in the "German profile" that isn't in the
> > IETF standard?

Peter Gutmann has an article on X.509 certificate profiles at
http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Nick Shelness <[email-masked]>, [email-masked]
Subject: Re: RHijacked Addresses
Date: Sat, 10 Aug 2002 02:52:46 +0200
Content-Description: clearsigned data
Sender: [email-masked]

On Saturday 10 August 2002 01:30, Nick Shelness wrote:
<snip>
> > What is in the "German profile" that isn't in the IETF standard?
<snip>
> These tend not to work very well, inter-operate,
> etc. I think this is what Marc is referring to. This of course has
> nothing to do with the S/MIME you and I are familiar with, but with
> special military versions of S/MIME, or more accurately "sort of
> S/MIME".
<snip>

No, not (only) military. They've introduced it in the administration and 
will likely extend it to eGovernment. The idea is that every citizen 
can go the local registry office and get a smartcard to do 
"eGovernment".

Marc

Mutig warf sich die kleine Überwachungskamera zwischen Täter und Opfer!
                                          --Rena Tangens / FoeBuD e.V.
- -- 
Marc Mutz <[email-masked]>

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Paul Hoffman / IMC <[email-masked]>
Subject: Re: RHijacked Addresses
Date: Sat, 10 Aug 2002 02:45:47 +0200
Cc: [email-masked]
Content-Description: clearsigned data
Sender: [email-masked]

On Saturday 10 August 2002 00:46, Paul Hoffman / IMC wrote:
> At 12:41 AM +0200 8/10/02, Marc Mutz wrote:
> >Oh, and why do Outlook, Notes and Groupwise need plugins for the
> > German S/MIME profile?
> >http://www.bsi.bund.de/aufgaben/projekte/sphinx/interop/ergeb102.htm
> >(sorry, in German, but "Tabelle 2" should be self-explanatory ;-)
>
> It's not, sorry.

Well, every X stands for a point of non-interoperability...

> What is in the "German profile" that isn't in the
> IETF standard?
<snip>

The ISIS/MTTv2 standard consists of six parts, see
http://www.secorvo.de/publikat/mttspc20.zip.
The one most applicable to S/MIME is surely "Profiles for Certificates 
and CRLs". It describes on 45 pages whata certificate needs to contain 
and where. Same for CRLs.

I translate for you the first few paragraphs of the summary:

Q> The stucture of the present document essentially follows that of PKIX 
Q> document "Cerificate and CRL Profile" [PKIX-PRO 98], which specifies 
Q> a profile for an internet-PKI. [...]
Q>
Q> The profiles are based on the current standard X.509v3 [ITU-T X.509 
Q. 97], while the v1.1 standard is based on X.509v1. The current
Q> standard allows to insert an unlimited number of additional fields in 
Q> a certificate (certificate extensions) and in CRLs. Therefore, for 
Q> interop's sake, a suitable selection needs to be carried out. The 
Q> profiles serve primarily this purpose.
Q>
Q> Certificates and CRLs need to include all essential information that 
Q> is needed for validity checks of digital signatures and keys. Hence
Q> there exists a close relationship between said information and the 
Q> validity model(?) used.
Q>
Q> The validity model contained in the present document defines under 
Q> which circumstances a digital signature will be considered valid. 
Q> This ensures that all MailTrusT components employ the same check 
Q> procedures.
Q>
Q> A prerequisite for validity checks is the presence of all needed 
Q> certificates and CRLs. Obtaining these objects will generally depend 
Q> on information contained in the certificates. This is also covered by 
Q> the present document.
Q>
Q> The spec is divided into the following chapters:
Q> 2. definitions
Q> 3. certificate formats: A profile is defined for certifiates in a
Q>    MailTrusT PKI.
Q> 4. CRL format: A profile is defined for CRLs in a MailTrusT PKI
Q> 5. validity model
Q> 6. check of certificate path

IIRC, this doc needs to concern itself with such seemingly trivial 
things as "where do I find the email address to which this certificate 
is bound?" for a given certificate...

Marc

Mutig warf sich die kleine Überwachungskamera zwischen Täter und Opfer!
                                          --Rena Tangens / FoeBuD e.V.
- -- 
Marc Mutz <[email-masked]>

To: [email-masked]
Subject: Re: RHijacked Addresses
Sensitivity: 
From: Nick Shelness<[email-masked]>
Date: Sat, 10 Aug 2002 00:30:00 +0100
Sender: [email-masked]

Paul,

> What is in the "German profile" that isn't in the IETF standard?

If I remember correctly, I left Lotus more than 16 months ago, the 
military establishments of many European countries decided that they 
wanted a "Commercial of the Shelf" (COTS) messaging system based on open 
standards (in this case S/MIME). They then each produced a huge pile of 
requirements that differed from country to country, and couldn't be met by 
any COTS system. In order to win the business, the vendor organization in 
each country, first attempted to have their base products modified. The 
vendors development organizations having been led down a similar garden 
path by the US DOD over the X.400 based (kind of) Defense Messaging 
System, refused. The revenue opportunities couldn't justify the cost. 
Since salesmen never take no for an answer, they then contracted with 
local software houses to produce plug-ins. These tend not to work very 
well, inter-operate, etc. I think this is what Marc is referring to. This 
of course has nothing to do with the S/MIME you and I are familiar with, 
but with special military versions of S/MIME, or more accurately "sort of 
S/MIME".

Nick

Nick Shelness
Independent Technology Consultant
Fellow - Differéntis Ltd.
Advisor - Oak Investment Partners

Contact Details
   Office Tel: +44 (0) 1828 640 632
   Office Fax: +44 (0) 1828 640 647
   Internet email: [email-masked]
   Short message: +44 7753 566460 or [email-masked]
   AOL instant messaging: NickShelness
   MSN instant messaging: [email-masked]
   Yahoo instant messaging: NickShelness
   Snail mail: The Old Mill, Meigle, Perthshire, PH12 8TJ, UK

Date: Fri, 9 Aug 2002 15:46:51 -0700
To: Marc Mutz <[email-masked]>, Jacob Palme <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: RHijacked Addresses
Cc: [email-masked]
Sender: [email-masked]

At 12:41 AM +0200 8/10/02, Marc Mutz wrote:
>Oh, and why do Outlook, Notes and Groupwise need plugins for the German
>S/MIME profile?
>http://www.bsi.bund.de/aufgaben/projekte/sphinx/interop/ergeb102.htm
>(sorry, in German, but "Tabelle 2" should be self-explanatory ;-)

It's not, sorry. What is in the "German profile" that isn't in the 
IETF standard?

--Paul Hoffman, Director
--Internet Mail Consortium

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Paul Hoffman / IMC <[email-masked]>, Jacob Palme <[email-masked]>
Subject: Re: RHijacked Addresses
Date: Sat, 10 Aug 2002 00:41:16 +0200
Cc: [email-masked]
Content-Description: clearsigned data
Sender: [email-masked]

On Friday 09 August 2002 21:46, Paul Hoffman / IMC wrote:
<snip>
> >If you are talking about S/MIME, I fail to see where "good
> >interoperability" lies.
>
> Outlook, Netscape, and Lotus Notes.
<snip>

Oh, and why do Outlook, Notes and Groupwise need plugins for the German 
S/MIME profile?
http://www.bsi.bund.de/aufgaben/projekte/sphinx/interop/ergeb102.htm 
(sorry, in German, but "Tabelle 2" should be self-explanatory ;-)

Marc

Mutig warf sich die kleine Überwachungskamera zwischen Täter und Opfer!
                                          --Rena Tangens / FoeBuD e.V.
- -- 
Marc Mutz <[email-masked]>

Date: Fri, 9 Aug 2002 12:46:20 -0700
To: Marc Mutz <[email-masked]>, Jacob Palme <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: RHijacked Addresses
Cc: [email-masked]
Sender: [email-masked]

At 10:39 AM +0200 8/9/02, Marc Mutz wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Monday 05 August 2002 18:30, Paul Hoffman / IMC wrote:
>>  At 8:49 PM +0200 8/4/02, Jacob Palme wrote:
>>  >I am not a security expert and do not understand why.
>>  >Possible causes could be:
>>  >
>>  >- Competing standards where unity is needed.
>>
>>  Not true for email. S/MIME has been built into most widely-used MUAs
>>  for many years; almost no one uses it.
>
>Oh, and is that any wonder? S/MIME combines the wonderful properties of
>non-interoperability, complexity, too vague standards and overly high
>costs. Of course, those properties are not independent of each other:
>
>E.g. the high costs come from interop tests that _any_ company must
>beform for itself after choosing a profile.
>Non-interoperability comes from the vague standards wording and the
>complexity.

Um, which S/MIME clients have you found that don't interoperate for 
typical email? FWIW, I have seen much more discussion of PGP clients 
not interoperating than for S/MIME clients, but that might be due to 
the higher amount of use of PGP among developers.

>There must be a reason why so many PKI projects fail to succeed.

True, but it is not necessarily due to lack of interop. The lack of 
understanding of trust, and the mistrust of trust, rate very high 
there.

>  > Complex, yes; expensive, no. But the complexity hasn't prevented them
>>  from being widely deployed with quite good interoperability.
><snip>
>
>If you are talking about S/MIME, I fail to see where "good
>interoperability" lies.

Outlook, Netscape, and Lotus Notes.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Keith Moore <[email-masked]>
To: Nick Shelness <[email-masked]>
cc: [email-masked]
Subject: Re: RHijacked Addresses 
Date: Fri, 09 Aug 2002 11:06:21 -0400
Sender: [email-masked]

> The question, therefore, is can we find any entities (governments, 
> institutions, individuals, etc.) that are trust-worthy enough.

I think we can find many entities that are trust-worthy enough for
some purposes; I doubt we shall find any entity that is trust-worthy
enough for all or even most pruposes.   That is why I don't believe
in a global single-rooted PKI.

As long as people still choose who to trust based on their assessment
of risk for that particular situation, I have no problem with the 
government being one of the parties that is able to make assertions  
about someone's identity.  However one of the pitfalls associated with 
the government acting as a CA is that the government can compel you 
to place trust in its credentials even when the trust is unwarranted.

Keith

To: [email-masked]
Subject: Re: RHijacked Addresses
Sensitivity: 
From: Nick Shelness<[email-masked]>
Date: Fri, 9 Aug 2002 15:03:51 +0100
Sender: [email-masked]

Keith,

[email-masked] wrote on 08/09/2002 14:34:27:

> The US government is not trustworthy.  A government that will break its
> own constitution at a whim will think nothing of issuing false 
credentials,
> revoking certificates, and committing identity theft any time it is
> convenient (of course they will claim it is in the national interest but
> nobody will be able to verify such claims); and a government-controlled 
PKI 
> would give them much more ability to do this than they currently have 
with 
> paper documents. 

Viewed as an absolute, no government, institution or individual is 
completely trust-worthy. We might not even be happy if they were. Trust is 
relative. It would be fantastic is we could build a broad web of trust 
that didn't depend upon the trustfulness of any government, institution or 
individual, but I don't think that is possible. The question, therefore, 
is can we find any entities (governments, institutions, individuals, etc.) 
that are trust-worthy enough. The answer I think is yes. We'd be in much 
better shape if everyone had access to suitably reliable identities, even 
if occasionally the issuing institution betrayed our trust. There is of 
course and ancillary issue which is much more worrying to Americans and 
(yes Marc) Britons, and that would be an absolute requirement to employ 
that identity for non-voluntary transactions. Americans and Britons don't 
have to carry identity cards and don't want to, though clearly they are 
willing to produce suitable guarantees of identity when entering into 
certain voluntary transactions. E.g., boarding an airplane, entering of 
leaving a country, or cashing a check, etc. Europeans on the other hand 
have been carrying identity cards for a long time, and at least since the 
demise of totalitarian government, don't seem particularly worried by 
this.

Nick

Nick Shelness
Independent Technology Consultant
Fellow - Differéntis Ltd.
Advisor - Oak Investment Partners

Contact Details
   Office Tel: +44 (0) 1828 640 632
   Office Fax: +44 (0) 1828 640 647
   Internet email: [email-masked]
   Short message: +44 7753 566460 or [email-masked]
   AOL instant messaging: NickShelness
   MSN instant messaging: [email-masked]
   Yahoo instant messaging: NickShelness
   Snail mail: The Old Mill, Meigle, Perthshire, PH12 8TJ, UK

From: Keith Moore <[email-masked]>
To: Marc Mutz <[email-masked]>
cc: Nick Shelness <[email-masked]>, [email-masked]
Subject: Re: RHijacked Addresses 
Date: Fri, 09 Aug 2002 09:34:27 -0400
Sender: [email-masked]

> I know Americans and Britains will shoot me for this suggestion, but I
> am of th opinion that digital signature infrastructures are the job of
> the government, just as passports and drivers licenses.

The US government is not trustworthy.  A government that will break its
own constitution at a whim will think nothing of issuing false credentials,
revoking certificates, and committing identity theft any time it is
convenient (of course they will claim it is in the national interest but
nobody will be able to verify such claims); and a government-controlled PKI 
would give them much more ability to do this than they currently have with 
paper documents. 

To: [email-masked]
Subject: Re: RHijacked Addresses
Sensitivity: 
From: Nick Shelness<[email-masked]>
Date: Fri, 9 Aug 2002 11:14:58 +0100
Sender: [email-masked]

Marc Mutz <[email-masked]> wrote on 08/09/2002 09:51:21:

> I know Americans and Britains will shoot me for this suggestion, but I 
> am of th opinion that digital signature infrastructures are the job of 
> the government, just as passports and drivers licenses.
> 
> That would blow up the "single organization" to span entire countries 
> and "pair-wise extension" to the rest of the world would become 
> manageable.

I think most Britons (and I am one) would have no problem with a 
government operated infrastructure (read registry). I doubt that 
American's would either subject to certain caveats. Hell, a registry 
already exists in both places for companies and driver's licences. The 
problem especially in the US is that it operates at state rather than 
national level, and getting the states to agree about anything is 
extremely difficult.

For my part, I have always thought that one might be able to employ the 
banking system as a PKI hierarchy. The Bank for International Settlement 
would hold the root. Reserve banks the next level, and commercial banks 
the level below that. Interestingly, such a structure is already in place 
for SWIFT and other international money transfers between commercial 
banks. Money laundering regulations have already established quite a high 
bar in many countries to opening a bank account, so I think that another 
level could be established. What's not clear is what would be in it for 
the banks. Clearly in such a systems, trust would depend upon one's view 
of a country's and/or bank's reliability. Certificates from Swiss based 
banks would carry higher trust than those from Nigerian banks, to pick on 
both countries for no particular reason.

Nick

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Nick Shelness <[email-masked]>, [email-masked]
Subject: Re: RHijacked Addresses
Date: Fri, 9 Aug 2002 10:51:21 +0200
Content-Description: clearsigned data
Sender: [email-masked]

On Tuesday 06 August 2002 19:50, Nick Shelness wrote:
<snip>
> We
> know how to employ signing certificates across a single organization,
> and how to extend them in a pair-wise fashion (via cross
> certificates) to a limited number of other organizations, but beyond
> that I would argue we're stuck. Other may disagree. I'd love to be
> wrong on this one.
<snip>

I know Americans and Britains will shoot me for this suggestion, but I 
am of th opinion that digital signature infrastructures are the job of 
the government, just as passports and drivers licenses.

That would blow up the "single organization" to span entire countries 
and "pair-wise extension" to the rest of the world would become 
manageable.

Marc

Mutig warf sich die kleine Überwachungskamera zwischen Täter und Opfer!
                                          --Rena Tangens / FoeBuD e.V.
- -- 
Marc Mutz <[email-masked]>

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Paul Hoffman / IMC <[email-masked]>, Jacob Palme <[email-masked]>
Subject: Re: RHijacked Addresses
Date: Fri, 9 Aug 2002 10:39:14 +0200
Cc: [email-masked]
Content-Description: clearsigned data
Sender: [email-masked]

On Monday 05 August 2002 18:30, Paul Hoffman / IMC wrote:
> At 8:49 PM +0200 8/4/02, Jacob Palme wrote:
> >I am not a security expert and do not understand why.
> >Possible causes could be:
> >
> >- Competing standards where unity is needed.
>
> Not true for email. S/MIME has been built into most widely-used MUAs
> for many years; almost no one uses it.

Oh, and is that any wonder? S/MIME combines the wonderful properties of 
non-interoperability, complexity, too vague standards and overly high 
costs. Of course, those properties are not independent of each other:

E.g. the high costs come from interop tests that _any_ company must 
beform for itself after choosing a profile.
Non-interoperability comes from the vague standards wording and the 
complexity.

There must be a reason why so many PKI projects fail to succeed. 

> >- Too complex and expensive standards.
>
> Complex, yes; expensive, no. But the complexity hasn't prevented them
> from being widely deployed with quite good interoperability.
<snip>

If you are talking about S/MIME, I fail to see where "good 
interoperability" lies. I think of S/MIME as being like XML: if you 
have two apps that claim to understand XML (S/MIME), it will guarantee 
you nothing. You need them to use the same DTD (profile) to do anything 
useful with it.

Marc

Mutig warf sich die kleine Überwachungskamera zwischen Täter und Opfer!
                                          --Rena Tangens / FoeBuD e.V.
- -- 
Marc Mutz <[email-masked]>

Date: Tue, 06 Aug 2002 20:41:47 -0700 (PDT)
From: [email-masked]
Subject: RE: RHijacked Addresses
To: Nick Shelness <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > Why are so few people using either of these security
> > methods, when they at the same time complain of the
> > lack of security in e-mail.

> It would be trivial for me to turn on S/MIME signing in my MUA, and as the
> signing certificate travels with the signed mail item, there is no
> receiver certificate look-up required. So far so good. The problem is with
> the certificate. At what price do I acquire one, and how confident can a
> recipient be of its veracity. I can create my own self-signed root
> certificate at no cost (this approach works fine for SSL/TSL based
> encryption), but any old forger could also do that. If I physically handed
> a correspondent my self-signed root certificate in a face-to-face meeting,
> then we'd be all set, but how scalable would this be? The answer is not
> very. I could acquire a certificate from a trusted third party (assuming
> my correspondents and I could agree on one), but how will this third party
> (or their delegate) insure the veracity of my claim. They will have to
> operate very stringent controls and at a commensurate cost. So we're
> stuck. We know how to employ signing certificates across a single
> organization, and how to extend them in a pair-wise fashion (via cross
> certificates) to a limited number of other organizations, but beyond that
> I would argue we're stuck. Other may disagree. I'd love to be wrong on
> this one.

Nick, you know darned well you're square on target with this assessment.
Indeed, I've heard it argued that this is why our entire approach to
public key infrastructure needs to be rethought.

				Ned

To: [email-masked]
Subject: RE: RHijacked Addresses
Sensitivity: 
From: Nick Shelness<[email-masked]>
Date: Tue, 6 Aug 2002 18:50:35 +0100
Sender: [email-masked]

Jacob Palme <[email-masked]> wrote on 08/06/2002 17:40:17

> Why are so few people using either of these security
> methods, when they at the same time complain of the
> lack of security in e-mail.

It would be trivial for me to turn on S/MIME signing in my MUA, and as the 
signing certificate travels with the signed mail item, there is no 
receiver certificate look-up required. So far so good. The problem is with 
the certificate. At what price do I acquire one, and how confident can a 
recipient be of its veracity. I can create my own self-signed root 
certificate at no cost (this approach works fine for SSL/TSL based 
encryption), but any old forger could also do that. If I physically handed 
a correspondent my self-signed root certificate in a face-to-face meeting, 
then we'd be all set, but how scalable would this be? The answer is not 
very. I could acquire a certificate from a trusted third party (assuming 
my correspondents and I could agree on one), but how will this third party 
(or their delegate) insure the veracity of my claim. They will have to 
operate very stringent controls and at a commensurate cost. So we're 
stuck. We know how to employ signing certificates across a single 
organization, and how to extend them in a pair-wise fashion (via cross 
certificates) to a limited number of other organizations, but beyond that 
I would argue we're stuck. Other may disagree. I'd love to be wrong on 
this one.

Nick

Nick Shelness
Independent Technology Consultant
Fellow - Differentis Ltd.
Advisor - Oak Investment Partners

Contact Details
   Office Tel: +44 (0) 1828 640 632
   Office Fax: +44 (0) 1828 640 647
   Internet email: [email-masked]
   Short message: +44 7753 566460 or [email-masked]
   AOL instant messaging: NickShelness
   MSN instant messaging: [email-masked]
   Yahoo instant messaging: NickShelness
   Snail mail: The Old Mill, Meigle, Perthshire, PH12 8TJ, UK

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: [email-masked]
Subject: Re: RHijacked Addresses 
Date: Tue, 06 Aug 2002 13:49:03 -0400
Sender: [email-masked]

> Perhaps SMTP relayers should be instructed to check
> if messages are using PGP or S/MINE, and refuse to
> handle them otherwise? Like SMTP relayers five years
> ago started refusing to relay mail. That was *very*
> effective!

it was very effective at disrupting mail service for mobile users.  
it doesn't seem to have done much to solve the spam problem.

Date: Tue, 6 Aug 2002 18:40:17 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: RE: RHijacked Addresses
Sender: [email-masked]

At 12:56 -0700 02-08-05, Dan Wing wrote:
>As an implementor, there isn't a simple choice of which to implement --
>you have to implement both to cover cases of customers that prefer
>one over the other.

Is there a co-working problem between S/MINE and PGP?
I guess people can send messages unsing either security
method, and the receiving mailer should then be able
to use the security protocol chosen by the sender?

Why are so few people using either of these security
methods, when they at the same time complain of the
lack of security in e-mail.

This discussion started with a person complaining that
a lot of spams and/or virus messages had been sent
with him as purported sender. Such spamming can only
be avoided if everyone used secure e-mail, and if
everyone refused to handle incoming e-mail which was
not secure.

Perhaps SMTP relayers should be instructed to check
if messages are using PGP or S/MINE, and refuse to
handle them otherwise? Like SMTP relayers five years
ago started refusing to relay mail. That was *very*
effective!
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: Re: RHijacked Addresses 
Date: Mon, 05 Aug 2002 16:40:46 -0400
Sender: [email-masked]

I don't think signing mail in the way that S/MIME or PGP does would
solve the spam or virus problem, at least not for most of us.  

I get lots of perfectly valid mail from people I don't know, and 
I don't think that's unusual.  It's no less valid for not being signed,
and having a signature would not do anything to convince me (or my
agent) of its validity.  Even if we managed to require that all mail
be signed, spammers would create fake identities and sign those.

We might could get PGP or S/MIME widely deployed but we're nowhere
close to having the necessary infrastructure to make everyone use a
real identity in email - nor do we know how to make it trustworthy,
nor how to deal with the resulting privacy concerns. 

Keith

Date: Mon, 5 Aug 2002 13:19:23 -0700
To: "Dan Wing" <[email-masked]>, "Jacob Palme" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: RHijacked Addresses
Cc: <[email-masked]>
Sender: [email-masked]

At 12:56 PM -0700 8/5/02, Dan Wing wrote:
>  > At 8:49 PM +0200 8/4/02, Jacob Palme wrote:
>>  >I am not a security expert and do not understand why.
>>  >Possible causes could be:
>>  >
>>  >- Competing standards where unity is needed.
>>
>>  Not true for email. S/MIME has been built into most widely-used MUAs
>>  for many years; almost no one uses it.
>
>Not to be confused with PGP, the Other Standard.  Which isn't built
>into many MUAs but does have plugins for nearly all major MUAs.

If a user needs a plugin, it is not easily available.

>   And
>is used by some people -- it's certainly easier to use with a group
>of people than S/MIME.

Among groups of technically-savvy people, yes. Among typical users, 
no. Pre-trusted roots are much simpler to use than webs of trust. 
They are, of course, much less safe.

>As an implementor, there isn't a simple choice of which to implement --
>you have to implement both to cover cases of customers that prefer
>one over the other.

So few users have any preference that this becomes moot.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Dan Wing" <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, "Jacob Palme" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RHijacked Addresses
Date: Mon, 5 Aug 2002 12:56:15 -0700
Importance: Normal
Sender: [email-masked]

> At 8:49 PM +0200 8/4/02, Jacob Palme wrote:
> >I am not a security expert and do not understand why.
> >Possible causes could be:
> >
> >- Competing standards where unity is needed.
> 
> Not true for email. S/MIME has been built into most widely-used MUAs 
> for many years; almost no one uses it.

Not to be confused with PGP, the Other Standard.  Which isn't built
into many MUAs but does have plugins for nearly all major MUAs.  And
is used by some people -- it's certainly easier to use with a group
of people than S/MIME.

As an implementor, there isn't a simple choice of which to implement --
you have to implement both to cover cases of customers that prefer
one over the other.

-d

Date: Mon, 05 Aug 2002 13:20:41 -0500
From: "Eric A. Hall" <[email-masked]>
To: Jacob Palme <[email-masked]>
CC: [email-masked]
Subject: Re: RHijacked Addresses
Sender: [email-masked]

on 8/4/2002 1:49 PM Jacob Palme wrote:

> It is very surprising and disappointing that application
> layer security standards are not successful.

> I am not a security expert and do not understand why.

Lack of transparency. If it is more effort (measurable in multiple
dimensions) to make something secure, a large number of people simply
won't do it. Stuff has to be designed and deployed as secure in the
default for everybody to use it. Since SMTP (as a topical example) wasn't
designed with this objective in mind -- and since making it secure
requires significant amounts of external effort in terms of getting a
cert, configuring the product, integrating accounts, and so forth -- it is
unlikely to ever be used in the secure form by all of the people all of
the time.

Secondarily -- but no less important -- there isn't an effective
infrastructure for building these kinds of services upon. One of my
not-so-hidden agenda motives for the LDAP-WHOIS work is to facilitate the
deployment of an Internet directory instrastructure that provides public
hooks into administrative resource domains, and this is achieved by
providing standardized schema, naming, filters, delegation paths, and so
forth, and doing so for every unique administrative resource on the
Internet. Of course, the directory will have to become the primary point
of focus at some point, or else the directory itself is just additional
baggage and therefore represents additional cost to the operators. But if
the directory becomes the default base, then the layered services can
inherit the attributes and features offered with no additional costs.

Paul's point about trust is also on target. I'm not sure that can be
solved in the default condition, however. No service that *requires*
security can rightfully make use of implicit trust defined by external
parties, ever. But if that's true, then having to manage all trust
relationships will also mean that security is an ongoing cost item, and
therefore will never be ubiquitous. Hard problem, that.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Mon, 5 Aug 2002 09:30:50 -0700
To: Jacob Palme <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: RHijacked Addresses
Cc: [email-masked]
Sender: [email-masked]

At 8:49 PM +0200 8/4/02, Jacob Palme wrote:
>I am not a security expert and do not understand why.
>Possible causes could be:
>
>- Competing standards where unity is needed.

Not true for email. S/MIME has been built into most widely-used MUAs 
for many years; almost no one uses it.

>- Too complex and expensive standards.

Complex, yes; expensive, no. But the complexity hasn't prevented them 
from being widely deployed with quite good interoperability.

>- Maybe existing standards do not solve the right problem.
>   (For example protection of body, when protection of
>   heading is more needed.)

If this were a real problem, it could have been solved years ago with 
encapsulation. This is probably a red herring.

>- Difficulty of establish a trusted key distribution
>   scheme giving everyone, not only a few large servers,
>   access to keys.

Close, but not quite, I think. Key distribution is easy: trust 
distribution has so far been impossible. That is, if you and I have 
certificates that lead to different roots, how do you and I establish 
trust?

>- Viruses and worms threaten keys stored in personal
>   computers, and smart cards (which possibly might
>   solve this problem) has not been successful because
>   of the extra cost or lack of standards.

This has not been a problem yet, but it certainly will be when/if 
trusted email becomes prevalent. It is pretty trivial to find the 
private keys on a PC, and probably 95% of them are easily susceptible 
to dictionary attacks.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sun, 4 Aug 2002 20:49:04 +0200
To: Paul Hoffman / IMC <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: RHijacked Addresses
Cc: [email-masked]
Sender: [email-masked]

At 12:07 -0700 02-08-03, Paul Hoffman / IMC wrote:
>Seven years ago, I would have agreed with you. Having seen 
>the repeated failure of the apps folks and the security 
>folks to get even reasonably close to this goal, I'm very 
>skeptical. Having said that, I would bow deeply to anyone 
>who designs and deploys such a system.

It is very surprising and disappointing that application
layer security standards are not successful. This is
related to another area, micropayments, which also
has not been successful.

I am not a security expert and do not understand why.
Possible causes could be:

- Competing standards where unity is needed.
- Too complex and expensive standards.
- Maybe existing standards do not solve the right problem.
   (For example protection of body, when protection of
   heading is more needed.)
- Difficulty of establish a trusted key distribution
   scheme giving everyone, not only a few large servers,
   access to keys.
- Viruses and worms threaten keys stored in personal
   computers, and smart cards (which possibly might
   solve this problem) has not been successful because
   of the extra cost or lack of standards.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sat, 3 Aug 2002 20:25:21 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: RHijacked Addresses
Sender: [email-masked]

At 17:44 +0100 02-08-03, Philip Hazel wrote:
>However, in the world of email, people seem to be a lot more worried
>about forgeries. Is this because email is cheap, leading to
>proportionately more forgeries, or because it's more likely to be
>destructive (viruses, worms), or what?
></aside>

Communication via computers is more anonymous, and the
cost of making forgeries is much lower. A forger has
a much lower risk of exposure or prosecution on the net
than in the non-net world.

This is the same reason why crime rates are much higher
in large cities than in small cities and rural communities.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sat, 3 Aug 2002 12:07:00 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: RHijacked Addresses
Sender: [email-masked]

At 12:45 PM -0500 8/3/02, Eric A. Hall wrote:
>It's because it should be reasonably resolvable with computers, without
>requiring that everybody become an expert in security and mail routing
>services.

Seven years ago, I would have agreed with you. Having seen the 
repeated failure of the apps folks and the security folks to get even 
reasonably close to this goal, I'm very skeptical. Having said that, 
I would bow deeply to anyone who designs and deploys such a system.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sat, 03 Aug 2002 12:45:20 -0500
From: "Eric A. Hall" <[email-masked]>
To: Philip Hazel <[email-masked]>
CC: [email-masked]
Subject: Re: RHijacked Addresses
Sender: [email-masked]

on 8/3/2002 11:44 AM Philip Hazel wrote:
> However, in the world of email, people seem to be a lot more worried
> about forgeries. Is this because email is cheap, leading to
> proportionately more forgeries, or because it's more likely to be
> destructive (viruses, worms), or what?

It's because it should be reasonably resolvable with computers, without
requiring that everybody become an expert in security and mail routing
services.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Sat, 3 Aug 2002 17:44:43 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: [email-masked]
Subject: Re: RHijacked Addresses
Sender: [email-masked]

On Fri, 2 Aug 2002, Eric A. Hall wrote:

> If that were the problem at hand, this might even be a reasonable point.
> The problem at hand -- the one that started this thread -- is forgery, and
> the lack of protection against it.

<aside>
It is interesting that this seems to be so much worse with email than
with paper mail. Or at least, that seems to be the perception.

In the world of paper mail, very few people go to the trouble of
checking that what they receive is genuine. At least, most of the time.
I get letters from my bank signed "squiggle", and as long as they seem
to be saying reasonable things, I trust them. If I received a sudden
demand for a large sum of money, I'd question it, of course.

I think that a lot of life is like this. It would waste a huge amount of
time if everything had to be verified or validated. Naturally, there are
forgeries from time to time, but society seems able to tolerate them,
and the vast majority of paper mail is genuine.

However, in the world of email, people seem to be a lot more worried
about forgeries. Is this because email is cheap, leading to
proportionately more forgeries, or because it's more likely to be
destructive (viruses, worms), or what?
</aside>

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Fri, 02 Aug 2002 19:46:01 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: RHijacked Addresses
Sender: [email-masked]

on 8/2/2002 5:59 PM Keith Moore wrote:
>>"Both problems" are forged senders,
> 
> If signed mail were the norm, viruses would send out signed mail.
> If they needed to get a pass phrase from the human user, they would
> do that.  

If that were the problem at hand, this might even be a reasonable point.
The problem at hand -- the one that started this thread -- is forgery, and
the lack of protection against it.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: RHijacked Addresses 
Date: Fri, 02 Aug 2002 21:08:45 -0400
Sender: [email-masked]

> If that were the problem at hand, this might even be a reasonable point.
> The problem at hand -- the one that started this thread -- is forgery, and
> the lack of protection against it.

the original message was about forged viruses.  
though I'll admit that forged non-viruses also cause problems. 

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: [email-masked]
Subject: Re: RHijacked Addresses 
Date: Fri, 02 Aug 2002 18:59:15 -0400
Sender: [email-masked]

> "Both problems" are forged senders,

If signed mail were the norm, viruses would send out signed mail.
If they needed to get a pass phrase from the human user, they would
do that.  

Date: Fri, 02 Aug 2002 17:29:52 -0500
From: "Eric A. Hall" <[email-masked]>
CC: [email-masked]
Subject: Re: RHijacked Addresses
Sender: [email-masked]

on 8/2/2002 1:41 PM Paul Hoffman / IMC wrote:
> At 12:39 PM -0500 8/2/02, Eric A. Hall wrote:
> 
>> > authentication wouldn't solve the problem either, as long as the
>>> systems that send the mail are so easily compromised.
>>
>>It would go a long way towards solving both problems.
> 
> How? Many of the copies of Klez that I am *still* getting are from 
> MTAs with whom I have had previous experience as sending OK messages.

I don't understand the argument you are making here.

"Both problems" are forged senders, either from worms that use a fake
reverse-path, or from malicious intent. Klez is an example of the former,
and the message that started this thread is ostensibly an example of the
latter (minus any additional substantive evidence).

Some form of mechanism for restricting the source(s) of mail to authorized
senders would defeat both of those problems, when it was used. It would
also defeat forged reverse-path addresses in spam, when it was used.

It would not defeat anything when it was not used. It would not stop all
worms and all spam in any event. It would "go a long way" towards solving
the problems, however.

What of this are you disagreeing with?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Fri, 2 Aug 2002 11:41:40 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: RHijacked Addresses
Sender: [email-masked]

At 12:39 PM -0500 8/2/02, Eric A. Hall wrote:
>  > authentication wouldn't solve the problem either, as long as the
>>  systems that send the mail are so easily compromised.
>
>It would go a long way towards solving both problems.

How? Many of the copies of Klez that I am *still* getting are from 
MTAs with whom I have had previous experience as sending OK messages.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: RHijacked Addresses 
Date: Fri, 02 Aug 2002 13:55:49 -0400
Sender: [email-masked]

> > authentication wouldn't solve the problem either, as long as the
> > systems that send the mail are so easily compromised.
> 
> It would go a long way towards solving both problems. Moreover, it's a
> change that we can affect, rather than pine for.

"What are you looking for?"
"I lost my keys!"
"Where did you last see them?"
"In my house." 
"Then why are you looking for them outside?"
"Because the light is better out here."

Date: Fri, 02 Aug 2002 12:39:21 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: RHijacked Addresses
Sender: [email-masked]

on 8/2/2002 12:35 PM Keith Moore wrote:

> the forgery is not nearly as big a problem as the vulnerability of so
> many systems to viruses.

Agree completely

> authentication wouldn't solve the problem either, as long as the
> systems that send the mail are so easily compromised.

It would go a long way towards solving both problems. Moreover, it's a
change that we can affect, rather than pine for.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: RHijacked Addresses 
Date: Fri, 02 Aug 2002 13:35:00 -0400
Sender: [email-masked]

> > In other words, the blame is squarely with Microsoft, and they
> > should be held financially and personally liable for the harm
> > that they have caused.
> 
> quoting from the original message:
> 
>  | They have even gone so far as to create aliases that are not ours.
> 
> None of the large-scale public worms invent new localparts. This appears,
> instead, to be a simple matter of forgery.

the forgery is not nearly as big a problem as the vulnerability of so
many systems to viruses.  authentication wouldn't solve the problem either,
as long as the systems that send the mail are so easily compromised.

From: "Gary Feldman" <[email-masked]>
To: "IETF mailing list on MIME and e-mail" <[email-masked]>
Subject: Re: RHijacked Addresses
Date: Fri, 2 Aug 2002 07:37:03 -0400
Sender: [email-masked]

>From: "Jacob Palme" <[email-masked]>
>Sent: Wednesday, July 31, 2002 11:49 AM

> This message, which I got recently, shows how some people
> react to what is happening around us. What is our responsibilities
> as standards developers for allowing this to happen?

If, as a newcomer to this list, I may be so bold as to respond directly
to this question, my response is that there are definite responsibilities.

One of the concepts used in formal software methodologies is that of
a standard list of quality factors.  My best example is the FURPS+
model, introduced by HP some years ago.  FURPS stands for
Functionality, Usability, Reliability, Performance, and Scalability
(with the plus being added later since this list is obviously incomplete).
The principle is that any software development project must, in its
project documentation, address each of these issues, even if at times
the correct comment is "Not relevant."

As I start learning the IETF process, the only similar criterion that
stands out as being required is "implementability,"  i.e. it is a 
requirement that implementations exist for protocol standards to
advance through the process.

I believe it is an obligation for standards developers and standards
bodies to have a reasonably robust list of such criteria.  Security is
surely one of those criteria, and issues such as authentication, 
avoiding denial of service attacks, etc.  are standard subitems
of that criterion.  

This certainly wasn't the case in the original 821/822.  Indeed, some
may say that the ability to forge is a feature.  However, for future
work, I wonder if it wouldn't make sense for the standards process
to say that "Security" is a required section for all protocol standards
documents to advance in the process.

Gary

Date: Thu, 01 Aug 2002 12:05:32 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: RHijacked Addresses
Sender: [email-masked]

on 8/1/2002 8:42 AM Keith Moore wrote:

> In other words, the blame is squarely with Microsoft, and they
> should be held financially and personally liable for the harm 
> that they have caused.

quoting from the original message:

 | They have even gone so far as to create aliases that are not ours.

None of the large-scale public worms invent new localparts. This appears,
instead, to be a simple matter of forgery.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: RHijacked Addresses 
Date: Thu, 01 Aug 2002 09:42:41 -0400
Sender: [email-masked]

> This message, which I got recently, shows how some people
> react to what is happening around us. What is our responsibilities
> as standards developers for allowing this to happen?

we attempted to deal with the virus problem in MIME content-types
by requiring each new content-type to have documented security
considerations.    unfortunately one particular OS vendor decided
to distribute mail reading software that ignored not only the
security risks of presenting arbitrary types but the entire 
content-typing system.

In other words, the blame is squarely with Microsoft, and they
should be held financially and personally liable for the harm 
that they have caused.

Keith

From: [email-masked] (Juergen Helbing)
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Subject: Re: RHijacked Addresses
Date: Thu, 01 Aug 2002 12:39:20 GMT
Sender: [email-masked]

On Wed, 31 Jul 2002 17:49:17 +0200, you wrote:

>This message, which I got recently, shows how some people
>react to what is happening around us. What is our responsibilities
>as standards developers for allowing this to happen?

Waiting for IPv6 and personal home mail servers which accept eMail
only from trusted other IPv6 servers.

>At 00:01 -0700 02-07-31, Adventive Editor wrote:

>>I own a well traveled web site. Over the course of the last few
>>months, someone has been sending virus laden emails using our email
>>address. They have even gone so far as to create aliases that are
>>not ours. The problem is neither our computers, not the mail server.

My mail-contact addresses which are visible on my websites are also
flooded with viruses - and these addresses are used to spam the world.
Some spammers are even attaching _my_ _webpages_ to their spam/trojans
- and they are using my mail-address to fool the users.

The advertising industry uses billions of dollars to find customers
and spam them with all type of media. We have _no_ chance against
them.

As a software developer I'm meanwhile thinking about automatic
"eMail-Handshake" to make sure that a sender is "authorized" to send
me eMail - and rejected already on eMail server level. This requires a
database of "permitted" senders on the receiving SMTP server. 

But because OE users are not even ready to use the integrated security
features but insist on "quick view and execute" features we have no
chance over all.

A first approach might be to introduce a "general mail reader
function" called:   "Reject such Spam" - which retransmits a message
to the mailer. But the design for such a beast is hard - and
ungraceful due to malfunctions.

I am afraid that seperating "private and public identities" is the
only solution in the long run. (And it is also cheap :-)

-- 
Juergen
------------
www.yenc.org

Date: Thu, 1 Aug 2002 15:18:08 +0530
From: Arnt Gulbrandsen <[email-masked]>
To: Jacob Palme <[email-masked]>
Cc: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: RHijacked Addresses
Sender: [email-masked]

Jacob Palme <[email-masked]>
> This message, which I got recently, shows how some people
> react to what is happening around us. What is our responsibilities
> as standards developers for allowing this to happen?

I note that your message is unsigned. I note, with some sadness, that so
is mine.

--Arnt

Date: Wed, 31 Jul 2002 17:49:17 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: RHijacked Addresses
Sender: [email-masked]

This message, which I got recently, shows how some people
react to what is happening around us. What is our responsibilities
as standards developers for allowing this to happen?

At 00:01 -0700 02-07-31, Adventive Editor wrote:
>I've a question I hope you can help find an answer to.
>I own a well traveled web site. Over the course of the last few
>months, someone has been sending virus laden emails using our email
>address. They have even gone so far as to create aliases that are
>not ours. The problem is neither our computers, not the mail server.
>Our hosting company has checked everything on their end, as we have
>also checked everything on our end. Someone knows a way of sending
>emails that appear to have originated from our server.
>
>It would be an understatement to say these hoax emails have damaged
>our business, integrity, income, and professionalism. They have even
>dashed our hopes of creating a newsletter for our visitors.
>
>Now the question. Are there detectives dedicated to investigating
>this type of Internet problem? Also, how is it that a hacker can use
>the email address belonging to someone else's domain without access
>to their email hub? What can be done to prevent this practice?
>
>I handle all my mail in a rather odd manner. All mail is forwarded
>to an AOL account for action. All responses to inquiries are
>answered from the AOL account. Absolutely none are generated from
>our ISP mail address. In 4+ years, we haven't used it once. That's
>the reason I know with absolute certainty someone else is using our
>address. This plus the false aliases they use.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/