New header: X-MailScanner-Id:

[Mariano Absatz]

Hi,

I did a small upgrade to these patches (I left them in the same place, 
replacing the old ones).

I was a bit uneasy about the uniqness of the id, so, before md5-digesting it, 
I added the MTA-level id ($message->{id}) and a little bit of random 
(int(rand(1_000_000))) to it.

OTOH, the fact that the X-MailScanner-Id was showing the md5 string _AND_ the 
original string poses some information disclosure, since it is showing all of 
the recipients of a message to all the recipients, and that might include one 
or more "blind" recipients ("Bcc:")... so now, if you say (in the 
MailScanner.conf file):

Include Id Header = yes
Full Id Header = no

it will _only_ show the md5 string... if you want both, you have to say:

Include Id Header = yes
Full Id Header = yes

The default for both options is "no".

Julian, 

if you think you won't be adding this patch, please let me know and I'll pack 
it as a single file patch, easier to use by us mortals (with access only to 
the distribution).

Regards.

El 15 Sep 2003 a las 20:40, Mariano Absatz escribió:

> Hi Julian,
> 
> my loggin tweaks never end... :-)
> 
> As ZMailer internal id's are purely based on the inode number of the message
> file, these id's are, by no means, unique... what's more, in linux, they
> repeat frequently... sometimes within the same second (that is, when the
> beast is running fast)...
> 
> So when I started adding log entries to a SQL database (in a different way of
> the standard SQLLogging, but with many ideas borrowed from it) I found myself
> trying to find a suitable Id for joining the tables.
> 
> The easiest thing to do is to generate a serial entry in the message table
> and use it in the recipient & report tables, but then I also wanted the Id to
> be in the message itself, so I can cross reference between the database and
> the messages themselves.
> 
> So off I went... and modified MailScanner to do this... I generated an Id
> based on the hostname, process-id, timestamp, originating IP (clientip), from
> and to list... it seems to be quite unique... otherwise, we could add some
> randomness to it...
> 
> I thought about leaving the text form just "as is"... but it was really too
> long to use it as an effective id in 3 different tables. So I did an MD5
> checksum and stored that... but later I missed the verbosity of the text
> form, so I let the header with both forms, first the checksum, and then (in a
> new line that starts with a tab, RFC2822-compliant) the long form...
> 
> The following files had to be modified for this to work:
> /opt/bin/MailScanner
> /opt/lib/MailScanner.pm
> /opt/lib/MailScanner/ConfigDefs.pl
> /opt/lib/MailScanner/Message.pm
> 
> I let a set of complete modified files (as well as individual patches for
> 4.23-11) in http://www.baby.com.ar/MailScanner/id-patch/
> 
> Please, let me know what you think.
> 
> Oh... you have to add the following lines to MailScanner.conf to make it
> work:
> 
> Id Header = X-MailScanner-%org-name%-Id:
> Include Id Header = yes
> 
> by default, the header will not be added.
> 
> PS: The Message.pm file has already been patched for the $nametag/$contentag
> bug (see http://tinyurl.com/nh59) _and_ for the $Name inside MailScanner's
> own report when using multiple lines (see http://tinyurl.com/nh5c).

--
Mariano Absatz
El Baby
----------------------------------------------------------
Allow me to introduce my selves.