Serverbased E-mail Security

From
Revision as of 01:10, 17 October 2005 by )nka (talk | contribs) (→‎Routing: adding routing drawing)
Jump to navigation Jump to search

Zusammenfassung

Immer mehr kritische Geschäftsprozze werden über Email Kommunikation abgewickelt. Dabei werden vertrauliche Daten direkt oder aber immer mehr auch automatisiert zwischen Applikationen (z.B. SAP Mailkonnektor) ausgetauscht. Das dafür verwendete SMTP Protokoll bietet keine ausreichenden Sicherheitsmechanismen, so dass sich die beiden Verfahren S/MIME und OpenPGP etablieren konnten. Eine standardkonforme Nutzung dieser Verfahren setzt ein enormes Anwenderwissen und relativ komplexe Vorgänge auf den Systemen des Endanwenders voraus. Dadurch werden PKI Infrastrukuren und Emailsignaturen und -verschlüsselungen bisher nicht umfassend eingesetzt. Die serverbasierten Lösungen tragen mehr und mehr dazu bei die genannten Verfahren einer breiten Anwenderzahl zugänglich zu machen und lassen die Nutzung von PKI's, Trustcentern und Emailsicherheit deutlich aufleben. Zusätzlich zu einer Vereinfachung der Anwendung und Administration bietet eine zentrale Lösung die Möglichkeit der Umsetzung von Archivierungen, Viren/SPAM Prüfungen in verschlüsselten Emails, Organisationsweiter Schlüsselhinterlegung (gefordert in ISO 9001 konformen Security Policy's), Anwendung globaler kontrollierbarer Regeln usw.. Da es bisher keine akzeptable freie OpenSource Implementierung gibt, wird hier der Aufbau eines Beispielszenarios auf Basis des SecureMail Gateways der Berliner Firma Zertificon Solutions durchgeführt. Vielen Dank für die Bereitstellung einer kostenfreien Lizenz!


Einleitung

Lange Zeit wurden unter dem Begriff Emailsicherheit lediglich Viren/SPAM Filter verstanden oder allgemeiner Systeme zur Eliminierung ungewollter Emails bzw. Emailinhalte. Eine Erweiterung des schwer einzugrenzenden Begriffs stellt die Anwendung kryptografischer Verfahren, aus dem Gebiet der IT Sicherheit zur Realisierung verschiedener Schutzziele, auf die Emailkommunikation dar. Dafür sind 2 Verfahren sehr weit verbreitet S/MIME und OpenPGP, welche sich ähneln aber nicht zueinander kompatibel sind. Der Anwender muss sich (und alle seine Kommunikationspartner) daher für ein Verfahren entscheiden oder entsprechende Software auswählen, die beide "Welten" unterstützt. Mit Hilfe dieser Verfahren ist es möglich digitale Signaturen zu erzeugen zur Sicherstellung von Integrität, Authentisierung und Verbindlichkeit sowie den Inhalt zu verschlüsseln um Vertraulichkeit zu gewährleisten. Diese beiden Anwendungen basieren auf einem hybriden Verfahren aus asymmetrischer und symmetrischer Kryptografie und erfordern daher eine entsprechende Verwaltung der in Zertifikate eingebetteten Schlüssel. Dabei muss zwischen öffentlichen Zertifikaten der Kommunikationspartner und den privaten internen Zertifikaten unterschieden werden.

Siehe auch:

S/Mime und PKI

S/Mime basiert auf der Nutzung von X.509 Zertifikaten, die Bestandteil einer PKI sind.

Siehe auch:

OpenPGP

OpenPGP nutzt selbsterzeugte Zertifikate, deren Echtheit über die Unterschriftenkette das sogenannte "Web of Trust" bestätigt wird.

Siehe auch:

Zertifikationsverwaltung

Die Zertifikate der Emailkommunikationspartner müssen den Anwendungen zur Verfügung stehen. Zusätzlich müssen alle Zertifikate im Pfad bis zu einer vertrauenswürdigen Wurzel ebenfalls zur Validierung bekannt sein. Das erfordert ein komplexes Zertifikatsmanagement.

Externe Kommunikationspartner

