Subject: Re: Implementing RFC 1864 (Content-MD5:)

From: [email-masked]
Date: Wed, 4 Feb 1998 00:52:03 +0900

On your comment below especially where you mention leaving it to the "
     "mail system" as a way to cut spanning, I think your trying to "kill 
     two stones with one bird" and I don't mean that the other way around.
     
     Spamming is, and always will be... just like stones... you can't 
     really kill them.  And to think that the way to stifle them is to get 
     every type of mail system in the world on the same version to 
     calculate the proper MIC, well, I personally think you'd have an 
     easier job of getting Microsoft & NetScape to kiss & make up shaking 
     hands together.  Then when ever a new release comes out, half of the "
     e-mail makers" will fold up because they can't come out with the mods 
     fast enough and the rest of the world will be wondering who they can 
     send their newest version to.
     
     And that doesn't even begin to consider all of the possible security 
     problems that bugs in each vendor's rendition of the "new E-mail 
     standard" will create.  Just look where we've come from 5 years ago, 
     last year and compare that to the challenges ahead.
     
     Something application independent like a black box between the 
     internet and each local system will probably provide the best 
     performance.  Such a box must have an intelligent firmware capability 
     to be upgraded, but it cannot compromise security by allowing such 
     firmware to be downloaded by anything other than original code, not 
     hacked up security hole versions.
     
     FWIW
     
     Walter Benton
     NWS Project Manager
     Memorex Telex Japan 
     
>>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.

___________________________________ 返信 _______________________________________
件名: Implementing RFC 1864 (Content-MD5:)
送信者:  Martin Hamilton <[email-masked]> at &NWS-Internet
日付:    98/02/03 19:28

-----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

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
     
iQCVAwUBNNbxNtZdpXZXTSjhAQG87gQAlGyJnPpiVYPPEE7BdfkxSP4sGGeAOTpm UO2f5
M3Yx+9G+AEleZ0taSKqz9QvA0POxsd6QpMlAZJ+4l+qHiruzS8A6oSFA7U/ C7MqCOQNN7
qVRBGI+ydkU5vDvPVmBfLMV9ypntk75PdL0GNip56v0lo5Zw+xF9gD lePT0PsTWHg=
=eRRH
-----END PGP SIGNATURE-----

---

From: Martin Hamilton <[email-masked]>
Date: Sat, 21 Feb 1998 17:30:58 +0000

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

[email-masked] writes:

| Spamming is, and always will be... just like stones... you can't 
| really kill them.  And to think that the way to stifle them is to get 
| every type of mail system in the world on the same version to 
| calculate the proper MIC, well, I personally think you'd have an 
| easier job of getting Microsoft & NetScape to kiss & make up shaking 
| hands together.  Then when ever a new release comes out, half of the "
| e-mail makers" will fold up because they can't come out with the mods 
| fast enough and the rest of the world will be wondering who they can 
| send their newest version to.

Hi Walter - I'm sure you're right in the general case.  In this
particular case, however, all it takes is convincing the relatively
small number of hackers responsible for the mail hub software most of
us use to put this stuff into their code base.

As previously noted - it's not only useful for protecting against
spam.  There are an awful lot of loops and broken gateways in real
mail systems Out There.  Deploying this system will significantly
improve the Internet's ability to route around these problems (and
possibly some of the spam too :-).  So what if it takes a year or two
to be widely deployed ?  The long term benefits are enormous...

[ I said: ]

| >>If you make the "mail system" itself calculate the MIC, e.g. inside somethi
| ng 
| >>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.

Ciao!

Martin

PS ObHack :-

From: Martin Hamilton <[email-masked]>
Subject: PATCH: Content-MD5 generation
Newsgroups: comp.mail.sendmail
Date: 21 Feb 1998 17:13:03 +0000
Organization: c/o Loughborough University, UK

 From...
<URL:http://www.net.lut.ac.uk/~martin/antispam/sendmail-hacks/README>
This is an unofficial hack to the sendmail 8.8.8 source to add support
for generating Content-MD5: headers for incoming messages which don't
have them already.  Sendmail info is at <URL:http://www.sendmail.org/>,
in case you didn't have it already.  When sendmail encounters a message
which doesn't have a Content-MD5: header, it tries to generate one and
also adds a new header, Content-MD5-Origin:, with its hostname as the
value.  This will be documented in an Internet Draft soon...

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 sendmail code base
at some point in the future :-)

It seems to work OK for me on Linux and Solaris 2.6 - 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
@net.lut.ac.uk