duplicate detection
Differences
The differences between two versions are shown here.
| Both sides of the previous revisionPrevious revisionNext revision | Previous revision | ||
| duplikatserkennung [2017/11/23 13:42] – [Multiple Mailzuführung in komplexen Umgebungen] lwsystems | duplikatserkennung [2022/06/08 14:12] (current) – [Funktionsweise] lwsystems | ||
|---|---|---|---|
| Zeile 5: | Zeile 5: | ||
| During archiving, Benno MailArchiv generates a SHA256 checksum for each archived email. This is logged internally in the Benno MailArchiv journal and used for consistency checks (compliance). | During archiving, Benno MailArchiv generates a SHA256 checksum for each archived email. This is logged internally in the Benno MailArchiv journal and used for consistency checks (compliance). | ||
| - | ====== Funktionsweise | + | ===== Funktionsweise ===== |
| - | Die Checksumme wird jeweils über die **gesamte** E-Mail erzeugt. | + | Die Checksumme wird jeweils über die **gesamte** |
| + | |||
| + | Beim Archivieren einer E-Mail | ||
| Dank dieser wirksamen Doubletten-Erkennung können E-Mails beliebig oft zur Archivierung an Benno MailArchiv übergeben werden. Sie werden zuverlässig als Doubletten erkannt und ihre Archivierung als Duplikat abgebrochen, | Dank dieser wirksamen Doubletten-Erkennung können E-Mails beliebig oft zur Archivierung an Benno MailArchiv übergeben werden. Sie werden zuverlässig als Doubletten erkannt und ihre Archivierung als Duplikat abgebrochen, | ||
| - | Durch die SHA265-Prüfsumme ist mit an Sicherheit grenzender Wahrscheinlichkeit ausgeschlossen, | + | Durch die SHA256-Prüfsumme ist mit an Sicherheit grenzender Wahrscheinlichkeit ausgeschlossen, |
| Da die gesamte E-Mail für die Erzeugung der Checksumme herangezogen wird, bedeutet dies bzgl. der Konsistenzprüfung von archivierten E-Mails bzw. der Konsistenzprüfung des gesamten Archivs, dass bereits das „Kippen“ eines einziges Bits einer archivierten E-Mail ausreicht, um die Checksumme der Mail zu verändern, und somit eine Korruption der Mail/des Archivs festzustellen ist. | Da die gesamte E-Mail für die Erzeugung der Checksumme herangezogen wird, bedeutet dies bzgl. der Konsistenzprüfung von archivierten E-Mails bzw. der Konsistenzprüfung des gesamten Archivs, dass bereits das „Kippen“ eines einziges Bits einer archivierten E-Mail ausreicht, um die Checksumme der Mail zu verändern, und somit eine Korruption der Mail/des Archivs festzustellen ist. | ||
| - | ===== Multiple Mailzuführung in komplexen Umgebungen ===== | + | ====== Multiple Mailzuführung in komplexen Umgebungen |
| While emails typically (and especially in on-premises installations) reach the mail archive via a single, uniform path, in complex environments (e.g., in larger hosting infrastructures) emails may be transported to the archive multiple times and simultaneously via different paths. For example, different MTAs or transport methods and types (SMTP, IMAP, etc.) could be responsible for this. | While emails typically (and especially in on-premises installations) reach the mail archive via a single, uniform path, in complex environments (e.g., in larger hosting infrastructures) emails may be transported to the archive multiple times and simultaneously via different paths. For example, different MTAs or transport methods and types (SMTP, IMAP, etc.) could be responsible for this. | ||
| - | ==== Ein Beispiel ==== | + | In diesem Fall bietet sich die Konfiguration einer [[konfiguration# |
| + | |||
| + | |||
| + | ===== Ein Beispiel | ||
| In a highly complex infrastructure, Benno MailArchiv receives a specific email "M" for archiving via three different routes. Because each copy of the email is transported via these different routes, the email itself (from the user's perspective in the mail client – i.e., in terms of text and content) is the same. However, in the email copies (in the part typically not visible to the user), individual and different email headers have been inserted for each copy due to the different transport routes. | In a highly complex infrastructure, Benno MailArchiv receives a specific email "M" for archiving via three different routes. Because each copy of the email is transported via these different routes, the email itself (from the user's perspective in the mail client – i.e., in terms of text and content) is the same. However, in the email copies (in the part typically not visible to the user), individual and different email headers have been inserted for each copy due to the different transport routes. | ||
| Zeile 53: | Line 58: | ||
| However, if several emails (identical in content and text) M1, M2 and M3 (different copies of the same email in the above sense) arrive for archiving, how should these be handled with regard to their different headers? | However, if several emails (identical in content and text) M1, M2 and M3 (different copies of the same email in the above sense) arrive for archiving, how should these be handled with regard to their different headers? | ||
| - | ====== Eine rechtliche | + | ====== Eine Sicht auf rechtliche Aspekte dieser |
| Rechtlich besteht nach uns vorliegenden Informationen kein Zwang, mehrere Varianten einer E-Mail zu archivieren, | Rechtlich besteht nach uns vorliegenden Informationen kein Zwang, mehrere Varianten einer E-Mail zu archivieren, | ||
duplikatserkennung.1511444526.txt.gz · Zuletzt geändert: 2017/11/23 13:42 von lwsystems
Page Tools
