Hilfe ich spamme....

disciple schrieb:
Das heißt: wurde die eMail von einem regulären Mail-"server" (der Begriff ist eigentlich technisch falsch und steht nur der Verständlichkeit halber hier, korrekt ist MTA Mail Transfer Agent mit statischer IP Adresse) oder von einem Dial Up Host, also einer normalen Kiste mit dynamischer IP verschickt.
Hmm, eigentlich sollte man schon am SMTP Gateway die Weiterleitung von nicht korrekten Mailservern unterbinden (Authentifizierung, Whitelist). Plausibiltätskontrolle ja, aber im vorliegenden Fall kann man von einer gültigen Mailadresse ausgehen. Die Sache mit dem Reverse Lookup hat was für sich.

Es kann aber auch viel trivialer sein: ZB kann die Mail einen Anhang mit unerwünschten Binärcode, gesperrten Dateiendungen etc pepe haben.
 
Counselor schrieb:
Hmm, eigentlich sollte man schon am SMTP Gateway die Weiterleitung von nicht korrekten Mailservern unterbinden (Authentifizierung, Whitelist).

Warum sollte sich ein MTA bei einem anderen Authentifizieren? Der will ja nichts haben, sondern was loswerden.
Und bitte verzeih, aber das Word Whitelist in Zusammenhang mit SMTP zu verwenden kann unter günstigsten Bedingungen bestenfalls als Schwachsinn bezeichnet werden. Willst du auf einer MTA eine Liste mit allen Relays führen, die das Recht haben dir ne Mail zu schreiben? Fang schonmal an zu tippen, wir hören uns dann 2015 wieder.

Aber du kannst 1und1 ja mal vorschlagen, dass du auf dem zentralen Relay eine für dich optimierte Blacklist (Stichwort SORBS) einführen willst, aber such dir vorher schonmal nen neuen Hoster.

EDIT: Englischwahn natürlich Wort, nicht Word
 
disciple schrieb:
Warum sollte sich ein MTA bei einem anderen Authentifizieren? Der will ja nichts haben, sondern was loswerden.
Ein MTA ist ein Serverprozeß, der den Anschluß an ein externes Mailsystem herstellt. Damit beschränkt sich seine Funktion nicht darauf was loszuwerden, sondern er nimmt auch Mails entgegen. BTW: Schon mal was davon gehört, daß man den Zugang zum SMTP Gateway zB nach Domänen sperren kann?
Zur Authentifizierung: Wir haben etwa ein Dutzend firmeninterne MTAs. Die authentifizieren sich natürlich. Eine kleine Fa mit DSL Anschluß, die ihre Mails mehrmals täglich beim Provider abholt identifiziert ihren Gateway ebenfalls am Gateway des Providers.
disciple schrieb:
Und bitte verzeih, aber das Word Whitelist in Zusammenhang mit SMTP zu verwenden kann unter günstigsten Bedingungen bestenfalls als Schwachsinn bezeichnet werden. Willst du auf einer MTA eine Liste mit allen Relays führen, die das Recht haben dir ne Mail zu schreiben? Fang schonmal an zu tippen, wir hören uns dann 2015 wieder.
Eigentlich meinte ich eine Blacklist mit Open Relays. Insoweit falsch ausgedrückt.
disciple schrieb:
Aber du kannst 1und1 ja mal vorschlagen, dass du auf dem zentralen Relay eine für dich optimierte Blacklist (Stichwort SORBS) einführen willst, aber such dir vorher schonmal nen neuen Hoster.
Brauche ich ebenfalls nicht, weil ich dort nicht hosten lasse. Die Auftraggeber meines Arbeitegbers haben idR ein eigenes Rechenzentrum.
disciple schrieb:
Das heißt: wurde die eMail von einem regulären Mail-"server" ... oder von einem Dial Up Host, also einer normalen Kiste mit dynamischer IP verschickt.
Aha. Du willst also eine Liste aller dynamischen IP Segmente führen. Fang mal an zu tippen.

Die Frage, die ein MTA beantworten muß, lautet etwas anders: Darf ich von der IP-Adresse X eine Nachricht im Namen von Absender A für Empfänger B entgegennehmen? Das hat nichts damit zu tun, ob eine IP dynamisch über DHCP vergeben wird oder nicht oder ob die IP zu einem Rechner gehört, der sich über DFÜ eingewählt hat. Oder willst du Mails von einer kleinen Fa, die sich über DFÜ einwählt als SPAM abtun?
disciple schrieb:
Spamfilter suchen nur in dritter/vierter instanz nach Worten
Stimmt so auch nicht. Man überwacht den Mailverkehr auf den Servern mittels Mail Conditions auf zahlreiche Eigenschaften, und nicht nur auf SPAM. Eine von mehreren Dutzend Mail Conditions ist zB SPAM. Wenn die Condition SPAM anhand konfigurierbarer Regeln (=SPAM-Filter) durch einen Blicks in den Content der Mail festgestellt wird, dann wird der Mail-Deny Service aufgerufen. Der Mail Deny Service wird aber zB auch bei der Condition 'Attachement > 10 MB' aufgerufen oder wenn eine Mail aus einer unerwünschten Domäne kommt, ohne daß es zwingend SPAM sein muß.
 
