Subject: Implementing RFC 1864 (Content-MD5:)

From: Martin Hamilton <[email-masked]>
Date: Tue, 03 Feb 1998 10:28:09 +0000

-----BEGIN PGP SIGNED MESSAGE-----

I've just been hacking (yep, that kind of "implementing" - remember to
send your unsubscription request to ietf-request!) support for this
into a few things, and thought I'd read the RFC to check that I was
doing it right.  On the fourth or fifth read, I noticed this
paragraph...

   The Content-MD5 field is generated by only an originating user agent.
   Message relays and gateways are expressly forbidden from generating a
   Content-MD5 field.

I'd like the text of this paragraph to read more like...

   The Content-MD5 field should be generated when a message which has 
   no Content-MD5 value already is encountered.  Ideally this would
   always be done by the originating mail user agent, but the MIC is
   still useful when generated by an intermediate relay or gateway.

Before people start jumping up and down and throwing things, I should 
explain my rationale for suggesting this :-

  * A hash like Content-MD5 (or -SHA1, or ...) is no substitute for
     a real crypto based digital signature system

  * If the digest supplied with the message and one calculated anew
     disagree, this just tells you that something happened to one or
     both of them - not what, or where.

  * Hackers don't seem to be in a big hurry to add support for this.
     OK, so MH has it, but that goes without saying :-)

  * There are a class of situations where it would be useful to have
     Content-MD5: (or something similar) headers stamped on most/all
     the messages that go through a hub.

On that last point, consider...

  * mail loops, same body (possibly unrealistic example ?  headers
     tend to accumulate in the message "body" - does protect against
     brain dead gateways from <certain vendors> though ?)

  * multiple submissions (e.g. broken SMTP clients in WWW browsers)

  * identical messages sent to lots of recipients individually
     (typically spam or Dilbert style "morale boosting" messages from
     a brain dead manager ?!)

If you make the "mail system" itself calculate the MIC, e.g. inside
something like sendmail or Exim, this neatly gets you around the
privacy problems associated with postmasters poking around in people's
mail to see if it's spam.  Not a long term solution to the spam
problem (spammers will no doubt immediately retaliate by including the
MD5 of the current date/ time in the body of each message :-), but it
does raise the entry level barrier for spamming a little higher -
which can't be a bad thing.

So, what do people think about this ?  Re-use Content-MD5: or create a
new header specifically for relays to add - or is this a stupid idea
which should never see the light of day ?  (Too late!)

Ciao!

Martin

PS It might also be interesting to think about something like :-
hmyeJl.op46Xs.IOjJpl.ISKg==.bodyparts.rbl.net

---

From: Nathaniel Borenstein <[email-masked]>
Date: Tue, 3 Feb 1998 08:41:01 -0500 (EST)