Die öffentlichen Zertifikate der Kommunikationspartner sind größtenteils in Verzeichnisdiensten der Herausgeber (Trustcenter) frei verfügbar oder werden manuell vor einer verschlüsselten Kommunikation oder implizit eingebettet in Signaturen übermittelt. Aus diesen 3 Quellen muss die Anwendung Zertifikate entgegennehmen können und idealerweise lokal speichern. Die Schwierigkeit besteht hierbei in den unterschiedlichen Formaten und Protokollen sowie in der Vielzahl der verfügbaren Trustcenter. Ein zentraler Service stellt daher eine enorme Vereinfachung für den Endwanwender dar. Dieser fungiert als Speicher und Metasuchmaschine und kann sogar bei entsprechendem Vertrauensstatus die Validierung übernehmen. Diese zentralen Zertifikatsdienste werden über Webservices und/oder dem XKMS Protokoll in Anwendungen integriert. Ein Beispiel: Backbone of Trust.

Interne Private Zertifikate

Die internen Zertifikate mit den geheimen Schlüsseln sind sicherheitsrelevante Daten und müssen daher auf entsprechend geschützte Weise verwaltet werden. Dazu können Software PSE auf speziell gehärteten Serversystemen, Hardware Security Module (z.B. spezielle PCI Karten, SmartCards) oder auch remote PSE's mit zertifizierten geschlossen Blackboxsystemen genutzt werden. Für Firmen ist es möglich den Verwaltungsaufwand enorm zu verkleinern durch die Nutzung von Domainzertifikaten. Hierbei wird pro Emaildomain nur ein privates Zertifikat benutzt.

Use Cases

Es gibt viele konkrete Szenarien in denen Emailsicherheit empfehlenswert oder sogar geschäftskritsche Notwendigkeit ist. Für die spezielle Form der serverbasierten Variante wären folgende zu nennen:

  • Viren/SPAM filtern in verschlüsselten Emails
  • Digitale Signatur als Schutz vor Phishing
  • Übermittlung kritischer Daten verschlüsselt per Mail (auch automatisiert und in großen Mengen)
  • Durchsetzung zentraler Regeln zur Anwendung von Kryptografie (z.B. Verbot interner Verschlüsselung zur Informationsflusskontrolle)

OSMS - OpenSecurityMailServer

Im folgenden wird Schritt für Schritt der Aufbau eines aktuell modernen (möglichst) sicheren Mailservers auf Basis von OpenSuSE 10 beschrieben. Bei Verdopplung des hier beschriebenen Systems und entsprechender Konfigurationsanpassung auf eine 2. Domain und IP kann damit ein vollständiges Server2Server Mailroutingszenario abgebildet und getestet werden. Das Verhalten der verschiedenen Sicherheitskomponenten kann eindrucksvoll im Zusammenspiel beobachtet werden. Ebenfalls möglich ist der Nachbau dieses fullfeatured Mailservers auf entsprechender Zielhardware zu Performancemessungen. Das Setup basiert teilweise auf der Beschreibung von Genco YILMAZ.

Aufbau Mailserver

Die Basiskomponenten des Systems sind:

  • Betriebssystem: OpenSuSE 10
  • Datenbank: PostgreSQL
  • MTA: Postfix 2.2 + SASL AUTH + TLS
  • IMAP/POP: Courier IMAPs/POPs
  • Webmail: Squirrelmail
  • Security: SecureMail Gateway 2.3 von Zertificon Solutions (OpenSSL, GnuPG, Bouncycastle)
  • Virenfilter: ClamAV über amavisd-new
  • SpamFilter: SpamAssassin über amavisd-new

Betriebssystem Setup

  • CD 1 oder DVD 1 einlegen und booten vom Medium
  • Auswahl Bootscreen: <Installation>
  • Language: Deutsch
  • Medienpruefung: <Weiter>
  • Lizenz: Ja + <Weiter>
  • Uhr und Zeitzone: Europa + Deutschland + Lokale Zeit + <Weiter>
  • Desktop: Andere + Textmodus + <Weiter>
  • Installationseinstellungen: <Uebernehmen>
  • Installation bestaetigen: <Installieren>
  • nach reboot CD 5 einlegen falls zur Hand ansonsten: <Ueberspringen> + <Ignorieren>