Counselor schrieb:
Ein MTA ist ein Serverprozeß, der den Anschluß an ein externes Mailsystem herstellt. Damit beschränkt sich seine Funktion nicht darauf was loszuwerden, sondern er nimmt auch Mails entgegen. BTW: Schon mal was davon gehört, daß man den Zugang zum SMTP Gateway zB nach Domänen sperren kann?

Falsch. Du kannst einen Socket nach Domänen sperren. Weiterhin ist eine MTA, wenn sie mit einer anderen MTA kommuniziert ein Relay, kein Server. Und wenn du schon auf Fachsimpelei bestehst, ist es ein Deamon. Und nochmal: eine Authentifizierung beim Einliefern würde bedeuten, dass nur die bekannte MTAs Mails an dich schicken könnten. Das natürlich auch ne Methode Spam (und eMails ganz allgemein) zu vermeiden. Gut dass sich MTAs nur identifizieren.

Counselor schrieb:
Zur Authentifizierung: Wir haben etwa ein Dutzend firmeninterne MTAs. Die authentifizieren sich natürlich. 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. Genau wie ich sagt. Zum loswerden reicht allerdings ein einfacher Helo. Ausnahme ist SMTPAuth, was aber eigentlich ausschließlich zwischen MTA und Client, nicht von Relays untereinander gesprochen wird.


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

Counselor schrieb:
Die Frage, die ein MTA beantworten muß, lautet etwas anders: Darf ich von der IP-Adresse X eine Nachricht im Namen von Absender A für Empfänger B entgegennehmen? Das hat nichts damit zu tun, ob eine IP dynamisch über DHCP vergeben wird oder nicht oder ob die IP zu einem Rechner gehört, der sich über DFÜ eingewählt hat. Oder willst du Mails von einer kleinen Fa, die sich über DFÜ einwählt als SPAM abtun?
Wenn nach deiner Aussage relevant wäre, welche IP dahinter steckt, wäre DHCP sehr wohl relevant. Aber, glück gehabt, interessiert den MTA nicht. Dem reicht völlig, dass der helo im reverse-lookup mit der IP übereinstimmt. Deshalb kann man ja auch domain-ranges sperren, die ja mal mit IP-Adressen (abgesehen von dns) garnix zu tun haben.


Counselor schrieb:
Stimmt so auch nicht. Man überwacht den Mailverkehr auf den Servern mittels Mail Conditions auf zahlreiche Eigenschaften, und nicht nur auf SPAM. Eine von mehreren Dutzend Mail Conditions ist zB SPAM. Wenn die Condition SPAM anhand konfigurierbarer Regeln (=SPAM-Filter) durch einen Blicks in den Content der Mail festgestellt wird, dann wird der Mail-Deny Service aufgerufen. Der Mail Deny Service wird aber zB auch bei der Condition 'Attachement > 10 MB' aufgerufen oder wenn eine Mail aus einer unerwünschten Domäne kommt, ohne daß es zwingend SPAM sein muß.
Richtig ist: man stellt mehrere Conditions fest. Falsch ist: man guckt nicht nur auf den Content sondern ebenso auf den Header. Noch richtiger ist: es wird kein Mail-Deny Service aufgerufen, sondern die Mail wird verworfen und je nach Config eine Ablehnungsmail direkt wieder in die MTA an den Versender eingetütet. Bei negativem Spamergebnis droppt die MTA dann die Mail einfach ins passende Postfach.

An Biene

Der Mailserver von 1und1 meldet sich mit einem falschen helo. Das kann nur von 1und1 selbst behoben werden. Aber zur Beruhigung: bei mir hats die Mail am Spamassassin vorbei bis ins Postfach geschafft.
 
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 ...
 
Die ganzen Zitate nerven.

Ich beschränke mich auf einige wesentlichen Punkte:
Deamon->Daemon ... wie auch immer. Natürlic hat M$ keinen Daemon, weil sie keine MTA haben. Bei M$ bildet MTA, MUA un MDA einen monolithischen Block. Ergo entfällt jedes Geseier zu dem Thema.

Desweiteren hast zu keinem Zeitpunkt von Mailservern, sondern von Satelite-Systemen gesprochen. Da der original Punkt hier aber das Mailsystem von 1&1 ist, sagt mir irgendeine doofe Vorahnung, dass die nicht nur über POP3 ihre Mails von ihrem T-Online Anschluss abhören.

Die von dir beschriebenen Routinen zur Identifikation, werden vom SMTP Protokoll nicht unterstützt. SMTP kennt den Befehl AUTH nicht, es ist ein Mod für ESMTP und nicht zwingend in der Mailspezifikation vorgeschrieben.

And for the personal flavour: Postfix mit Spamassassin und abgleich mit der Sorbs Datenbank. - Ist mir lieber als ein Mailsystem, das so heißt wie ein Online-Rollenspiel
 
Zurück
Oben