Excerpts from bulk.interesting.mildly: 3-Feb-98 Implementing RFC 1864
(Cont.. Martin [email-masked] (3140)

> On the fourth or fifth read, I noticed this paragraph...

>    still useful when generated by an intermediate relay or gateway.

I see the need you're trying to fill here, and I sympathize, but I'm not
particularly pleased with overloading the Content-MD5 field in this way.
 If we follow your suggestion, then we won't be able to tell the
difference between the situation you describe (MD5 generation at a mail
relay) and the originally-envisioned situation (MD5 generation by the
composing user's MUA).

If it's desirable to be able to add MD5 hashes at relays -- and I
suspect you are right, it probably is quite valuable -- then I'd prefer
to see it done in such a way that these two situations can be
distinguished.  I can think of two ways to go about this that are
backwards-compatible with RFC 1864:

1.  Add a new field, Content-Relay-MD5, for the purpose you described,
and use it *instead* of Content-MD5 where appropriate.

or

2.  Add a new field, Content-MD5-Origination, describing the context in
which the Content-MD5 was added, allowing interested parties to tell
whether it was applied at composition time or mail relay time.

Either of these would require a new RFC, but a pretty short and simple
one....  -- Nathaniel
--------
Imagination was given to man to compensate him for what he is not;
a sense of humor to console him for what he is.  -- Francis Bacon

Nathaniel Borenstein <[email-masked]>          |  FAQ & PGP key:
Chief Scientist, First Virtual Holdings    |  [email-masked]

---

From: Martin Hamilton <[email-masked]>
Date: Thu, 05 Feb 1998 12:11:52 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Nathaniel Borenstein writes:

| 1.  Add a new field, Content-Relay-MD5, for the purpose you described,
| and use it *instead* of Content-MD5 where appropriate.
| 
| or
| 
| 2.  Add a new field, Content-MD5-Origination, describing the context in
| which the Content-MD5 was added, allowing interested parties to tell
| whether it was applied at composition time or mail relay time.

How about this... ?  (Picking up on 2.)

  Mail relays MAY add a Content-MD5: header to a message which does
  not already contain one.  A relay which does this MUST also add a
  Content-MD5-Origin: header listing its domain name or Internet
  Protocol address.  IP addresses MUST be delimited by square
  brackets.  For example :-

    Content-MD5-Origin: mescaline.gnu.org

  or

    Content-MD5-Origin: [158.121.106.21]

  as appropriate .  Machines which are known by multiple domain names
  and/or IP addresses MAY use an arbitrarily chosen one, though if
  there is a canonical domain name this would be the best choice for
  the value of the Content-MD5-Origin: header.

  If a message has a Content-MD5: header but no accompanying
  Content-MD5-Origin:, the value associated with the Content-MD5:
  header will be assumed to have been generated by the originating
  mail user agent.

I think this means no change to existing implementations, since ...

  * we don't change the syntax of the Content-MD5: header
  * we don't require that an extra header be added by
      originating user agents

It also has the knock-on bonus that...

  * we stimulate interest in (and possibly a few more actual
      implementations of :-) Content-MD5: by flooding the net
      with Content-MD5: headers (!)

This intentionally leaves aside the interesting issue of what mail
relays should do if/when they notice that a supplied value of
Content-MD5: differs from one they calculate themselves.  If a
supplied Content-MD5: value doesn't match the one calculated by
whoever is on the receiving end, it should in theory be possible to
use the Received: headers (assuming we're talking about a mail message
here) to zoom in on a subset of the relaying systems as candidates to
win the bozo-who-munged-the-message booby prize.

[Now back to our to our scheduled programme of rolling Postel-bashing,
Me Toos, and unsubscription requests ;-]

Ciao!

Martin

PS See below for ObHack :-) ... now on to sendmail!

- ------- Forwarded Message

From:    Martin Hamilton <[email-masked]>
Subject: Re: [EXIM] Anti Spam 
To:      [email-masked]
Date:    Thu, 05 Feb 1998 10:45:47 GMT

I said:

| Since most mail systems seem to store the message headers and body in
| separate files, it should be pretty easy to write or adapt a bit of
| code which wraps up the MD5 library routine and is generally usable.

& it was - <URL:http://www.net.lut.ac.uk/~martin/antispam/exim-hacks/>

This is an unofficial hack to the Exim 1.82 source to add support for
generating Content-MD5: headers for incoming messages which don't have
them already.  Exim info is at <URL:http://www.exim.org/>, in case you
didn't have it already.

It uses the public domain MD5 implementation by Colin Plumb, and the
Base64 digest generation code from mpack/metamail.  If you don't know
what to do with the files in this directory, tough!  Wait for a fully
operational version which might appear in the main Exim code base at
some point in the future :-)

It seems to work OK for me on Linux and SunOS 4.1.4 - but as this is a
first attempt you'd have to be stupid, crazy, or both to run it on any
production services.  Don't say you haven't been warned!

Martin
@mrrl.lut.ac.uk

- ------- End of Forwarded Message