Basiskonfiguration

  • root Passwort setzen
  • Netzwerkkonfiguration:
    • Aendern -> Firewall -> Erlaubte Dienste hinzufuegen fuer die externe Zone:
  DHCP-Client (bei Bedarf), HTTPS,IMAPS,POP3S,SSH,Mailserver
    • Aendern -> Netzwerkschnittstellen -> Bearbeiten:
  Konfigurationsmethode, falls statische IP entsprechend eintragen
  Hostname, Domain, Nameserver, Defaultroute entsprechend Umgebung eintragen
  <Weiter>,<Weiter>
  • Test der Internetverbindung: "Nein" <Weiter>
  • Methode zur Benutzer-Authentifikation: Lokal (/etc/passwd) <Weiter>
  • Neuer Benutzer: <Weiter>,<Ja>
  • Hinweise zur Version: <Weiter>
  • Hardwarekonfiguration: <Weiter>
  • Installation abgeschlossen: <Beenden>

Remotezugang freischalten

als root auf der Konsole anmelden: 

vi /etc/ssh/sshd_config:
PermitRootLogin yes

/etc/init.d/sshd restart

Absofort kann die weitere Installation remote ueber eine SSH Sitzung durchgefuehrt werden!

Installation aller Pakete und Onlineupdate

(das Onlineupdate steht für OpenSuSE noch nicht zur Verfügung und muss hier noch ergänzt werden)


Installationsquelle fuer Netzinstallation hinzufuegen

Hinweis: bei lokalem DVD oder CD Satz nicht notwendig!

1. yast starten als root user 2. Falls notwendig proxy einrichten unter Netzwerkdienste -> Proxy-Server: 

  (x) Aktivieren, z.B.: http://proxy.domain.loc:3128

3. Software -> Installationsquelle wechseln -> Hinzufuegen: 

  http://download.opensuse.org/distribution/SL-OSS-current/inst-source
  http://download.opensuse.org/distribution/SL-OSS-current/inst-source-java/
  <yes>

4. Mit <Auf> die neue Quelle in der Liste nach oben verschieben.

Jetzt koennen beliebige Pakete ohne Installationsmedien hinzugefuegt werden.

Notwendige Softwarepakete installieren

System: 

yast -i xntp wget findutils-locate

SecureMail: 

yast -i postgresql postgresql-server patch sudo XFree86-libs libtool

Postfix: 

yast -i postfix-postgresql postgresql-libs

Cyrus SASL Authentication for SMTPD: 

yast -i mysql-shared postgresql-libs cyrus-sasl-sqlauxprop

Courier (and dependencies): 

yast -i courier-authlib courier-imap expect fam libtool tcl fam-server

Squirrelmail (and dependencies): 

yast -i apache2-prefork apache2 apache2-mod_auth_mysql apache2-mod_php5 php5-gettext php5-iconv \
php5-mbstring php5-openssl ispell-american squirrelmail squirrelmail-plugins

Content Filter: 

yast -i amavisd-new spamassassin clamav clamav-db

oder alles zusammen mit: 

yast -i xntp wget findutils-locate postgresql postgresql-server patch sudo XFree86-libs libtool \
postfix-postgresql postgresql-libs mysql-shared cyrus-sasl-sqlauxprop courier-authlib courier-imap \
expect fam  tcl fam-server apache2-prefork apache2 apache2-mod_auth_mysql apache2-mod_php5 php5-gettext \
php5-iconv  php5-mbstring php5-openssl ispell-american squirrelmail squirrelmail-plugins amavisd-new \
spamassassin clamav  clamav-db

Alle neuinstallierten Services in den Runleveln verlinken: 

 for d in saslauthd spamd freshclam clamd amavis ntp apache2 fam courier-authdaemon courier-imap-ssl courier-pop-ssl
 do
   chkconfig --add $d
 done

Manuelles Hinzufuegen von phpPgAdmin: 

cd /srv/www/htdocs/ && \
wget http://mesh.dl.sourceforge.net/sourceforge/phppgadmin/phpPgAdmin-3.5.5.tar.bz2 && \
tar xvjf phpPgAdmin-3.5.5.tar.bz2 && \
rm phpPgAdmin-3.5.5.tar.bz2


Das courier-authlib RPM muss neugebaut werden für die PostgreSQL Anbindung. Dazu können die SuSE Source Pakete genutzt werden. Hier sind meine nicht speziell gekennzeichneten oder versionierten RPMs für den Schnelltest und als Vorlage. 

