disciple schrieb:
Counselor schrieb:
Schon mal was davon gehört, daß man den Zugang zum SMTP Gateway zB nach Domänen sperren kann?
Falsch.
Eine Frage kann nicht richtig oder falsch sein.
disciple schrieb:
Du kannst einen Socket nach Domänen sperren.
Du gibst mir also recht, daß man den Zugang zu einem SMTP Gateway sperren kann? Und unter Socket verstehst du hoffentlich auch ein Tupel aus Ziel- und Quell-IP-Adresse, Ziel- und Quell-Port und Netzwerkprotokoll, so daß wir uns auf eine Sperrung über eine Firewall verständigen können?
disciple schrieb:
Weiterhin ist eine MTA, wenn sie mit einer anderen MTA kommuniziert ein Relay, kein Server.
Tja, für die Weiterleitung (Relaying) von Mail ist ein SMTP-Relay-Server ja auch zuständig. Sonst würde dort ja keiner was hinschicken. Und wenn du dich an dem Begriff 'Serverprozess' störst: Darunter versteht man eine Anzahl von Tasks, die unter der Regie eines (Domino-)Servers laufen. Hat also nichts damit zu tun, ob der MTA gerade mit einem anderen MTA kommuniziert oder nicht.
disciple schrieb:
Und wenn du schon auf Fachsimpelei bestehst, ist es ein Deamon.
Wenn schon, dann
Daemon; kommt nämlich von 'disk and execution monitor'. Daemons (hilfreiche Geister) gibt es nur in der UNIX/LINUX basierten Welt. Mailsysteme, die nicht unter UNIX/LINUX basierten Systemen laufen, haben keine MTA-Daemons. Erzähl mal MS, der Exchange Server hätte einen MTA-Daemon. MS definiert den MTA so: 'A component that transfers messages between servers using the X400 protocol' und hat ihn als Service implementiert. Steinhardt nennt ihn in seinem Notes/Domino Kompendium schlicht 'Serverprozess' (korrekte Bezeichnung im Englischen 'Domino-SMTP-MTA-Server-Task'), der die Schnittstelle zu anderen Mailsystemen ist. Ein Task ist ein Prozess, der eine spezielle Serverfunktion realisiert. Lotus definiert es so: 'MTA (message transfer agent): A program that translates messages between mail formats. Also called a gateway.'
disciple schrieb:
Und nochmal: eine Authentifizierung beim Einliefern würde bedeuten, dass nur die bekannte MTAs Mails an dich schicken könnten.
Und nochmal: Ein kleines Unternehmen hat einen SMTP Gateway. Diesen nutzt es, um sich mit dem Gateway seines Mailproviders zu verbinden, um dort hin über SMTP Mails zu senden und über POP3 zu empfangen. Warum sollte dem Unternehmen ein fremder völlig unbekannter MTA was zuschicken können? Es reicht doch, wenn alle Mails beim Provider eingehen und von dort abgerufen werden können, oder nicht?
disciple schrieb:
Das natürlich auch ne Methode Spam (und eMails ganz allgemein) zu vermeiden.
Wieso sollte mir jemand anders als mein angestammter Provider eine Mail zusenden dürfen? Es reicht doch, wenn die Leute meine Mails zu meinem Provider senden?
disciple schrieb:
Gut dass sich MTAs nur identifizieren.
Nein, sehr schlecht. Neue Übertragungsmethoden von Mail, die eine Authentifizierung der beteiligten Mailserver erlauben, sollen das bisherige System (SMTP) ablösen. Rein unternehmensinterne MTAs identifizieren sich mit einem X.509 Zertifikat. Ein HELO reicht da nicht.
disciple schrieb:
Counselor schrieb:
Eine kleine Fa mit DSL Anschluß, die ihre Mails mehrmals täglich beim Provider abholt identifiziert ihren Gateway ebenfalls am Gateway des Providers.
Abholt, richtig.
Oh, ich hatte vergessen, daß die Angestellten auch Mails schreiben, und über den Sammelaccount des Unternehmens beim Mailprovider versenden. Da reicht kein einfacher HELO.
disciple schrieb:
Counselor schrieb:
Aha. Du willst also eine Liste aller dynamischen IP Segmente führen. Fang mal an zu tippen.
Schon geschehen. Willkommen in der Admin-Welt. Heute: Ich und das RIPE-Net
Sagt zwar was aus, wem ein IP Segement gehört. Sagt aber nichts darüber aus, ob die Adressen in dem Segment dynamisch vergeben werden. Ein Kunde unserer Firma ist auch mit einem Segment an IP Adressen bei RIPE eingetragen. Er hütet sich, alle IPs dynamisch zuzuweisen. Und noch mehr hütet er sich, die Art und weise der IP Adresszuweisung öffentlich zu machen.
http://www.ripe.net/ripencc/faq/database/qa2.html#1
disciple schrieb:
Wenn nach deiner Aussage relevant wäre, welche IP dahinter steckt, wäre DHCP sehr wohl relevant.
Falsch. Einfach einzusetzende und verbreitete Reputationssysteme wie DNS-basierte Black- und Whitelists (entweder für IP-Adressen oder für Domains) reichen.
disciple schrieb:
Aber, glück gehabt, interessiert den MTA nicht.
Der Kandidat hat 100 Punkte! Glückwunsch! Wenn die E-Mail Authentifizierung (zB SPF) kommt, dann wird sich die Frage dem MTA ganz schnell stellen. Wenn der MTA eine Nachricht ohne Prüfung der Zuordnung Absender A/IP-Adresse X annimmt, setzt er den MDA der Gefahr aus, dass dieser eine Fehlermeldung für ein nicht wirklich von Adresse A stammendes Mail an Adresse A sendet, oder ich setze den Benutzer der Gefahr aus, dass er ein angeblich von Absender A stammendes Mail für echt hält. Literaturtipp:
http://spf.pobox.com/howworks.html
disciple schrieb:
Deshalb kann man ja auch domain-ranges sperren, die ja mal mit IP-Adressen (abgesehen von dns) garnix zu tun haben.
Falsch. Deine Domain-Range ist eine Teilmenge eines DNS Namensraums. Oder anders: ohne DNS gäbe es deine Domain-Range nicht. Der Rechnername eines MTAs ist eines von mehreren DNS Objekten einer Domäne. Seine IP Adresse wird in der Zonendatei in einem Resource Record gehalten. Der Typ des Ressource Records ist entweder A bei IPv4 oder AAAA bei IPv6. Willst du deinem MTA die Kommunikation mit Rechnern bestimmter Domänen verbieten, dann mußt du kucken, ob die IP des Senders in der Zonendatei der verbotenen Domänen geführt wird.
disciple schrieb:
Richtig ist: man stellt mehrere Conditions fest.
Falsch: Wenn auch nur eine Condition zutrifft, dann wird der entsprechende Mail Service ausgelöst. Beispiel: Du willst weder Mails mit Anhängen > 25 MB (Condition: Size Limit25 löst MailDeny aus), noch virenverseuchte Anhänge (Condition: MailHasAttachement löst Mail Service AttachementAnalyzer aus, welcher bei positivem Befund Mail Deny auslöst). Es kommt eine virenverseuchte Mail mit Anhang, Größe wenige kByte. Willst du die etwa durchlassen? Literaturtipp:
http://www.inform.de/C1256C9F00704EC6/vwContentByKey/N25N9EQB931ABENDE
disciple schrieb:
Falsch ist: man guckt nicht nur auf den Content sondern ebenso auf den Header.
Richtig ist: Es gibt die Condition SPAM Mail Content mit der Rule 'MailContent', die den Body untersucht, und es gibt für diverse Header-Felder eigene Conditions, aber auch für Envelope-Felder (zB. die Condition 'Incoming Bad Domains' mit zB einer Rule 'FromBadExtDomain', die das Feld 'SenderDomains' untersucht). Erstere Condition filtert - contentbasiert -ausschließlich SPAM, zweitere Condition filtert díe Mail unabhängig davon, ob der Content SPAM ist oder nicht, wenn die Mail von bestimmten Senderdomains kommt.
disciple schrieb:
Noch richtiger ist: es wird kein Mail-Deny Service aufgerufen
Erzähle das mal Notesdev. Im ND.Cerberus löst die SPAM Condition den Mail Deny Service aus. Das bedeutet: Man kann einstellen, ob sie ganz abgewiesen wird, oder nur geblockt. Im ersteren Fall erhält der Absender wahlweise eine NDR oder die abgelehnte Mail. Im zweiteren Fall gar keine Benachrichtigung. Auf jeden Fall wird die Mail aus dem Mailrouter gelöscht. Optional werden Administratoren per Mail von diesem Vorgang benachrichtigt. Die abgelehnte Mail wird optional in einer Mail-In-Datenbank archiviert.
disciple schrieb:
Besser: Notes/Domino + ND.Cerberus mit
ISS/Cobion Orange Spam Technologie. Das ISS/Cobion Rechenzentrum in Kassel hat eine Topaktuelle SPAM-Signaturdatenbank. Darüber hinaus können in E-Mails vorhandene URLs gegen eine ebenso aktuelle SPAM-URL Datenbank abgeglichen werden. Ferner: Blackholelists, Interne Blacklist, Textanalyse mittels Text-Histogrammen, Schlüsselwort- und Bildanalyse. Und integrierte Scan-Engines der führenden Hersteller von Virenscannern. Und vieles, vieles mehr
...