|
List Info Thread: R: excessive time spent in sql-update?
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
R: excessive time spent in sql-update? |
|
List Info Thread: R: excessive time spent in sql-update?
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
lists.sourceforge.net
[mailto:amavis-user-
>
> Giampaolo,
>
> > I guess it's better you don't use the mail_id
field as a primary key:
> it
> > may not be unique in your db. Think, in example,
to messages sent to
> > destinations defined as a list or an alias in your
system.
>
> Don't confuse mail_id with a Message-ID header.
Ok, I just did... 
Sorry for increasing the entropy of this thread.
Giampaolo
> mail_id is guaranteed by amavisd to be unique among all
records
> currently present in a database.
>
>
> amavisd-new-2.3.0 release notes:
>
> ...
> reported
> in the log and elsewhere (e.g. 92598-11-5), but has
much stronger
> long-term
> uniqueness property and can be used for the purpose
of uniquely
> identifying
> a quarantined mail, or for other uses. The mail_id is
a 12-character
> string
> consisting of characters [A-Za-z0-9+-] (like base64,
except for a '/'
> being
> substituted by a '+'), guaranteed to start and to end
with an
> alphanumeric
> character (i.e. not with '+' or '-'). It is derived
by
> cryptographically
> strong method (MD5), cumulatively collecting entropy
during the life
> of
> child processes, folding-in entropy from processed
mail and other
> cheaply
> accessible sources, collected when an opportunity
arises (e.g. file
> system
> file-IDs, SA results etc), without placing a burden
on system sources
> of
> randomness (see RFC 4086). Note that MD5 has been
demonstrated to
> have some
> weaknesses, but we are not talking about
cryptographic attacks here,
> but
> rather about spreading messages which have no
inherent intention of
> causing
> collisions.
>
> The mail_id carries 71.9 bits of information (subject
to the quality
> of
> sources). For a high-end system that keeps a year's
worth of mail
> messages
> in evidence (e.g. in quarantine) and receives 10e6
messages each day
> (20..200 TB of yearly mail contents), the probability
of a mail_id
> collision happening during one year (while gradually
displacing an
> entire
> collection with a new set of IDs) is n^2/m = 0.3 %
> (10e6 * 365)^2 / (62 * (64^(12-2)) * 62) = (10e6 *
365)^2 / 2^71.9
> = 0.003
> Eventual clash is still possible and needs to be
detected, but a re-
> tried
> mail delivery attempt is acceptable if its
probability is low, as
> each mail
> processing rolls a dice again. On a smallish system
receiving 10.000
> mail
> messages daily an 8-character mail_id would suffice,
but the savings
> are
> not worth the trouble of providing configuration
flexibility.
>
> Paired with a mail_id there is its companion
secret_id generated for
> each
> message, such that mail_id can be derived from
secret_id and pairing
> checked,
> but not the other way around. The purpose of
secret_id is not yet
> fully
> developed, but can serve as a 'ticket', granting user
a right to
> release
> a quarantined message addressed to him.
>
>
> Mark
>
>
------------------------------------------------------------
-----------
> --
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?
Stop.
> Now Search log events and configuration files using
AJAX and a browser.
> Download your FREE copy of Splunk now >>