Courier Authlib RPM mit PGSQL support
Courier Authlib SRPM mit PGSQL support

Selbermachen geht so:

  • courier-authlib source RPM installieren (z.B. im yast suchen und dann Aktionen->Quellen installieren -> Weiter)
  • Notwendige Pakete zum Kompilieren nachinstallieren:
yast -i postgresql-devel bison cvs flex gdbm-devel gettext-devel glibc-devel m4 ncurses-devel rcs strace \
        texinfo  unzip zlib-devel autoconf automake gcc gcc-c++ libstdc++-devel openldap2-devel pam-devel
  • Anpassen von /usr/src/packages/SPECS/courier-authlib.spec:
beim configure (Zeile 80) hinzufuegen:
       --with-pgsql-libs=/usr/lib \
       --with-pgsql-includes=/usr/include/pgsql \
       --with-authpgsql \
in der %files section (Zeile 150):
%{_libdir}/libauthpgsql.so.0*
  • Neues RPM erzeugen:
rpmbuild -ba /usr/src/packages/SPECS/courier-authlib.spec
  • Neues RPM installieren:
rpm --force -U /usr/src/packages/RPMS/i*86/courier-authlib-0.*.i*86.rpm
  • Entfernen der devel Pakete:
rpm -e postgresql-devel bison cvs flex gdbm-devel gettext-devel glibc-devel m4 ncurses-devel rcs \
       strace texinfo unzip zlib-devel autoconf automake gcc gcc-c++ libstdc++-devel openldap2-devel \
       pam-devel pango gtk2 cairo autoconf texinfo atk libgcj cyrus-sasl-devel

SecureMail Gateway installieren

Release auspacken: 

tar xvzf smgw-2_3_0-gw-build0150-suse-i386.tar.gz

Anpassungen zur Installation auf OpenSuSE 10: 

cd smgw-2_3_0-gw-build0150-suse-i386
perl -pi -e 's/_IDS="SUSE LINUX Enterprise Server/_IDS="SUSE LINUX/;s/-eq 9/-ge 9/' install.sh
perl -pi -e 's/_VERSIONS=9/_VERSIONS="9\t10"/' install/makeenv

Installation starten: 

./install.sh

Eingaben zur Installation: Netzwerke zur Firewallkonfiguration aus denen auf das SMGW zugegriffen wird (SSH + WWW) z.B. 

NETWORKS = 192.168.0.0/24

Mailrouting (yes auswaehlen): die 1. zu konfigurierende Domain auswaehlen z.B. 

Domain name: company1.loc
Recipient domains:
Internal mail server:
External smartrelay:

Runlevel Links erstellen mit: 

chkconfig --add smgw

Konfiguration

Zeitsynchronisation (NTP)

Eine exakte Zeit ist fuer digitale Signaturen und Zertifikatsvalidierung zwingend notwendig.

vim /etc/ntp.conf 

server ntp1.ptb.de
server ntps1-0.cs.tu-berlin.de
server ntp2.ptb.de
server ntps1-1.cs.tu-berlin.de

/etc/init.d/ntp restart

User/Gruppen

groupadd -g 1001 vmail useradd -g 1001 -u 1001 -d /home/vmail -m -c 'Virtual Mailsystem User' vmail

Datenbank Virtuelle Domain/User Konfiguration

/etc/init.d/postgres start

Als Datenbank User weiterarbeiten: 

su - postgres

Zugriffsrechte anpassen: 

perl -pi -e 's/(.*?127\.0\.0\.1.*?)ident sameuser/$1md5/g' $PGDATA/pg_hba.conf
pg_ctl reload

Mail Datenbank erstellen: 

psql -c "create user vmailuser with password 'changeIT' createdb createuser" template1
psql -U vmailuser -h 127.0.0.1 -p 5432 -c "create database mail with encoding = 'unicode'" template1
psql -U vmailuser -h 127.0.0.1 -p 5432 -d mail < create_tables.sql


Beispieldaten hinzufügen: 

postgres@osms:~> psql -U vmailuser -h 127.0.0.1 -p 5432 -d mail -c "\
INSERT INTO postfix_users (email,clear,name,homedir,maildir,quota) VALUES
('alice@company1.loc','alice','Alice','/home/vmail/','company1.loc/alice/Maildir/','10000000') ;"

