Nigel Metheringham writes:
| Time to look at the RFC. We could of course always generate the hash - it
| wouldn't be that much work, and then maybe inject the value into the
| Received header - at least make it a variable within exim.
Before anyone else says it :-) I was looking at the RFC again, and
noticed the warning that mail systems should never ever generate
Content-MD5: headers themselves!
To answer Dom @ Demon ...
I was thinking that only mail which is being injected via SMTP from a
"remote" host would count, so if you had a bulk mailer program which
runs on the mail hub and speaks SMTP to localhost you would be OK. The
definition of a remote host would have to be admin tweakable, needless
to say, to suit indidivual situations. This way the code for the
mooted restriction would take effect as the message to be passed on by
the list processor first arrived, rather than as the deliveries were
being made. I'm not sure how practical that is, though.
Alan's procmail hack is really neat - exactly what I was originally
planning to do for just myself :-)
General comment - I think this stuff really does want to be built in
to the mail hub software if it's going to get anywhere. Anything which
has to be fetched and installed separately immediately reduces the
takeup. My inclination would be to hack in the code to generate
Content-MD5: (or X-Relay-Content-MD5:, or somesuchlike :-) initially,
and see how we got on with that. Probably better to experiment with a
freezing/blocking strategy in say Perl to get an idea of what's the
best approach.
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.
Ciao!
Martin
--
*** Exim information can be found at
http://www.exim.org/ ***