Erstellen des Mailverzeichnisses fuer den neuen User: 

osms:~ # su - vmail
vmail@osms:~> mkdir -p company1.loc/alice
vmail@osms:~> maildirmake company1.loc/alice/Maildir
vmail@osms:~> maildirmake -q 10000000S company1.loc/alice/Maildir

Einrichten von phpPgAdmin zur Pflege der MTA Daten: 

osms:/srv/www/htdocs/phpPgAdmin # cp conf/config.inc.php-dist conf/config.inc.php
osms:/srv/www/htdocs/phpPgAdmin # vim conf/config.inc.php

       $conf['servers'][0]['desc'] = 'Postfix/Courier Backend';
       $conf['servers'][0]['host'] = '127.0.0.1';
       $conf['servers'][0]['port'] = 5432;
       $conf['servers'][0]['defaultdb'] = 'template1';
       $conf['servers'][0]['pg_dump_path'] = '/usr/bin/pg_dump';
       $conf['servers'][0]['pg_dumpall_path'] = '/usr/bin/pg_dumpall';

/etc/init.d/apache2 restart

Anmelden ist dann ueber http://192.168.0.170/phpPgAdmin/ als vmailuser (pass: changeIT) moeglich. Ueber die WebGUI koennen nun weitere User/Domains hinzugefuegt werden. In groesseren Installationen koennen natuerlich spezielle Mailverwaltugnen direkt auf das SQL Backend zugreifen. Eine Integration ist dadurch leicht moeglich, ebenso ein Verteilung der Daten auf mehrere MTA Instanzen.

Postfix

TLS

SMTPD Server SSL Zertifikat erzeugen. Fuer ein Produktivsystem sollte hier natuerlich eine echte CA genutzt werden. 

osms:/etc/postfix # openssl req -x509 -newkey rsa:1024 -keyout postfix.pem -out postfix.pem -nodes -days 365
Generating a 1024 bit RSA private key
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Berlin
Locality Name (eg, city) []:Berlin
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Company 1
Organizational Unit Name (eg, section) []:Secure Emailadministration
Common Name (eg, YOUR name) []:osms.domain.loc
Email Address []:

Einstellungen in /etc/postfix/main.cf: 

smtpd_use_tls = yes
smtpd_tls_cert_file = $config_directory/postfix.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_auth_only = yes

SASL/SMTP AUTH

Einstellungen in /etc/postfix/main.cf:

smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_sasl_local_domain = $myhostname broken_sasl_auth_clients = yes smtpd_sasl_application_name = smtpd

osms:/etc/postfix # vim /usr/lib/sasl2/smtpd.conf 

pwcheck_method: auxprop
auxprop_plugin: sql
mech_list: plain login

sql_engine: pgsql
sql_hostnames: localhost
sql_user: vmailuser
sql_passwd: changeIT
sql_database: mail
sql_select: select clear from postfix_users where email='%u@%r' and smtpaccess='Y'

Lookup Tables

Die standardmäßig als normale Dateien zur Verfügung gestellten Map/Lookup Tabellen sind in die Datenbank verlagert worden, um weitere Applikationen darauf aufzusetzen und eine Verteilung in großen geclusterten Installationen zu gewährleisten. Die einzelnen Tabellen werden separat konfiguriert.

Postfix erfährt über die /etc/postfix/main.cf die Konfigurationsdateien: 

check_client_access pgsql:/etc/postfix/pgsql-client.cf
check_sender_access pgsql:/etc/postfix/pgsql-sender.cf
check_recipient_access pgsql:/etc/postfix/pgsql-recipient.cf
alias_maps = pgsql:/etc/postfix/pgsql-aliases.cf 
relocated_maps = pgsql:/etc/postfix/pgsql-relocated.cf
transport_maps = pgsql:/etc/postfix/pgsql-transport.cf
virtual_mailbox_domains = pgsql:/etc/postfix/pgsql-virtual-domains.cf 
virtual_alias_maps = pgsql:/etc/postfix/pgsql-virtual.cf 
virtual_mailbox_maps = pgsql:/etc/postfix/pgsql-virtual-maps.cf 
virtual_uid_maps = pgsql:/etc/postfix/pgsql-virtual-uid.cf 
virtual_gid_maps = pgsql:/etc/postfix/pgsql-virtual-gid.cf

Die einzelnen Dateien befinden sich in der archivierten Postfix Konfiguration.

Routing

Das Mailrouting wird hauptsächlich durch die in der master.cf konfigurierten Services beeinflusst.

Folgende Grundideen sind hierbei umgesetzt:

Postfix Routing Overview
  • Separierung von innen und außen Bereich durch Port 25 SMTPD auf unterschiedlichen IP Adressen (im aktuellen Beispiel außen: 192.168.0.170 innen 192.168.0.171)
  • auf beiden Eingängen ist TLS aktiv
  • an der inneren Schnittstelle wird TLS erzwungen (für Clients die dies nicht unterstützen z.B. squirrelmail wird der separate smtps Port 465 geöffnet)
  • SMTP AUTH ist am inneren Eingang Pflicht
  • ein before-queue amavisd Filter führt adhoc Viren/SPAM checks durch, die zum REJECT der Mail führen können
  • das SMGW sorgt für automatische Ver/Entschlüsselung, Signatur/Verifikation
  • anschließend wird nochmals ein Viren/SPAM check durchgeführt (damit werden eingangs verschlüsselte Viren und auch SPAM gefiltert!)

Die main.cf und master.cf befinden sich in der archivierten Postfix Konfiguration.

Courier

Auth

Zur Authentifizierung wird das Paket courier-authlib benutzt und muss zur Anbindung an die User Datenbank konfiguriert werden.

vim /etc/authlib/authdaemonrc: 

authmodulelist="authpgsql authpam"

vim /etc/authlib/authpgsqlrc: 

PGSQL_HOST              localhost
PGSQL_PORT              5432
PGSQL_USERNAME          vmailuser
PGSQL_PASSWORD          changeIT
PGSQL_DATABASE          mail
PGSQL_USER_TABLE        postfix_users
PGSQL_CRYPT_PWFIELD     crypt
PGSQL_CLEAR_PWFIELD     clear
PGSQL_UID_FIELD         uid
PGSQL_GID_FIELD         gid
PGSQL_LOGIN_FIELD       email
PGSQL_HOME_FIELD        homedir
PGSQL_NAME_FIELD        name
PGSQL_MAILDIR_FIELD     maildir
PGSQL_QUOTA_FIELD       quota
PGSQL_AUXOPTIONS_FIELD  'disableimap=' || disableimap || ',disablepop3=' || disablepop3 || ',
                         disablewebmail=' || disablewebmail || ',sharedgroup=' || sharedgroup
PGSQL_WHERE_CLAUSE      access='Y'

chmod 400 /etc/authlib/authpgsqlrc

/etc/init.d/courier-authdaemon restart

IMAP/POP

Create SSL certs: vim /etc/courier/pop3d.cnf: 

[ req_dn ]
C=DE
ST=B
L=Berlin
O=Courier POP3 Server
OU=Automatically-generated POP3 SSL key
CN=localhost
emailAddress=postmaster@domain.loc

vim /etc/courier/imapd.cnf: 

[ req_dn ]
C=DE
ST=B
L=Berlin
O=Courier IMAP Server
OU=Automatically-generated IMAP SSL key
CN=localhost
emailAddress=postmaster@domain.loc

Prozesse starten mit: 

/etc/init.d/fam start
/etc/init.d/courier-pop-ssl start
/etc/init.d/courier-imap-ssl start

Squirrelmail Webmailer

Die Konfiguration auf eigene Daten anpassen: 

/srv/www/htdocs/squirrelmail/config/conf.pl

http://192.168.0.170/squirrelmail/

Name: alice@company1.loc Password: alice

Z1 SecureMail Gateway

  • Lizenz einspielen
  • Relay IPs anpassen
  • Policy einstellen

Der Anwendung liegt eine sehr gute Dokumentation bei. Entweder über die Weboberfläche unter "Documentation" oder im Dateisystem: ``/opt/tbone/doc/Z1_SMGW_03_System_Guide.pdf``.

Anwendung und Testfälle

Fazit

Weiterführende Links

Internet Mail Consortium: S/MIME and OpenPGP
Z1 SecureMail Gateway
Teletrust e.V. (inkl. ISIS-MTT Spezifikation)

1. Autor: Ingo Kampe (Signierte Emails an kampe@...)

Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=Serverbased_E-mail_Security&oldid=1855"