Abweisung von Mails auf Grund fehlendem/falschen PTR-Record?
Klaus Peukert
Ist für MTAs ein PTR-Record, bzw. genauer eine korrekte
Rückwärtsauflösung vorgeschrieben und wenn ja, dürfen bei Fehlen
dieser Mails abgewiesen werden (Anti-Spam-policy etc.)?
Im konkreten Fall weist jemand Mails von einem Rechner ohne PTR-Record
ab, mit der Begründung aus RFC 1123, Punkt 6.1.1: "Every host MUST
implement a resolver for the Domain Name System (DNS), and it MUST
implement a mechanism using this DNS resolver to convert host names to
IP addresses and vice-versa."
Unter Punkt 1.2.2 aber vorher noch das Robustness Principle:
"At every layer of the protocols, there is a general rule whose
application can lead to enormous benefits in robustness and
interoperability: "Be liberal in what you accept, and
conservative in what you send""
Frage: Ist der RFC 1123 für SMTP überhaupt relevant oder wird er von
einem anderen evtl. "überstimmt"? Was ist mit virtuellen Hosts, bei
denen das reverse lookup auf nen kanonischen Namen zeigt. Es ist doch
Unsinn, den PTR-Record an der Stelle zu prüfen.
Für Anregungen und Hinweise wäre ich der versammelten Gemeinde
dankbar. Falls ich ne FAQ erwischt haben sollte, dann reicht ein
kurzer Verweis auf eine entsprechende Webseite oder Thread im Usenet.
Ein paar Diskussionen
Danke und mfg,
Klaus
Bernd Hohmann
> Ist für MTAs ein PTR-Record, bzw. genauer eine korrekte
> Rückwärtsauflösung vorgeschrieben und wenn ja, dürfen bei Fehlen
> dieser Mails abgewiesen werden (Anti-Spam-policy etc.)?
Irgendwo findet sich immer ein Netzpolizist, der das so macht und haben
will.
Ich selber halte es für Praxisfern, da die Reverse-Pointer idR. von den
Providern verwaltet werden welche die IP zur Verfügung stellen.
Wer das mal bei der DTAG für seine eigene Standleitung machen muss, der
kann das danach wirklich gut weil das Formular tausend Sachen abfragt
:-). Bei Tiscali brauchte ich nur eine kurze E-Mail und es war erledigt.
Mein jetziger Provider hat von selber nachgefragt.
Bei anderen Providern (gerade bei A/SDSL-Standleitungen) ist es oft so,
dass Standardnamen vergeben werden. Lauten die dann auf irgendwas mit
"ADSL" im Hostnamen, ist man auch der doofe weil dann paar kluge Filter
meinen, es käme von einem Dial-Up. Will man aber den PTR geändert haben,
muss man oft nochmal extra bezahlen.
> Unter Punkt 1.2.2 aber vorher noch das Robustness Principle:
> "At every layer of the protocols, there is a general rule whose
> application can lead to enormous benefits in robustness and
> interoperability: "Be liberal in what you accept, and
> conservative in what you send""
Leider hat diese Liberalität zu Missbrauch geführt. Man kann halt nur
zwischen Pest und Cholera wählen :-)
Bernd
Ullrich von Bassewitz
> Ist für MTAs ein PTR-Record, bzw. genauer eine korrekte
> Rückwärtsauflösung vorgeschrieben und wenn ja, dürfen bei Fehlen
> dieser Mails abgewiesen werden (Anti-Spam-policy etc.)?
"Duerfen" darf der Empfaenger immer - es gibt schliesslich keine Moeglichkeit,
ihn zu zwingen, Deine Mails anzunehmen. Ob es Sinn macht ist eine andere
Frage.
Meine Erfahrung ist, dass ein generelles Abweisen solcher Mails zu viele false
positives produziert um voll eingesetzt zu werden. Andererseits ist es in sehr
vielen Faellen ein Zeichen fuer Spam, weil bei schlecht administrierte Rechner
(und dazu rechne ich welche mit fehlendem RDNS) auch oft Sicherheitsprobleme
haben, die einen Missbrauch zum Versand von Spam erlauben. Zur Zeit mache ich
es so, dass ich nachts und am Wochenende keine Mails von Rechnern mit
fehlendem RDNS annehme. Das hat sich als hinreichend sicher herausgestellt,
weil zu den Zeiten selten wichtige Business Mails kommen. YMMV.
> Frage: Ist der RFC 1123 für SMTP überhaupt relevant oder wird er von
> einem anderen evtl. "überstimmt"? Was ist mit virtuellen Hosts, bei
> denen das reverse lookup auf nen kanonischen Namen zeigt. Es ist doch
> Unsinn, den PTR-Record an der Stelle zu prüfen.
Es gibt eine Menge Leute, die verwenden den PTR Record um Verbindungen von
Dialup oder ADSL Benutzern abzulehnen. Auch wenn das nicht im RFC erwaehnt
wird, ist es gaengige Praxis.
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
17:52:12 up 29 days, 19:46, 9 users, load average: 0.08, 0.02, 0.03
Jan Theofel
Hallo,
Klaus Peukert wrote:
>
> Ist für MTAs ein PTR-Record, bzw. genauer eine korrekte
> Rückwärtsauflösung vorgeschrieben und wenn ja, dürfen bei Fehlen
> dieser Mails abgewiesen werden (Anti-Spam-policy etc.)?
Wir machen das hier auch so und es hat sich hervorragend bewährt. ;-)
I.d.R. kannst du davon ausgehen, dass es sich bei Maschinen ohne PTR record
um schlecht konfigurierte Maschinen handelt von denen du sowieso keine Mail
haben willst.
Ausserdem kann ich ohne PTR record nicht den Reverse-Lookup auf Namensteile
wie "pool", "dialin", etc. durchsuchen, welche wir hier auch blocken.
Es gibt immer wieder False-Positives, die Leute rufen dann an und ich weise
Sie auf Ihr Problem hin. Meistens hilft der Hinweis auf
"AOL's mail servers will reject connections from any IP address that does not
have reverse DNS (a PTR record)."
weiter (Quelle: http://postmaster.info.aol.com/guidelines/standards.html).
Dann gehe die meistens ihren Admin hauen oder sie wechseln den Anbieter. ;-)
Jan
P.S.: Hendrik - wenn du das mitliest: Wir sollten unsere URL in der Info an-
passen. ;-)
--
Jan Theofel Fon: +49 (7 11) 48 90 83 - 0
ETES - EDV-Systemhaus GbR Fax: +49 (7 11) 48 90 83 - 50
Libanonstrasse 58 A * D-70184 Stuttgart Web: http://www.etes.de
Bernd Hohmann
>> Ist für MTAs ein PTR-Record, bzw. genauer eine korrekte
>> Rückwärtsauflösung vorgeschrieben und wenn ja, dürfen bei Fehlen
>> dieser Mails abgewiesen werden (Anti-Spam-policy etc.)?
>
> Wir machen das hier auch so und es hat sich hervorragend bewährt. ;-)
Na, zum Glück hat es noch keiner bemerkt.
> I.d.R. kannst du davon ausgehen, dass es sich bei Maschinen ohne PTR record
> um schlecht konfigurierte Maschinen handelt von denen du sowieso keine Mail
> haben willst.
Ernsthaft? Bei solchen Maschinen gehe ich eher davon aus, dass der
zugehörige Upstreamprovider (welcher der erste Ansprechpartner für die
RDNS der IP ist) kompliziert zu Handhaben ist.
> Ausserdem kann ich ohne PTR record nicht den Reverse-Lookup auf Namensteile
> wie "pool", "dialin", etc. durchsuchen, welche wir hier auch blocken.
Ja, auch sehr clever.
> Es gibt immer wieder False-Positives, die Leute rufen dann an und ich weise
> Sie auf Ihr Problem hin. Meistens hilft der Hinweis auf
>
> "AOL's mail servers will reject connections from any IP address that
> does not have reverse DNS (a PTR record)."
>
> weiter (Quelle: http://postmaster.info.aol.com/guidelines/standards.html).
>
> Dann gehe die meistens ihren Admin hauen oder sie wechseln den Anbieter.
> ;-)
Ich kenne das nur so: Irgendjemand filtert plötzlich meine Kunden. weil
als "MTA of the Day" heute nunmal "pool69.irgendwas.de" dran ist. Ich
rufe dann beim Betreiber des zuständigen Ziel-MTAs an und bitte ihn um
einen Eintrag in der Whitelist. Macht er das nicht, lasse ich das die
Geschäftsführer untereinander regeln.
Einen recht angenehmen Teil meines Umsatzes mache ich mit Kunden, die
mal bei Unternehmen wie Espenlaub & Schwofel waren wo die eigene
Ideologie mehr zählt als die Wünsche der Kunden.
Bernd
Klaus Peukert
>Ist für MTAs ein PTR-Record, bzw. genauer eine korrekte
>Rückwärtsauflösung vorgeschrieben und wenn ja, dürfen bei Fehlen
>dieser Mails abgewiesen werden (Anti-Spam-policy etc.)?
[...]
Hab inzwischen paar Threads in groups.google.com gefunden. Tendenz: So
richtig RFC-konform ist es nicht, man handelt sich vergleichsweise
viele false positives ein, dennoch machen es einige (u.a. wohl auch
AOL). Kurzum ein eher kontroverses Thema (a'la Blocken von DULs o.ä.).
Die einen sagen so, die anderen so.
Was mir noch aufgefallen ist: Welche *rechtlichen* Grundlagen,
Gesetze, Verordnungen, Bestimmungen etc. greifen hier, wenn man den
Server nicht privat sondern für Dritte verwaltet, also für Mitarbeiter
eines Unternehmens und/oder Kunden bspw.?
Darf man "einfach so" Mails auf Grund technischer/inhaltlicher
Kriterien direkt am Server filtern/abweisen, die für Dritte bestimmt
sind? Müssen Mitarbeiter darüber aufgeklärt werden und/oder dem
zustimmen? Welche Konsequenzen kann man erwarten, wenn man Mails
abweist, die )aus Sicht von Sender und Empfänger, also != Admin) dann
doch wichtig sind?
Wo kann ich mich darüber genauer informieren?
Xpost nach de.soc.recht.datennetze, Followup-To dahin ist gesetzt.
mfg,
Klaus
Bernd Hohmann
> Was mir noch aufgefallen ist: Welche *rechtlichen* Grundlagen,
> Gesetze, Verordnungen, Bestimmungen etc. greifen hier, wenn man den
> Server nicht privat sondern für Dritte verwaltet, also für Mitarbeiter
> eines Unternehmens und/oder Kunden bspw.?
>
> Darf man "einfach so" Mails auf Grund technischer/inhaltlicher
> Kriterien direkt am Server filtern/abweisen, die für Dritte bestimmt
> sind? Müssen Mitarbeiter darüber aufgeklärt werden und/oder dem
> zustimmen? Welche Konsequenzen kann man erwarten, wenn man Mails
> abweist, die )aus Sicht von Sender und Empfänger, also != Admin) dann
> doch wichtig sind?
Bauen wir einen Extremfall.
Provider filtert ohne das Wissen seiner Kunden nach irgendwelchen
obskuren "Geek" Kriterien den inbound.
Sein Kunde hat mit einem Auftraggeber vereinbart, dass er eine E-Mail
schickt wenn die Erfüllung eines 45Mio-Vertrages stattfinden soll
("Hallo Dieter, starte die Produktion für Auftrag 4711").
Die Mail kommt nicht an, es stellt sich heraus, dass sie im MTA des
Providers vernichtet wurde.
Es gibt einen Run der Gutachter und es wird Fahrlässigkeit mit Drang zum
Vorsatz festgestellt.
Am Ende hacken beide Seiten auf den Provider ein.
Die Zwischentöne kannst Du dir dann in etwa zusammenraten.
Zu Deiner Frage: per Definition müssen alle Filter mit einem in dieser
Sache vertretungsberechtigten Beauftragten des Kunden abgesprochen
werden, der sollte dringlichst seine Mitarbeiter darauf hinweisen bzw.
per Dienstverfügung bekannt machen.
Bei grossen und klagewütigen Kunden sollte man sich eigentlich wirklich
jede Änderung des Serverfilters schriftlich bestätigen lassen.
Bernd
Hatto von Hatzfeld
>
> Klaus Peukert wrote:
> >
> > Ist für MTAs ein PTR-Record, bzw. genauer eine korrekte
> > Rückwärtsauflösung vorgeschrieben und wenn ja, dürfen bei Fehlen
> > dieser Mails abgewiesen werden (Anti-Spam-policy etc.)?
>
> Wir machen das hier auch so und es hat sich hervorragend bewährt. ;-)
>
> I.d.R. kannst du davon ausgehen, dass es sich bei Maschinen ohne PTR
> record um schlecht konfigurierte Maschinen handelt von denen du
> sowieso keine Mail haben willst.
> Es gibt immer wieder False-Positives, die Leute rufen dann an und ich
> Dann gehe die meistens ihren Admin hauen oder sie wechseln den
> Anbieter. ;-)
Ich habe gestern t-mobile darauf hingewiesen, dass es sehr ungünstig
ist, wenn ihre IPs keine Rückwärtsauflösung haben. (Anlass war, dass ich
eine Mail von einem PDA/Handy im Spamfilter fand.)
Heute kam die Antwort, dass sie es ändern werden.
Ciao,
Hatto
--
Bewahre mich davor zu wissen, was ich nicht wissen muss. Bewahre mich
davor, auch nur zu wissen, dass es Wissenswertes gibt, von dem ich nichts
weiß. Bewahre mich davor zu wissen, dass ich beschlossen habe, nichts
von den Dingen zu wissen, die nicht zu wissen ich beschlossen habe. Amen.
Ullrich von Bassewitz
> Bauen wir einen Extremfall.
Kennt Du wirklich so einen Fall? Oder ueberhaupt einen Fall, in dem ein
Provider erfolgreich verklagt wurde, weil Mails nicht ankamen (aus welchen
Gruenden auch immer)?
Kann ich die Telekom verklagen, wenn mir telefonisch jemand einen Auftrag
geben will, und mein Anschluss tut gerade nicht? (oder noch extremer: es ist
gerade gassenbesetzt?)
Meiner Erfahrung nach nehmen die meisten Leute Mailaerger recht locker, weil
Email nicht als "sicheres" Medium empfunden wird. Spam, Virenmails, nicht
funktionierende Computer usw. sind alles bekannte Probleme. Wenn da mal eine
Mail verschwindet, dann erstaunt das keinen richtig.
> Die Mail kommt nicht an, es stellt sich heraus, dass sie im MTA des
> Providers vernichtet wurde.
Sowas macht man auch nicht. Dialups, ADSL Pools, Rechner ohne RDSN usw.
muessen immer einen Reject kriegen, dann hat der Absender eine Fehlermeldung
gekriegt, und der schwarze Peter ist in Zweifelsfall wieder beim Absender.
Zumindest wird er erklaeren muessen, warum er den wichtigen Auftrag nicht per
Post rausgeschickt hat, nachdem eine Fehlermail zurueck kam. Wobei sich
natuerlich generell die Frage stellt, wer solche Deals per Email abmacht.
Theoretisch hast Du natuerlich recht, filtern ohne Einverstaendniss des
Empfaengers ist unzulaessig, und auch nicht besonders klug von Seiten des
ISPs. Ich glaube aber kaum, dass dem ISP was passieren kann, insbesondere in
dem Fall wie Du ihn geschildert hast (Mail "verschwindet" einfach), weil dabei
von aussen ueberhaupt nicht geprueft werden kann, warum die Mail nicht
durchkam. Welcher ISP gibt seinen Kunden eine 100 prozentige
Verfuegbarkeitsgarantie, und welcher ISP kommt fuer Folgeschaeden wie die von
Dir erwaehnten auf? Solche Dinge werden immer per AGB ausgeschlossen. Im
aergsten Notfall gab es einen aeusserst bedauerlichen Hardware Defekt, oder
einen Konfigurationsfehler, dem die Mail zum Opfer fiel.
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
21:54:21 up 29 days, 23:48, 10 users, load average: 0.12, 0.06, 0.01
Ullrich von Bassewitz
> Bei anderen Providern (gerade bei A/SDSL-Standleitungen) ist es oft so,
> dass Standardnamen vergeben werden. Lauten die dann auf irgendwas mit
> "ADSL" im Hostnamen, ist man auch der doofe weil dann paar kluge Filter
> meinen, es käme von einem Dial-Up. Will man aber den PTR geändert haben,
> muss man oft nochmal extra bezahlen.
Ich habe seit ca. 6 Jahren eine Standleitung und habe dreimal aus
verschiedenen Gruenden den Anbieter gewechselt (das letzte Mal vor einem
Jahr). In allen Faellen war es selbstverstaendlich, dass mein IP Range korrekt
zu mir delegiert wurde, und zwar ohne zusaetzliche Kosten. Und auch keiner der
ISPs, von denen ich Angebote angefordert habe, hat die Delegation als separate
Leistung ausgewiesen.
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
22:23:43 up 30 days, 18 min, 10 users, load average: 0.02, 0.08, 0.06
Bernd Hohmann
>>Bauen wir einen Extremfall.
>
> Kennt Du wirklich so einen Fall?
"Bauen wir einen Extremfall" im Sinne von "Konstruieren wir einen
Extremfall". Oder "Konstruieren wir einen Worst-Case".
> Kann ich die Telekom verklagen, wenn mir telefonisch jemand einen Auftrag
> geben will, und mein Anschluss tut gerade nicht? (oder noch extremer: es ist
> gerade gassenbesetzt?)
Sicherlich kannst Du Sie verklagen. Bei einem ähnlichen Fall hat der
zuständige Sachbearbeiter am Ende gemeint "Sie können die Klage in Bonn
einreichen und bis das dann für uns 'ganz unten' - wenn überhaupt -
wirksam wird, bin ich schon längst in Rente. Und ich bin erst 27 Jahre alt".
Nach sehr kurzer Überlegungszeit habe ich festgestellt, dass es am Ende
stimmt.
> Meiner Erfahrung nach nehmen die meisten Leute Mailaerger recht locker, weil
> Email nicht als "sicheres" Medium empfunden wird. Spam, Virenmails, nicht
> funktionierende Computer usw. sind alles bekannte Probleme. Wenn da mal eine
> Mail verschwindet, dann erstaunt das keinen richtig.
Nun - meine Kundschaft ist da etwas verwöhnt.
> Theoretisch hast Du natuerlich recht, filtern ohne Einverstaendniss des
> Empfaengers ist unzulaessig, und auch nicht besonders klug von Seiten des
> ISPs.
Nicht nur Theoretisch.
Stell Dir vor, dein Provider installiert auf den Routern ein Tool, was
sich mit dem kompletten Protokoll einklinkt. Port 25 in Deine Richtung
wird analysiert und bei Missgefallen wird bei Dir ein Socketfehler
generiert und der Gegenseite gaukelt man vor, dass alles brav seinen
Gang geht.
Du würdest mit Sicherheit einen fürchterlichen Aufstand machen.
> Ich glaube aber kaum, dass dem ISP was passieren kann, insbesondere in
> dem Fall wie Du ihn geschildert hast (Mail "verschwindet" einfach), weil dabei
> von aussen ueberhaupt nicht geprueft werden kann, warum die Mail nicht
> durchkam.
Ein Sachverständiger Mensch könnte das zumindest eingrenzen wenn er die
beiderseitigen Logfiles diesbezüglich Abgleicht.
Manchmal geht das sogar noch einfacher, in dem man mal in den Ordner
"Gelöschte Mails" reinschaut. Da findet sich so manches Juwel.
> Welcher ISP gibt seinen Kunden eine 100 prozentige
> Verfuegbarkeitsgarantie, und welcher ISP kommt fuer Folgeschaeden wie die von
> Dir erwaehnten auf?
Bei grober Fahrlässigkeit: der Verursacher.
> Solche Dinge werden immer per AGB ausgeschlossen. Im
> aergsten Notfall gab es einen aeusserst bedauerlichen Hardware Defekt, oder
> einen Konfigurationsfehler, dem die Mail zum Opfer fiel.
Habe viele AGBs gesehen, alle problematisch. Die von Dir genannte
"Notfallmethode" ist natürlich weiterhin gültig.
Bernd
Bernd Hohmann
>>Bei anderen Providern (gerade bei A/SDSL-Standleitungen) ist es oft so,
>>dass Standardnamen vergeben werden. Lauten die dann auf irgendwas mit
>>"ADSL" im Hostnamen, ist man auch der doofe weil dann paar kluge Filter
>>meinen, es käme von einem Dial-Up. Will man aber den PTR geändert haben,
>>muss man oft nochmal extra bezahlen.
>
> An was fuer Provider denkst Du da?
Ich hatte neulich sowas mit einem Menschen, der an einer Schweizer SDSL
Leitung angebunden war.
"Cable"-Provider in DE kenne ich ausser der Telekom kaum welche da es in
meiner Gegend keinen anderen Anbieter gibt.
> Ich habe seit ca. 6 Jahren eine Standleitung und habe dreimal aus
> verschiedenen Gruenden den Anbieter gewechselt
Dann musst Du in einer Grosstadt wohnen. Ich habe nur Telekom oder nichts.
Bernd
Falko Eickel
[MTA-IPs ohne rDNS]
> Ich habe gestern t-mobile darauf hingewiesen, dass es sehr ungünstig
> ist, wenn ihre IPs keine Rückwärtsauflösung haben. (Anlass war, dass ich
> eine Mail von einem PDA/Handy im Spamfilter fand.)
> Heute kam die Antwort, dass sie es ändern werden.
Wenn die in dem Tempo arbeiten wie der Postmaster bei T-Offline,
dann mach' Dir besser eine Wiedervorlage für's nächste Jahr :-(.
Als das Thema neulich auf Heise landete, wusste ich schon ein
halbes Jahr lang davon, und damals berichteten mir die Teamies,
daß sie dem Postmaster schon etliche Wochen wegen der dämlichen
Fehlkonfiguration in den Ohren lägen und jetzt das Problem
behoben würde, nachdem sich nun auch jemand aus dem Mutterkonzern
beschwert hätte (meinereiner war damals nämlich im Network
Information Center der Telekom beschäftigt). Leider scheint das
wohl immer noch nicht Anstoß genug gewesen zu sein ...
CU/2 Falko
Ullrich von Bassewitz
>> Kennt Du wirklich so einen Fall?
>
> "Bauen wir einen Extremfall" im Sinne von "Konstruieren wir einen
> Extremfall". Oder "Konstruieren wir einen Worst-Case".
Zu gut deutsch: Du kennst keinen Fall, in dem wirklich mal ein Provider
erfolgreich wegen nicht ankommender Email verklagt wurde. Korrekt?
> > Welcher ISP gibt seinen Kunden eine 100 prozentige
>> Verfuegbarkeitsgarantie, und welcher ISP kommt fuer Folgeschaeden wie die von
>> Dir erwaehnten auf?
>
> Bei grober Fahrlässigkeit: der Verursacher.
*Du* bist derjenige, der das nachweisen musst. Und das duerfte unmoeglich
sein. In dem Moment, wo der Provider sagt "die Filterregel war ein Irrtum, die
war eigentlich fuer einen anderen Kunden gedacht" hat sich die Sache schon
erledigt, wenn Du nicht das Gegenteil beweisen kannst.
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
09:28:37 up 30 days, 11:22, 10 users, load average: 0.01, 0.05, 0.01
Ullrich von Bassewitz
>> Theoretisch hast Du natuerlich recht, filtern ohne Einverstaendniss
>> des Empfaengers ist unzulaessig,
>
Ja, Du hast voellig recht. Schwarzarbeit ist auch illegal, zumindest in der
BRD. Trotzdem werden in diesem Bereich jaehrlich hunderte von Milliarden Euro
umgesetzt. DVDs zu rippen ist illegal in Deutschland, trotzdem ist das eine
gaengige Beschaeftigung fuer Hunderttausende. Spam ist illegal in Deutschland,
und trotzdem trudeln zwanzig Stueck pro Tag hier ein, und ein paar hundert
weise ich schon am Eingang ab.
In der Theorie ist das alles illegal, in der Praxis ist es ein Unterschied, ob
etwas illegal ist, oder ob es tatsaechlich eine Moeglichkeit gibt, dagegen
vorzugehen.
>> Ich glaube aber kaum, dass dem ISP was passieren kann,
Genau dieser Ueberzeugung wollte ich mit meinem Beitrag Ausdruck verleihen:-)
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
09:34:02 up 30 days, 11:28, 10 users, load average: 0.00, 0.01, 0.00
Bernd Hohmann
>>"Bauen wir einen Extremfall" im Sinne von "Konstruieren wir einen
>>Extremfall". Oder "Konstruieren wir einen Worst-Case".
>
> Zu gut deutsch: Du kennst keinen Fall, in dem wirklich mal ein Provider
> erfolgreich wegen nicht ankommender Email verklagt wurde. Korrekt?
"Bis jetzt ist es gut gegeangen" sprach der Mann, als er am 14ten
Stockwerk vorbeiflog.
Bernd
Rolf Eike Beer
> Am Mittwoch, 14. Januar 2004 16:23 tippte Klaus Peukert:
>
>> Ist für MTAs ein PTR-Record, bzw. genauer eine korrekte
>> Rückwärtsauflösung vorgeschrieben und wenn ja, dürfen bei Fehlen
>> dieser Mails abgewiesen werden (Anti-Spam-policy etc.)?
>> [...]
>
> Ich kenne keine Regel/Papier, welche/s dagegen spricht.
> Ich betreibe auch einen /ganz kleinen/ SMTP-Server. Alles was keinen,
> oder keinen zur IP-Adresse passenden, Name mitbringt, darf nichts
> abladen.
> Wie mir die Logs zeigen handelt es sich bei den 'NoNames' eh nur um
> kaputte Rechner, oft aus dem Netz der Korea Telecom, Iskranet (ru),
> Chinanet-{SH|GD}, Asia Pacific On-line Services Inc oder Kornet.
> Und dann wird versucht Mails mit einem from=<7777...@777777777.com>
> o.ä. an Hunz und Kunz zu realyen.
> Der MTA beantwortet deratige Anfragen freundlich aber bestimmend mit:
> "554 Client host rejected: cannot find your hostname, [an.ip.add.ress]"
Jetzt ist die Frage was genau er meint, ich blicke das so ganz auch
nicht.
Also, gegeben sei ein Hist der uns eine Mail abliefern will. Der hat die
IP a.b.c.d und will eine Mail mit from <foo@invalid> abkippen.
Variante a) wenn zu a.b.c.d kein Reverse-Lookup existiert wird die Mail
abgelehnt. Das ist zwar irgendwie machbar, aber IMHO suboptimal. Ich
habe bei einigen meiner Maschinen auch keinen Reverse-Eintrag da mehrere
unterschiedliche Domains auf der selben Kiste laufen (und ausserdem
provider->uplink schlaeft).
Variante b) zu "invalid" kann weder ein A- noch ein MX-Eintrag gefunden
werden.
Diese Mails weise ich auch ab, ebenso wenn der MX auf 127.0.0.1 zeigt.
Wenn ich nicht mal einen bounce zurueckschicken kann will dort sowieso
niemand mit mir kommunizieren.
Eike
Falko Eickel
>> Ist für MTAs ein PTR-Record, bzw. genauer eine korrekte
>> Rückwärtsauflösung vorgeschrieben und wenn ja, dürfen bei Fehlen
>> dieser Mails abgewiesen werden (Anti-Spam-policy etc.)?
> Irgendwo findet sich immer ein Netzpolizist, der das so
> macht und haben will.
Tja, wer bei inzwischen etwa 70 Prozent Spam und Würmern
noch legitime E-Mail loswerden will, muß halt zeigen, daß er
sein System im Griff hat. Wer die Sache mit dem DNS nicht
versteht, der hat wahrscheinlich auch keinen Postmaster
Account (oder jedenfalls keinen, der gelesen wird) und nimmt
auch nichtzustellbare Mails an und bespammt damit das FROM
(ich schlage dafür mal den Begriff "Open Reverse-Relay" vor),
von "Ralsky-Open Relays" (Ralsky Relay Rape, SMTP-Auth
Attacke gegen M$ Exchange Server mit Guest-Accounts oder
generell Accounts mit schwachen Passwörtern) oder gar
klassischen Open Relays mal ganz abgesehen ...
> Ich selber halte es für Praxisfern, da die Reverse-Pointer idR. von den
> Providern verwaltet werden welche die IP zur Verfügung stellen.
Das ist in der Regel selbst bei DialUps kein Problem (mal
abgesehen davon, daß es eine DialUp-IP ist). Im HELO nennt
Deine Kiste dann Ihren DynDNS.org-Hostnamen, unter dem sie
wiederzufinden ist, dieser löst zu Deiner aktuellen IP auf.
Die wiederum löst zu einem Namen auf, der anschließend
auch wieder zu dieser IP auflöst. (Okay, in Asien gibt es
praktisch keine Reverse-Auflösung, und in Südamerika geht
oft die anschließende Vorwärts-Auflösung nicht, aber der
Anteil an erwünschten Mails aus diesen Gegenden ist für die
meisten Leute eh äußerst gering.)
> Wer das mal bei der DTAG für seine eigene Standleitung
> machen muss, der kann das danach wirklich gut weil das
> Formular tausend Sachen abfragt :-).
Wobei die größte Schwierigkeit darin besteht, das Teil
überhaupt zu finden. In der ersten Hälfte des letzten Jahres
ist es drei- oder viermal umgezogen. Wer den DNS komplett
von der Telekom machen läßt, bei dem wird zumindest bei
MX-Records gleich der passende PTR mitgesetzt, ich glaube
sogar für alle A-Records. Bei den Leuten, die den Forward-DNS
selber übernehmen, sieht das aber sehr oft beim Reverse-DNS
schlecht aus :-(.
> Bei Tiscali brauchte ich nur eine kurze E-Mail und es war
> erledigt. Mein jetziger Provider hat von selber nachgefragt.
E-Mail statt Formular geht bei der Telekom auch.
> Lauten die dann auf irgendwas mit "ADSL" im Hostnamen, ist
> man auch der doofe weil dann paar kluge Filter meinen, es
> käme von einem Dial-Up. Will man aber den PTR geändert
> haben, muss man oft nochmal extra bezahlen.
Mit Wirehub/Easynet DynaBlock wäre das nicht passiert (und
wenn doch, dann wäre das einfach zentral korrigiert worden).
Jetzt gibt's die Überreste der Liste aber nur noch bei Sorbs
(dul.dnsbl.sorbs.net) - falls Du noch Interesse hast, ich
habe mir den letzten Stand vor der Abschaltung (29./30.11.)
heruntergeladen, Du kannst das Zonefile dann nach Deinen
eigenen Wünschen für Deinen Mailer verwurschten ...
>> [Robustness Principle]
> Leider hat diese Liberalität zu Missbrauch geführt. Man
> kann halt nur zwischen Pest und Cholera wählen :-)
Solange man die kaputten Systeme sauber per 550er abweist,
kann das nicht schaden, ebensowenig wie die Verweigerung der
Annahme von elektronischem Gefahrgut (auch wenn letzteres
leider erst nach der DATA-Phase möglich ist, wenn man mal
vom "Big Boss" absieht). Wichtig ist eine vernünftige
Begründung, warum man die E-Mail nicht haben will (und daß
Postmaster und Abuse trotzdem erreichbar sind - ansonsten
kann man sich gleich selbst bei RFC-Ignorant eintragen).
Die einzig sinnvolle Vorgehensweise ist heute die, möglichst
viel direkt zu blocken, entweder direkt anhand der IP-Adresse
oder aufgrund der verwendeten Mailadressen. Zusätzlich sollte
während der DATA-Phase sowas wie SpamAssassin und ein Wurmerkenner
direkt mitlaufen, um die letzte vernünftige
Chance, dem echten Absender die Unerwünschtheit seiner Post
mitzuteilen, nicht zu verpassen.
Alles andere kostet mehr: Erst Übertragungsvolumen (das kann
sich durchaus auf einen vierstelligen Euro-Betrag belaufen),
eventuell auch eine Aufstockung der Bandbreite, CPU-Leistung
und Speicherplatz beim Mailsystem, Zeit der Mitarbeiter, bei
JHD (Just Hit Delete) werden dann plötzlich auch erwünschte
Mails gleich mit dem Spam entsorgt, ohne daß das irgendwem
auffallen würde, und an eine Wurmepedemie, die die ganze Firma
für eine Woche lahmlegt, möchte man erst gar nicht denken.
Dagegen sollte eine sinnvoll begründete Ablehnung einer
legitimen E-Mail höchstens für eine kurzfristige Erregung des
Absenders führen, die sich nach dem Hinweis, daß er seine
E-Mail an den 800 Pfund Gorilla unter den ISPs auch nicht
losgeworden wäre (obwohl man darüber trefflich streiten kann,
ob man AOL nun wirklich als ISP gelten lassen will), legen
beziehungsweise die sich dann gegen den eigenen Admin richten
sollte.
CU/2 Falko
Wolfgang Jäth
>
> Bauen wir einen Extremfall.
>
> Provider filtert ohne das Wissen seiner Kunden nach irgendwelchen
> obskuren "Geek" Kriterien den inbound.
>
> Sein Kunde hat mit einem Auftraggeber vereinbart, dass er eine E-Mail
> schickt wenn die Erfüllung eines 45Mio-Vertrages stattfinden soll
> ("Hallo Dieter, starte die Produktion für Auftrag 4711").
>
> Die Mail kommt nicht an, es stellt sich heraus, dass sie im MTA des
> Providers vernichtet wurde.
Das ist dann aber kein Fall vonn Abweisung (aka Reject), sondern von
kommentarloser Löschung.
Im übrigen würde man so einen Auftrag (insbesondere bei dieser
Größenordnung) wohl eher per Fax durchgeben (man 'schriftlich'), und zudem
telefonisch nachfragen; alles andere wäre IMHO bestenfalls fahrlässig ...
Wolf 'und jeder, der so ein Projekt ohne schriftlichen Auftrag startet, ist
selber schuld' gang
--
Bernd Hohmann
>>Irgendwo findet sich immer ein Netzpolizist, der das so
>>macht und haben will.
>
> Tja, wer bei inzwischen etwa 70 Prozent Spam und Würmern
> noch legitime E-Mail loswerden will, muß halt zeigen, daß er
> sein System im Griff hat.
Er? Eher sein Provider. Ausser man ist sein eigener Provider - das ist
aber nur selten der Fall.
Wer die Sache mit dem DNS nicht
> versteht, der hat wahrscheinlich auch keinen Postmaster
> Account (oder jedenfalls keinen, der gelesen wird) [...]
Das ist eher ein Problem der Software. Ich vergesse regelmässig einen
Postmaster in einer frischen Domain anzulegen. Aus diesem Grunde wird
das bei mir automatisch auf die Adresse des Systemverantwortlichen
verbogen und die muss angegeben sein, sonst startet der MTA nicht.
Die einzige Lösung wäre die Herausgabe eines "Admin-Führerscheins" mit
vorheriger Prüfung. Das wiederum will aber auch keiner.
>>Bei Tiscali brauchte ich nur eine kurze E-Mail und es war
>>erledigt. Mein jetziger Provider hat von selber nachgefragt.
>
> E-Mail statt Formular geht bei der Telekom auch.
Ja: man kann das Formular auch per E-Mail verschicken :-)
>>>[Robustness Principle]
>
>>Leider hat diese Liberalität zu Missbrauch geführt. Man
>>kann halt nur zwischen Pest und Cholera wählen :-)
>
> Solange man die kaputten Systeme sauber per 550er abweist,
> kann das nicht schaden,
Wenn Du eine Mail von mir abweist, ist mir das egal.
Wenn das aber eine Mail von einem meiner Kunden an einen Deiner Kunden
betrifft, werden wir sicherlich ganz schnell zu einer Einigung kommen.
> Dagegen sollte eine sinnvoll begründete Ablehnung einer
> legitimen E-Mail höchstens für eine kurzfristige Erregung des
> Absenders führen, die sich nach dem Hinweis, daß er seine
> E-Mail an den 800 Pfund Gorilla unter den ISPs auch nicht
> losgeworden wäre (obwohl man darüber trefflich streiten kann,
> ob man AOL nun wirklich als ISP gelten lassen will), legen
> beziehungsweise die sich dann gegen den eigenen Admin richten
> sollte.
Auch wieder wahr.
Bernd
Klaus Peukert
>Jetzt ist die Frage was genau er meint, ich blicke das so ganz auch
>nicht.
>
> Also, gegeben sei ein Hist der uns eine Mail abliefern will. Der hat die
>IP a.b.c.d und will eine Mail mit from <foo@invalid> abkippen.
<foo@valid> in dem Fall sogar. Das ist ja grad das Dumme, daß da ne
legitime (und vom Empfänger erwünschte!) nicht abgeworfen kann (auch
Mails an den Postmaster bouncen im Übrigen...).
> Variante a) wenn zu a.b.c.d kein Reverse-Lookup existiert wird die Mail
> abgelehnt. Das ist zwar irgendwie machbar, aber IMHO suboptimal.
Dies meinte ich. Der Gegenüber überprüft die IP des Einliefernden, zu
der IP muß ein PTR existieren, der auf einen Namen zeigt, der wiederum
vorwärts aufgelöst auf die IP zeigt. Fehlt der PTR oder landet der
nicht wieder beim HELO-Namen kassiert man den 550.
Mir ist unklar, wie man ernsthaft eine solche "Lösung" nutzen kann und
als Begründung mehr oder weniger immer ein "Von solchen Systemen kommt
eh nur Schrott" kommt. Wenn man keine Mail will, soll man halt keinen
Server betreiben.
> Ich habe bei einigen meiner Maschinen auch keinen Reverse-Eintrag da
> mehrere unterschiedliche Domains auf der selben Kiste laufen (und
> ausserdem provider->uplink schlaeft).
Bei der siginifikanten Anzahl von "korrekten" Hosts mit
fehlendem/"falschen" PTR-Eintrag ist diese Abweisung doch absoluter
Unsinn, wenn die Wahrscheinlichkeit damit nen nicht unerheblichen
Anteil legitimer Mail wegzuwerfen nicht vernachlässigt werden kann.
Schließlich kann man die Verbindung auch teergruben, nen X-Header
einsetzen, was ins Subject schreiben, den "Spam-Score" erhöhen oder
so. Aber bei dem Risiko, die Mails abzulehnen, daß kann man auf nem
privaten Host machen, der nur für einen selbst werkelt, aber doch
nicht wenn Dritte mit dranhängen.
mfg,
Klaus
Klaus Peukert
>Nur mal so am Rande:
>http://www.datenschutz-und-datensicherheit.de/jhrg27/heft0308.htm
Kommt man irgendwo an den ganzen Artikel ran?
>http://sadr.dfn.de/service/ra/vortraege/041202.pdf
Leider 404. Ich hab was unter
http://www.dfn.de/content/beratung-weiterbildung/rechtimdfn/handlungsempfehlung/
was ganz interessantes gefunden, war das damit gemeint?
>http://www.heise.de/ct/03/26/186/
Interessant. Gibts noch mehr/ähnliche Links?
Danke schonmal und mfg,
Klaus
Thomas Hühn
> Im konkreten Fall weist jemand Mails von einem Rechner ohne PTR-Record
> ab, mit der Begründung aus RFC 1123, Punkt 6.1.1: "Every host MUST
> implement a resolver for the Domain Name System (DNS), and it MUST
> implement a mechanism using this DNS resolver to convert host names to
> IP addresses and vice-versa."
>
> Unter Punkt 1.2.2 aber vorher noch das Robustness Principle:
> "At every layer of the protocols, there is a general rule whose
> application can lead to enormous benefits in robustness and
> interoperability: "Be liberal in what you accept, and
> conservative in what you send""
Du kannst ihm den SMTP-Dalog auch ausgedruckt auf Papier schicken; dem
robustness principle zufolge hat er sich ja dann damit rumzuschlagen.
Hast du irgendeinen Vertrag oder derartiges mit ihm, daß er von dir
Mails annehmen muß? Steht da drin, welche technischen Rahmenbedingungen
einzuhalten sind?
Insofern ist mir überhaupt nicht klar, warum du hier auf die rechtliche
Schiene willst.
Thomas
Jost Krieger
...
Abgesehen von den vielen hier ergangenen Hinweisen, dass
a) jeder Mailbetreiber (im Einvernehmen mit seinen Kunden) entscheidet,
welche Mails er annimmt,
b) es sowieso eine gute Idee ist, korrektes DNS zu haben,
hat dies hier
> Im konkreten Fall weist jemand Mails von einem Rechner ohne PTR-Record
> ab, mit der Begründung aus RFC 1123, Punkt 6.1.1: "Every host MUST
> implement a resolver for the Domain Name System (DNS), and it MUST
> implement a mechanism using this DNS resolver to convert host names to
> IP addresses and vice-versa."
nun auch überhaupt nichts mit der Existenz von Reverse-DNS zu tun.
Da steht doch nur, dass ein Host in der Lage sein muss, existierende
Records aufzulösen.
Gruß Jost |8-))
Klaus Peukert
>Du kannst ihm den SMTP-Dalog auch ausgedruckt auf Papier schicken; dem
>robustness principle zufolge hat er sich ja dann damit rumzuschlagen.
Ich denke uns beiden und den anderen Mitlesern ist Sinn und Intention
des "robustness principles" klar. Ansonsten verweis ich auf die
Fachbegriffe der Informatik:
106: robuschdness brincible
Des 'robuschdness brincible' dr IETF lauded nedd: 'Du darfsch Müll
sende.' und au nedd 'Du mussch Müll annehme.'. Viele Leide verkenne
dis. (Krischdian Koehndobb)
Ob ein fehlender PTR nun Müll ist...
>Hast du irgendeinen Vertrag oder derartiges mit ihm, daß er von dir
>Mails annehmen muß? Steht da drin, welche technischen Rahmenbedingungen
>einzuhalten sind?
Hab ich nicht. Ein User eines Servers, auf dem ich (mit) die Hände
drauf hab, wollte Mail an eine Domain schicken, deren MX einen
(tatsächlich) fehlenden PTR mit einem 550 bedenkt. Der PTR existiert
inzwischen, insofern ist das Problem erledigt.
>Insofern ist mir überhaupt nicht klar, warum du hier auf die rechtliche
>Schiene willst.
Ich such ne Argumentation für ebenjene Nutzer, daß der Gegenüber der
"Böse" ist und nicht der fehlende PTR. Die rechtliche Seite
interessiert mich eher generell und hat mit dem konkreten Fall
eigentlich nix zu tun. Letzlich such ich Informationen, die meine
Meinung, daß eine solche Filterung BAD ist, untermauern.
mfg,
Klaus
Ullrich von Bassewitz
> Mir ist unklar, wie man ernsthaft eine solche "Lösung" nutzen kann und
> als Begründung mehr oder weniger immer ein "Von solchen Systemen kommt
> eh nur Schrott" kommt.
Leider stimmt diese Begruendung. Ich kenne SpamAssassin und andere Spamfilter
nicht so gut, aber es wuerde mich sehr wundern, wenn diese bei fehlendem
Reverse Lookup nicht auch ein negatives Scoring vergeben wuerden.
> Wenn man keine Mail will, soll man halt keinen
> Server betreiben.
So eine Diskussion hatten wir schon oefters. Bloss weil ich einen
Telefonanschluss habe, bin ich nicht gezwungen, auch abzunehmen, wenn Du
anrufst. Bloss weil ich eine Tuer habe, brauche ich sie noch lange nicht
aufmachen, wenn Du davorstehst und klingelst. Und bloss weil ich einen
Mailserver betreibe brauche ich von Dir noch lange keine Mail anzunehmen.
> Bei der siginifikanten Anzahl von "korrekten" Hosts mit
> fehlendem/"falschen" PTR-Eintrag ist diese Abweisung doch absoluter
> Unsinn, wenn die Wahrscheinlichkeit damit nen nicht unerheblichen
> Anteil legitimer Mail wegzuwerfen nicht vernachlässigt werden kann.
Es geht nicht so sehr um "korrekte" Hosts, sondern um "korrekte" Mailserver.
Waehrend es bei einem Mail ausliefernden Dialup Host sein kann, dass dieser
Probleme mit dem DNS hat ist das bei offiziellen Mailservern nur sehr selten
der Fall. Und Mails von Dialups, ADSL Ranges, Kabelmodems usw. will man
meistens sowieso nicht haben.
> Schließlich kann man die Verbindung auch teergruben, nen X-Header
> einsetzen, was ins Subject schreiben, den "Spam-Score" erhöhen oder
> so. Aber bei dem Risiko, die Mails abzulehnen, daß kann man auf nem
> privaten Host machen, der nur für einen selbst werkelt, aber doch
> nicht wenn Dritte mit dranhängen.
Das Problem ist der enorm hohe Leidensdruck durch Spam. Und weil das noch
schlimmer werden wird, werden immer mehr Leute solche Massnahmen einsetzen.
Wer heutzutage Mails ueber einen Dialup ausliefert, hat wenig Chancen, dass
sie durchkommt. Das war vor zwei Jahren noch anders. Je laenger Du wartest,
desto kleiner werden Deine Chancen, von einem Host ohne RDSN aus Mail
auszuliefern.
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
16:56:54 up 30 days, 18:51, 9 users, load average: 0.01, 0.02, 0.00
Chris Kronberg
> Jan Theofel wrote:
>
> >> Ist für MTAs ein PTR-Record, bzw. genauer eine korrekte
> >> Rückwärtsauflösung vorgeschrieben und wenn ja, dürfen bei Fehlen
> >> dieser Mails abgewiesen werden (Anti-Spam-policy etc.)?
> >
> > Wir machen das hier auch so und es hat sich hervorragend bewährt. ;-)
>
> Na, zum Glück hat es noch keiner bemerkt.
Haeh? Ich hab auch gemerkt, dass es es hervorragend bewaehren kann.
> > I.d.R. kannst du davon ausgehen, dass es sich bei Maschinen ohne PTR record
> > um schlecht konfigurierte Maschinen handelt von denen du sowieso keine Mail
> > haben willst.
>
> Ernsthaft? Bei solchen Maschinen gehe ich eher davon aus, dass der
Ernsthaft.
> zugehörige Upstreamprovider (welcher der erste Ansprechpartner für die
> RDNS der IP ist) kompliziert zu Handhaben ist.
Wenn der Provider so schwierig ist, ist es vielleich tauch ein
Provider, der nicht so recht weiss, was er da tut. Insofern
nicht verkehrt.
> > Es gibt immer wieder False-Positives, die Leute rufen dann an und ich weise
> > Sie auf Ihr Problem hin. Meistens hilft der Hinweis auf
> >
> > "AOL's mail servers will reject connections from any IP address that
> > does not have reverse DNS (a PTR record)."
> >
> > weiter (Quelle: http://postmaster.info.aol.com/guidelines/standards.html).
> >
> > Dann gehe die meistens ihren Admin hauen oder sie wechseln den Anbieter.
> > ;-)
>
> Ich kenne das nur so: Irgendjemand filtert plötzlich meine Kunden. weil
> als "MTA of the Day" heute nunmal "pool69.irgendwas.de" dran ist. Ich
Ahjo, Kunde hat nur poolxyz und total vergessen, dass sein Provider
auch einen Mailserver hat, den er auch benutzen sollte und
freigeschaltet ist?! Wer traut schon dem, was von einem dialup
Account kommt.
Cheers,
Chris.
Frank Ellermann
> AOL
Genau. Ich seh auch keinen Bedarf fuer Admin-Fuehrerscheine,
so furchtbar kompliziert sind SMTP und DNS doch gar nicht.
Und jeder technische Vorwand, Mail _nicht_ anzunehmen, trifft
heute mit guter Wahrscheinlichkeit ohnehin unerwuenschte Mail.
Die ganzen abuse desks, die desinfizierte Wuermer fuer immer
noch gefaehrlich halten, oder die message/rfc822 fuer einen
ganz fiesen Dateianhang halten, sind aber laestig. Bye, Frank
Jan Theofel
Hallo,
Bernd Hohmann wrote:
> Jan Theofel wrote:
>
>>> Ist für MTAs ein PTR-Record, bzw. genauer eine korrekte
>>> Rückwärtsauflösung vorgeschrieben und wenn ja, dürfen bei Fehlen
>>> dieser Mails abgewiesen werden (Anti-Spam-policy etc.)?
>>
>> Wir machen das hier auch so und es hat sich hervorragend bewährt. ;-)
>
> Na, zum Glück hat es noch keiner bemerkt.
Doch, die Spammer haben es gemerkt... (Wenn sie ihre Bounces auswerten. ;-)
Durch solche Massnahmen habe ich es geschafft ca. 99% unseres kompletten
SPAM Aufkommens zu erschlagen. Den SA könnte ich fast abschalten, weil was
da noch durchkommt erkennt der i.d.R. auch nicht mehr und bekommt dann
sowieso eine Spezialbehandlung.
>> I.d.R. kannst du davon ausgehen, dass es sich bei Maschinen ohne PTR
>> record
>> um schlecht konfigurierte Maschinen handelt von denen du sowieso keine
>> Mail
>> haben willst.
>
> Ernsthaft? Bei solchen Maschinen gehe ich eher davon aus, dass der
> zugehörige Upstreamprovider (welcher der erste Ansprechpartner für die
> RDNS der IP ist) kompliziert zu Handhaben ist.
Ernsthaft. Heute habe ich erfahren, dass die Telekom angeblich keine
Reverse-Lookups für ihre Standleitungen einrichtet. Sollte das wirklich
wahr sein - was ich nicht glaube - ist das für mich noch ein Grund mehr
genau diese Checks zu fahren.
Es führt dazu, dass die Kunden zu technisch kompetenten Providern gehen
bzw. sich bei ihren aktuellen beschweren und so das Problem ggf. lösen.
Je höher der Leidensdruck, desto besser.
> Einen recht angenehmen Teil meines Umsatzes mache ich mit Kunden, die
> mal bei Unternehmen wie Espenlaub & Schwofel waren wo die eigene
> Ideologie mehr zählt als die Wünsche der Kunden.
Die, die es haben, wissen es, wollen es und sind glücklich. Was will man
mehr?
Jan
--
Jan Theofel Fon: +49 (7 11) 48 90 83 - 0
ETES - EDV-Systemhaus GbR Fax: +49 (7 11) 48 90 83 - 50
Libanonstrasse 58 A * D-70184 Stuttgart Web: http://www.etes.de
Nils Bronstert
> > Wer das mal bei der DTAG für seine eigene Standleitung
> > machen muss, der kann das danach wirklich gut weil das
> > Formular tausend Sachen abfragt :-).
>
> Wobei die größte Schwierigkeit darin besteht, das Teil
> überhaupt zu finden. In der ersten Hälfte des letzten Jahres
> ist es drei- oder viermal umgezogen. Wer den DNS komplett
> von der Telekom machen läßt, bei dem wird zumindest bei
> MX-Records gleich der passende PTR mitgesetzt, ich glaube
> sogar für alle A-Records. Bei den Leuten, die den Forward-DNS
> selber übernehmen, sieht das aber sehr oft beim Reverse-DNS
> schlecht aus :-(.
Wobei man auch den Reverse-Lookup an den Kunden delegieren kann, auch
wenn dieser kein ganzes Class C hat. Siehe dazu RFC 2317 (übrigens imho
eine schöne Idee, das Problem zu umgehen).
> > Leider hat diese Liberalität zu Missbrauch geführt. Man
> > kann halt nur zwischen Pest und Cholera wählen :-)
>
> Solange man die kaputten Systeme sauber per 550er abweist,
> kann das nicht schaden, ebensowenig wie die Verweigerung der
> Annahme von elektronischem Gefahrgut (auch wenn letzteres
> leider erst nach der DATA-Phase möglich ist, wenn man mal
> vom "Big Boss" absieht). Wichtig ist eine vernünftige
> Begründung, warum man die E-Mail nicht haben will (und daß
> Postmaster und Abuse trotzdem erreichbar sind -
Ja.
> ansonsten
> kann man sich gleich selbst bei RFC-Ignorant eintragen).
Wobei ich einige wenige Ausnahmen, die manche Leute davon machen,
durchaus nachvollziehen kann (z. B. postmaster (oder war es abuse?) bei
Spamhaus - für nähere Infos auf news.admin.net-abuse.email
"groups-googlen").
> Die einzig sinnvolle Vorgehensweise ist heute die, möglichst
> viel direkt zu blocken,
Ja, wobei man schon gewissenhaft auswählen sollte. Zumindest, wenn man
Wert auf E-Mail legt.
> entweder direkt anhand der IP-Adresse
> oder aufgrund der verwendeten Mailadressen. Zusätzlich sollte
> während der DATA-Phase sowas wie SpamAssassin und ein Wurmerkenner
> direkt mitlaufen, um die letzte vernünftige
> Chance, dem echten Absender die Unerwünschtheit seiner Post
> mitzuteilen, nicht zu verpassen.
Ja, wobei letzteres schon auch sehr viel Resourcen kostet. Das kann
unter Umständen, beig größeren Mailservern, wirklich Kohle kosten. Aber
bei der Verwendung von guten Blocklisten, kann man darauf durchaus
(noch) verzichten.
> Alles andere kostet mehr: Erst Übertragungsvolumen (das kann
> sich durchaus auf einen vierstelligen Euro-Betrag belaufen),
> eventuell auch eine Aufstockung der Bandbreite, CPU-Leistung
> und Speicherplatz beim Mailsystem, Zeit der Mitarbeiter, bei
> JHD (Just Hit Delete) werden dann plötzlich auch erwünschte
> Mails gleich mit dem Spam entsorgt, ohne daß das irgendwem
> auffallen würde,
Ja, ganz meine Meinung. Der Spam ist inzwischen so zahlreich, daß wohl
deutlich mehr Mails verloren gehen, wenn man keine Gegenmaßnahmen
einrichtet, als wenn man strikt und umfassend blockt - vor allem
spammerfreundliche Provider bringen auch als Prävention so einiges. Ich
bin immer wieder erstaunt über die Effektivität von SPEWS (und Spamhaus)
bei doch sehr sehr wenigen legitimen Mails, die geblockt werden, die man
im Falle von SPEWS aber evtl. sowieso nicht möchte.
> und an eine Wurmepedemie, die die ganze Firma
> für eine Woche lahmlegt, möchte man erst gar nicht denken.
Ja, wobei ich da hauptsächlich an die Menge der Mails denke, denn
ausführbare Anhänge sollten sowieso tabu sein.
> Dagegen sollte eine sinnvoll begründete Ablehnung einer
> legitimen E-Mail höchstens für eine kurzfristige Erregung des
> Absenders führen, die sich nach dem Hinweis, daß er seine
> E-Mail an den 800 Pfund Gorilla unter den ISPs auch nicht
> losgeworden wäre (obwohl man darüber trefflich streiten kann,
> ob man AOL nun wirklich als ISP gelten lassen will),
;-)
> legen
> beziehungsweise die sich dann gegen den eigenen Admin richten
> sollte.
Ja, wobei das manche komischerweise nur sehr langsam einsehen
können. Liegt wohl an einer völligen Fehleinschätzung der Struktur des
Internets. Das wird wohl von vielen wie ein Dienst einer einzigen großen
Firma angesehen, was es zum Glück nicht ist.
Gruß
--
Nils Bronstert /// C= Amiga ,''`. In a world without
mailto:bro...@fh-worms.de /// PPC 604e 266 MHz : :' : walls and fences,
\\\/// 68060 50 MHz `. `' nobody needs
\XX/ Debian GNU/Linux `- Windows and Gates.
Nils Bronstert
> > Tja, wer bei inzwischen etwa 70 Prozent Spam und Würmern
> > noch legitime E-Mail loswerden will, muß halt zeigen, daß er
> > sein System im Griff hat.
>
> Er? Eher sein Provider.
Den, bzw. den Verantwortlichen meint er wohl ...
> Ausser man ist sein eigener Provider - das ist
> aber nur selten der Fall.
>
> > Wer die Sache mit dem DNS nicht
> > versteht, der hat wahrscheinlich auch keinen Postmaster
> > Account (oder jedenfalls keinen, der gelesen wird) [...]
>
> Das ist eher ein Problem der Software. Ich vergesse regelmässig einen
> Postmaster in einer frischen Domain anzulegen.
Ich habe ein spezielles Alias-File, das vor den kundenspezifischen
Alias-Files abgearbeitet wird. Darin steht z. B. postmaster drin, so daß
*alle* postmaster-Adressen *aller* Domains auf meinen Account
gehen. Ausnahmen sind nur Kunden-Mailserver, bei denen der MX der
betreffenden Domain dann aber sowieso auf deren Server und nicht auf
unseren Mailserver zeigt.
> Aus diesem Grunde wird
> das bei mir automatisch auf die Adresse des Systemverantwortlichen
> verbogen und die muss angegeben sein, sonst startet der MTA nicht.
Ähm, wer soll denn ansonsten die postmaster-Mail bekommen, wenn nicht
der Systemverantwortliche für den Mailserver?
> Die einzige Lösung wäre die Herausgabe eines "Admin-Führerscheins" mit
> vorheriger Prüfung. Das wiederum will aber auch keiner.
Ja, das wäre realitätsfern.
> [...]
> > Solange man die kaputten Systeme sauber per 550er abweist,
> > kann das nicht schaden,
>
> Wenn Du eine Mail von mir abweist, ist mir das egal.
>
> Wenn das aber eine Mail von einem meiner Kunden an einen Deiner Kunden
> betrifft, werden wir sicherlich ganz schnell zu einer Einigung kommen.
So? Ich würde mal sagen, das kommt *ausschließlich* auf den anderen
Kunden an, nicht auf Deinen (mal abgesehen, daß dieser dem anderen
Kunden sicher keine positiven Sachen erzählen würde). Denn was für eine
vertragliche Vereinbarung solltest *Du* mit dem Kunden des anderen
Providers haben? Wenn Du diese nicht hast, dann bist Du schließlich auf
sein Wohlwollen beim Annehmen von E-Mails angewiesen. Er macht das
schließlich *kostenlos* und *freiwillig*, obwohl es für ihn Kosten
verursacht.
> > Dagegen sollte eine sinnvoll begründete Ablehnung einer
> > legitimen E-Mail höchstens für eine kurzfristige Erregung des
> > Absenders führen, die sich nach dem Hinweis, daß er seine
> > E-Mail an den 800 Pfund Gorilla unter den ISPs auch nicht
> > losgeworden wäre (obwohl man darüber trefflich streiten kann,
> > ob man AOL nun wirklich als ISP gelten lassen will), legen
> > beziehungsweise die sich dann gegen den eigenen Admin richten
> > sollte.
>
> Auch wieder wahr.
Ja.
Im obigen Fall wird der Provider des anderen Kunden höchstwahrscheinlich
seinem Provider das Problem schildern und dieser wird Deinen Kunden in
die Whitelist aufnehmen, schließlich will er seinen Kunden nicht
verlieren. Aber einen Anspruch darauf hast Du nicht, höchstens evtl. (je
nach AGB bzw. Vertrag) der andere Kunde). Der Kunde des anderen
Providers könnte natürlich auch sagen, daß ihm der Spam-Block wichtiger
ist, als die Mail Deines Kunden. Dann wäre die Sache sogar noch klarer.
Nils Bronstert
> Ist für MTAs ein PTR-Record, bzw. genauer eine korrekte
> Rückwärtsauflösung vorgeschrieben
Vorgeschrieben ist im Internet nichts, wenn Du niemanden mit Deinen
Aktionen belästigst/schädigst. Das dürfte hier nicht der Fall sein. Wenn
Du mit "vorgeschrieben" die Internet-Standards, die sogenannten RFCs
(ja, die RFCs sind keine "echten" Standards) meinst, dann ist das
so. Eine Rückwärtsauflösung sollte vorhanden sein. Es gibt meiner
Meinung nach auch keinen einzigen Grund, keine oder eine falsche zu
haben. Wenn Du keine oder eine falsche hast, dann ist Dein Provider
inkompetent.
> und wenn ja, dürfen bei Fehlen
> dieser Mails abgewiesen werden (Anti-Spam-policy etc.)?
Grundsätzlich darf der Empfänger alles. Er nimmt Deine Mails schließlich
normalerweise kostenlos und ohne vertragliche oder sonstige
Gegenleistung von Dir an. Ein Empfänger kann also durchaus alle Mails
von Providern ablehnen, deren Admin ein grünes Auto fährt oder von allen
ungeraden IP-Adressen oder von allen Leuten, die "Hinz" oder "Kunz" mit
Vornamen heißen oder eben von allen Servern, die keinen oder einen
falschen PTR-Record haben. Ob das sinnvoll ist, kann nur der Empfänger
für sich entscheiden. Zulässig ist es in jedem Fall, es sei denn Du hast
einen entsprechenden Vertrag mit dem Empfänger, daß dieser zusagt Deine
Mails nicht abzulehnen. Das würde natürlich kaum jemand unterschreiben.
> Im konkreten Fall weist jemand Mails von einem Rechner ohne PTR-Record
> ab, mit der Begründung aus RFC 1123, Punkt 6.1.1: "Every host MUST
> implement a resolver for the Domain Name System (DNS), and it MUST
> implement a mechanism using this DNS resolver to convert host names to
> IP addresses and vice-versa."
So ist das, ja. Der Empfänger scheint sich gut auszukennen und weiß
offensichtlich, was er tut.
> Unter Punkt 1.2.2 aber vorher noch das Robustness Principle:
> "At every layer of the protocols, there is a general rule whose
> application can lead to enormous benefits in robustness and
> interoperability: "Be liberal in what you accept, and
> conservative in what you send""
Ja, den gibt es auch. Leider muß der aber wegen der Spammer hie und da
etwas eingeschränkt werden, einfach weil es sonst gar nicht mehr
funktioniert. Beschwer Dich bei den Spammern.
> Frage: Ist der RFC 1123 für SMTP überhaupt relevant
Ja, ist er.
> oder wird er von
> einem anderen evtl. "überstimmt"?
Hmm, gute Frage. Im RFC 2822 für Mail steht z. B., daß man im HELO/EHLO
ein sogenanntes IP-Literal (eine IP-Adresse in eckigen Klammern) angeben
kann, wenn kein Domainname existiert. Es wird aber nicht näher erklärt,
wann das passieren kann. Jedenfalls ist es auch dort eher so
geschrieben, daß es die Ausnahme sein sollte.
Letztendlich bist Du auf der sicheren Seite, wenn Du den Reverse-Lookup
einfach aktivierst bzw. korrigierst.
> Was ist mit virtuellen Hosts, bei
> denen das reverse lookup auf nen kanonischen Namen zeigt. Es ist doch
> Unsinn, den PTR-Record an der Stelle zu prüfen.
Warum? Ist doch kein Problem. Jeder vernünftige Mailer prüft erst
IP->Name, dann Name->IP. Wenn die resultierende IP mit der ersten IP
übereinstimmt ist doch alles OK. Nur wenn sie nicht stimmt, hat man es
meist mit einem vom Spammer aufgesetzten DNS-Server zu tun, der einen
nicht ihm gehörenden Domainnamen verwenden möchte. Wenn kein
Reverse-Lookup existiert sind es meist auch Spammer, die Beschwerden
erschweren wollen oder es ist ein unfähiger Provider. Dann solltest Du
ihn aus sein Problem hinweisen oder gegebenenfalls wechseln.
> Für Anregungen und Hinweise wäre ich der versammelten Gemeinde
> dankbar. Falls ich ne FAQ erwischt haben sollte, dann reicht ein
> kurzer Verweis auf eine entsprechende Webseite oder Thread im Usenet.
> Ein paar Diskussionen
Was spräche dagegen, einen korrekten Reverse-Lookup einzurichten? Ist
doch kein Problem, macht die Sache einfacher. Es gibt imho keinen
einzigen vernünftigen Grund dafür keinen oder einen falschen
Reverse-Lookup zu haben.
Nils Bronstert
> > Frage: Ist der RFC 1123 für SMTP überhaupt relevant oder wird er von
> > einem anderen evtl. "überstimmt"? Was ist mit virtuellen Hosts, bei
> > denen das reverse lookup auf nen kanonischen Namen zeigt. Es ist doch
> > Unsinn, den PTR-Record an der Stelle zu prüfen.
>
> Dialup oder ADSL Benutzern abzulehnen.
Ja, leider.
> Auch wenn das nicht im RFC erwaehnt
> wird,
Es ist aber laut meiner Interpretation der RFCs eher schlecht.
> ist es gaengige Praxis.
Ja, leider. Es macht die Dial-Up-User zu Internetusern zweiter
Klasse. Ich finde viele Blockmethoden wie z. B. die Verwendung von DSBL,
SPEWS, Spamhaus usw. als sehr empfehlenswert, aber das Blocken von
dial-Up-Usern finde ich nicht gut. Aber das ist natürlich nur meine
Meinung. Und grundsätzlich gilt natürlich immer "dein Rechner, deine
Regeln" - etwas, was Spammer nicht verstehen (wollen). Insofern kann ich
nur hoffen, daß andere das Problem bei Blocklisten für dynamische IPs
ebenso sehen, wie ich.
Nils Bronstert
> > Ist für MTAs ein PTR-Record, bzw. genauer eine korrekte
> > dieser Mails abgewiesen werden (Anti-Spam-policy etc.)?
>
> will.
Jaja, die bösen Netzpolizisten ...
> Ich selber halte es für Praxisfern, da die Reverse-Pointer idR. von den
> Providern verwaltet werden welche die IP zur Verfügung stellen.
Und was genau hat das mit dem Reverse-Lookup zu tun? T-Online hat auch
einen korrekten Reverse-Lookup ihrer Dial-Up-IP-Adressen ...
> Wer das mal bei der DTAG für seine eigene Standleitung machen muss, der
> kann das danach wirklich gut weil das Formular tausend Sachen abfragt
> :-).
Tja, das liegt aber sicher nicht daran, daß es für den Provider
kompliziert wäre, das einzurichten.
Außerdem: Hat die IP denn vorher keinen korrekten Reverse-Lookup? Würde
mich wundern. Bei den Dial-Up-IPs ist ja auch alles OK.
> Bei Tiscali brauchte ich nur eine kurze E-Mail und es war erledigt.
> Mein jetziger Provider hat von selber nachgefragt.
Du siehst, es ist offenbar kein Problem.
> Bei anderen Providern (gerade bei A/SDSL-Standleitungen) ist es oft so,
> dass Standardnamen vergeben werden. Lauten die dann auf irgendwas mit
> "ADSL" im Hostnamen, ist man auch der doofe weil dann paar kluge Filter
> meinen, es käme von einem Dial-Up.
Das ist aber wieder ein *völlig* anderes Problem.
> Will man aber den PTR geändert haben,
> muss man oft nochmal extra bezahlen.
Tja, "you get what you pay for" ...
> > Unter Punkt 1.2.2 aber vorher noch das Robustness Principle:
> > "At every layer of the protocols, there is a general rule whose
> > application can lead to enormous benefits in robustness and
> > interoperability: "Be liberal in what you accept, and
> > conservative in what you send""
>
> Leider hat diese Liberalität zu Missbrauch geführt. Man kann halt nur
> zwischen Pest und Cholera wählen :-)
Eben.
Ich muß sagen, daß das Blocken aufgrund fehlendem oder falschen
Reverse-Lookup bei uns geschätzt deutlich über 80% aller Spams killen
würde. Allerdings würde es wohl auch geschätzte knapp 1% aller legitimen
Mails killen. Das ist uns zu viel. Aber die Verlockung ist
zugegebenermaßen dennoch groß ...
Leider würde diese "Lösung" wohl auch nur ein paar Monate bis maximal
ein halbes Jahr halten, wenn alle sie anwenden würden, weil die Spammer
nachziehen würden. Aber wenigstens würden die oben erwähnten 1% endlich
ihre Fehlkonfiguration beheben und man könnte Spammer etwas einfacher
lokalisieren.
Nils Bronstert
> > Ich kenne das nur so: Irgendjemand filtert plötzlich meine Kunden. weil
> > als "MTA of the Day" heute nunmal "pool69.irgendwas.de" dran ist. Ich
>
> Ahjo, Kunde hat nur poolxyz und total vergessen, dass sein Provider
> auch einen Mailserver hat, den er auch benutzen sollte und
> freigeschaltet ist?! Wer traut schon dem, was von einem dialup
> Account kommt.
Dialup hat mit fehlendem oder falschem PTR übrigens nichts zu tun.
Desweiteren gibt es durchaus Gründe mit einem Dialup-Rechner Mails zu
senden (zu empfangen eher weniger, wegen diverser Probleme zumindest bei
den bei Dial-Up-Rechnern meist (aber nicht immer) verwendeten
dynamischen IPs). Aber es gilt natürlich immer "your server your rules".
Nils Bronstert
> I.d.R. kannst du davon ausgehen, dass es sich bei Maschinen ohne PTR record
> haben willst.
Das wird sich in Zukunft bei steigendem Spamaufkommen sicher in diese
Richtung bewegen, ja. Würde mich jedenfalls nicht stören, im Gegenteil.
> Ausserdem kann ich ohne PTR record nicht den Reverse-Lookup auf Namensteile
> wie "pool", "dialin", etc. durchsuchen, welche wir hier auch blocken.
Uh, das kann aber auch ziemlich schief gehen. Habt Ihr wenigstens eine
Ausnahmeliste? Denn einige SDSL-Leitungen mit festen IP-Adressen haben
auch solche Namen.
Ich mag dyn-Blocks aber sowieso nicht, weil sie das Internet zu einem
Zwei-Klassen-System machen.
> Es gibt immer wieder False-Positives, die Leute rufen dann an und ich weise
> Sie auf Ihr Problem hin. Meistens hilft der Hinweis auf
>
> "AOL's mail servers will reject connections from any IP address that does not
> have reverse DNS (a PTR record)."
Ist das tatsächlich so oder drohen sie das nur an?
> weiter (Quelle: http://postmaster.info.aol.com/guidelines/standards.html).
Sie machen wohl tatsächlich ernst. Hätte ich nicht gedacht. Naja, dann
wird man das in ein paar Monaten wohl überall anwenden können, denn an
AOL muß praktisch jeder Provider senden können, sonst verliert er zu
viele Kunden. Somit dürfte es in Kürze nur noch sehr wenige Provider
geben, die einen Mailserver ohne Reverse-Lookup betreiben. Ob der
Reverse-Lookup dann nochmals "normal" aufgelöst wieder zur gleichen IP
führt (also ob er korrekt ist), ist natürlich nochmal eine Stufe
strenger.
> Dann gehe die meistens ihren Admin hauen oder sie wechseln den Anbieter. ;-)
Hehe, ;-)
Nils Bronstert
> Jetzt ist die Frage was genau er meint, ich blicke das so ganz auch
> nicht.
>
> Also, gegeben sei ein Hist der uns eine Mail abliefern will. Der hat die
> IP a.b.c.d und will eine Mail mit from <foo@invalid> abkippen.
Was fürn "from" meinst Du? Den Envelope oder das "From: " im Header?
> Variante a) wenn zu a.b.c.d kein Reverse-Lookup existiert wird die Mail
> abgelehnt. Das ist zwar irgendwie machbar, aber IMHO suboptimal.
Ist sehr einfach machbar. Und einige machen das offenbar auch.
> Ich
> habe bei einigen meiner Maschinen auch keinen Reverse-Eintrag da mehrere
> unterschiedliche Domains auf der selben Kiste laufen
Das ist doch kein Grund. Warum kann ein Server, auf dem unterschiedliche
Domains laufen, keinen Reverse-Eintrag haben? Ein Reverse-Eintrag heißt
ja nicht, daß eine IP auf mehrere Namen aufgelöst werden sollte (das
geht zwar, wird aber von praktisch keiner Software unterstützt und ist
deshalb auch nicht zu empfehlen). Im Gegenteil. Eine IP sollte genau auf
einen FQDN aufgelöst werden, der wiederum zur gleichen IP aufgelöst
werden sollte. Wenn Dein Mailserver also z. B. die IP 192.168.0.2 hat
und die Namen mail.domain.example, kunde1.domain.example,
www.kunde2.example usw., dann sollte die IP 192.168.0.2 z. B. einen PTR
auf mail.domain.example haben und mail.domain.example einen A-Record auf
192.168.0.2. So einfach ist das.
Wie gesagt, es gibt genau *keinen* Grund dafür, keinen Reverse-Lookup zu
haben.
> (und ausserdem
> provider->uplink schlaeft).
Das wär ein Grund - ein Grund, den Provider zu wechseln ...
> Variante b) zu "invalid" kann weder ein A- noch ein MX-Eintrag gefunden
> werden.
Wenn Du oben das "MAIL FROM:" meintest, ja. Das ist ja ein heutzutage
schon fast üblicher Check. Bei kleineren Mailservern kann man mit dem
sogenannten Sender-Callback auch prüfen, ob der Absender samt Local-Part
wirklich existiert.
> Diese Mails weise ich auch ab, ebenso wenn der MX auf 127.0.0.1 zeigt.
> Wenn ich nicht mal einen bounce zurueckschicken kann will dort sowieso
> niemand mit mir kommunizieren.
Jep.
Nils Bronstert
> > Variante a) wenn zu a.b.c.d kein Reverse-Lookup existiert wird die Mail
> > abgelehnt. Das ist zwar irgendwie machbar, aber IMHO suboptimal.
>
> Dies meinte ich. Der Gegenüber überprüft die IP des Einliefernden, zu
> der IP muß ein PTR existieren, der auf einen Namen zeigt, der wiederum
> vorwärts aufgelöst auf die IP zeigt. Fehlt der PTR oder landet der
> nicht wieder beim HELO-Namen kassiert man den 550.
Ähm, Du meinst wohl "... oder landet der Name nicht wieder bei der IP,
kassiert man den 550.", oder? Denn das HELO/EHLO zu prüfen ergibt schon
so einige False-Positives und widerspricht auch dem RFC, der nur eine
Syntaxprüfung zuläßt. Man kann den HELO/EHLO z. B. darauf prüfen, daß er
keine "illegalen" Zeichen wie z. B. Umlaute oder den (allerdings leider
recht beliebten) Unterstrich "_" enthält. Denn eigentlich muß das HELO
ein FQDN oder zur Not ein IP-Literal sein. Somit dürfen syntaktisch
gesehen keine Sonderzeichen vorkommen. Laut RFC darf man das HELO/EHLO
aber nicht auf Korrektheit, was den FQDN oder die IP angeht, überprüfen.
> Mir ist unklar, wie man ernsthaft eine solche "Lösung" nutzen kann und
> als Begründung mehr oder weniger immer ein "Von solchen Systemen kommt
> eh nur Schrott" kommt. Wenn man keine Mail will, soll man halt keinen
> Server betreiben.
Jeder, der einen Server betreibt, darf natürlich die Regeln für seinen
Server selbst bestimmen. Schließlich mußt Du ihm ja keine Mail schicken.
Sagen wir also lieber: Man sollte vorsichtig sein mit dem, was man
blockt, sonst verliert man evtl. Mails, die man eigentlich haben wollte.
> > Ich habe bei einigen meiner Maschinen auch keinen Reverse-Eintrag da
> > mehrere unterschiedliche Domains auf der selben Kiste laufen (und
> > ausserdem provider->uplink schlaeft).
>
> Bei der siginifikanten Anzahl von "korrekten" Hosts mit
> fehlendem/"falschen" PTR-Eintrag
Es gibt keine korrekten Hosts mit fehlendem oder falschem PTR-Eintrag,
nur falsch konfigurierte. Es gibt höchstens Hosts mit falschem/fehlendem
PTR-Eintrag, die dennoch keine Spams senden. Das sind aber zum Glück
relativ wenige, auch wenn ich zustimmen muß, daß die Anzahl deutlich
über Null liegt.
> ist diese Abweisung doch absoluter
> Unsinn, wenn die Wahrscheinlichkeit damit nen nicht unerheblichen
> Anteil legitimer Mail wegzuwerfen nicht vernachlässigt werden kann.
Aber das kann nur der Serverbetreiber des annehmenden Hosts selbst
bestimmen.
> Schließlich kann man die Verbindung auch teergruben, nen X-Header
> einsetzen, was ins Subject schreiben, den "Spam-Score" erhöhen oder
> so. Aber bei dem Risiko, die Mails abzulehnen, daß kann man auf nem
> privaten Host machen, der nur für einen selbst werkelt, aber doch
> nicht wenn Dritte mit dranhängen.
Kommt auf die AGB, den Vertrag, die Absprachen (bei einer WG z. B.), den
Arbeitgeber und auf den Provider (der evtl. nur so die Kunden vor dem
Verlust von E-Mails durch zu viel Spam bewahren kann) drauf an. Kann man
sicher nicht verallgemeinern.
Nils Bronstert
> > Was mir noch aufgefallen ist: Welche *rechtlichen* Grundlagen,
> > Gesetze, Verordnungen, Bestimmungen etc. greifen hier, wenn man den
> > Server nicht privat sondern für Dritte verwaltet, also für Mitarbeiter
> > eines Unternehmens und/oder Kunden bspw.?
> >
> > Darf man "einfach so" Mails auf Grund technischer/inhaltlicher
> > Kriterien direkt am Server filtern/abweisen, die für Dritte bestimmt
> > sind? Müssen Mitarbeiter darüber aufgeklärt werden und/oder dem
> > zustimmen? Welche Konsequenzen kann man erwarten, wenn man Mails
> > abweist, die )aus Sicht von Sender und Empfänger, also != Admin) dann
> > doch wichtig sind?
>
> Bauen wir einen Extremfall.
>
> Provider filtert ohne das Wissen seiner Kunden nach irgendwelchen
> obskuren "Geek" Kriterien den inbound.
Was ist, wenn er nicht filtert (das Filtern wirft ja noch weitere
Probleme auf - der Provider könnte für *Inhalte* in E-Mails
evtl. verantwortlich gemacht werden), sondern blockt?
> Sein Kunde hat mit einem Auftraggeber vereinbart, dass er eine E-Mail
> schickt wenn die Erfüllung eines 45Mio-Vertrages stattfinden soll
> ("Hallo Dieter, starte die Produktion für Auftrag 4711").
>
> Die Mail kommt nicht an, es stellt sich heraus, dass sie im MTA des
> Providers vernichtet wurde.
Unrealistisch (ja, OK, ich weiß, Du willst einen Extremfall aufzeigen -
ich will auch nur zeigen, daß es mit leicht veränderter Konstellation
wesentlich unsicherer wird, wie ein Gericht entscheiden würde). Meist
wird wohl ein Bounce verschickt. Wenn der Provider blockt, dann wird
eine Fehlermeldung im SMTP-Dialog generiert und die E-Mail gar nicht
erst übertragen.
> Es gibt einen Run der Gutachter und es wird Fahrlässigkeit mit Drang zum
> Vorsatz festgestellt.
Evtl. wird auch Fahrlässigkeit beim Absender festgestellt, der das
realtiv unsichere Medium E-Mail für seine im Vergleich dazu wichtige
E-Mail verwendet hat.
> Am Ende hacken beide Seiten auf den Provider ein.
Ja, das läßt sich nie vermeiden ... ;-) Der Provider hat immer Schuld.
> Die Zwischentöne kannst Du dir dann in etwa zusammenraten.
>
> Zu Deiner Frage: per Definition müssen alle Filter mit einem in dieser
> Sache vertretungsberechtigten Beauftragten des Kunden abgesprochen
> werden, der sollte dringlichst seine Mitarbeiter darauf hinweisen bzw.
> per Dienstverfügung bekannt machen.
Ja, die beste Methode ist zweifellos, die verwendeten
Anti-Spam-Techniken dem Kunden mitzuteilen. Damit sollte es keine
Probleme mehr geben.
> Bei grossen und klagewütigen Kunden sollte man sich eigentlich wirklich
> jede Änderung des Serverfilters schriftlich bestätigen lassen.
Die sollte man nach Möglichkeit gar nicht bei sich annehmen ... ;-)
Dummerweise sieht man es denen oftmals nicht an und rausekeln kann man
sie ja nicht, sonst hat man gleich die nächste Klage am Hals ;-).
Nils Bronstert
meiner Meinung und meiner Rechtsauffassung. Urteile zu Deinem Beispiel
gibt es meines Wissens bisher nicht und die entsprechenden Gesetze sind
imho alles andere als eindeutig.
* Klaus Peukert <peu...@gmx.de>:
> Was mir noch aufgefallen ist: Welche *rechtlichen* Grundlagen,
> Gesetze, Verordnungen, Bestimmungen etc. greifen hier, wenn man den
> Server nicht privat sondern für Dritte verwaltet, also für Mitarbeiter
> eines Unternehmens und/oder Kunden bspw.?
Naja, man ist imho nur für seine eigenen Kunden verantwortlich. Der
eigene Kunde kann also, wenn er seine Mails nicht bekommt, evtl.
zumindest einen Grund für eine Klage haben. Ob er die in heutigen
Spam-Zeiten auch durchbringt (schließlich will sein Provider ihn nur vor
Spam und damit vor Mail-Verlust einer anderen Art, schützen) ist eine
andere Frage, die meines Wissens nach noch nie vor Gericht verhandelt
wurde. Meist wird der Kunde in eigenem Interesse aber zunächst mal bei
seinem Provider mal freundlich anfragen, ob man den Absender nicht
whitelisten könnte.
> Darf man "einfach so" Mails auf Grund technischer/inhaltlicher
> Kriterien direkt am Server filtern/abweisen, die für Dritte bestimmt
> sind?
Sicher. Beim Blocken dürfte das kein Problem sein. Die Mail wurde ja nie
übertragen oder vernichtet und der Absender erhält eine Fehlermeldung.
Der Absender hat also bestimmt kaum eine Grundlage für eine Klage. Wenn
dann nur der Empfänger. Ich bin aber kein Anwalt. Es gibt schließlich
manchmal schon sehr seltsame Urteile ...
> Müssen Mitarbeiter darüber aufgeklärt werden und/oder dem
> zustimmen?
Du meinst in einem Betrieb, der Mails empfängt? Wird wohl am besten so
sein. Aber auch ohne Zustimmung könnte ich mir das durchaus
vorstellen. Schließlich muß man ja als Provider für die störungsfreie
Zustellung der Mails sorgen, also dafür, daß möglichst keine Mails
verlorengehen. Wenn aber durch Spam die Gefahr durch das Nicht-blocken
höher ist als wenn man blockt (durch Postfachüberfüllung,
Unaufmerksamkeit beim JHD, Mailserverüberlastung usw.), dann ist es
meiner Meinung nach völlig OK, Spam zu blocken. Aber das ist einer der
kontrovers diskutierten Streitpunkte. Ein Urteil in die Richtung gibt es
wohl noch nicht.
> Welche Konsequenzen kann man erwarten, wenn man Mails
> abweist, die )aus Sicht von Sender und Empfänger, also != Admin) dann
> doch wichtig sind?
Der Absender hat meiner Meinung nach dabei nichts zu sagen. Der
Empfänger evtl. schon (aber nicht unbedingt). Meist wird es wohl
keinerlei Probleme geben, weil der Provider des Empfänger seinen Kunden
ja behalten möchte. Somit wird sich das Problem aus Sicht des Empfängers
wohl kaum stellen.
> Wo kann ich mich darüber genauer informieren?
>
> Xpost nach de.soc.recht.datennetze, Followup-To dahin ist gesetzt.
Die Gruppe ist sicher richtig.
Nils Bronstert
> > Du kannst ihm den SMTP-Dalog auch ausgedruckt auf Papier schicken; dem
> > robustness principle zufolge hat er sich ja dann damit rumzuschlagen.
>
> Ich denke uns beiden und den anderen Mitlesern ist Sinn und Intention
> des "robustness principles" klar. Ansonsten verweis ich auf die
> Fachbegriffe der Informatik:
>
> 106: robuschdness brincible
> Des 'robuschdness brincible' dr IETF lauded nedd: 'Du darfsch Müll
> sende.' und au nedd 'Du mussch Müll annehme.'. Viele Leide verkenne
> dis. (Krischdian Koehndobb)
Schön gesagt.
> Ob ein fehlender PTR nun Müll ist...
Tja, fraglich. Ich tendiere auch dazu, daß es eher dem RFC widerspricht
("sei liberal in dem, was Du annimmst"), Mails von IPs mit fehlendem
Reverse-Lookup nicht anzunehmen, auch wenn ein fehlender Reverse-Lookup
nicht RFC-konform ist. Aber bei der heutigen Spamschwemme *muß* man
Maßnahmen ergreifen, damit eben *keine* Mails verlorengehen. Und die
Spanne innerhalb der RFCs ist fast ausgeschöpft ...
> > Hast du irgendeinen Vertrag oder derartiges mit ihm, daß er von dir
> > Mails annehmen muß? Steht da drin, welche technischen Rahmenbedingungen
> > einzuhalten sind?
>
> Hab ich nicht.
Das ist der entscheidende Punkt.
> Ein User eines Servers, auf dem ich (mit) die Hände
> drauf hab, wollte Mail an eine Domain schicken, deren MX einen
> (tatsächlich) fehlenden PTR mit einem 550 bedenkt. Der PTR existiert
> inzwischen, insofern ist das Problem erledigt.
Gut.
> > Insofern ist mir überhaupt nicht klar, warum du hier auf die rechtliche
> > Schiene willst.
>
> Ich such ne Argumentation für ebenjene Nutzer, daß der Gegenüber der
> "Böse" ist
Ist er meiner Meinung nach nicht. Ich würde es (noch) nicht so machen,
aber letztendlich ist das der verzweifelte Versuch, dem Spam Herr zu
werden, ohne zu viel legitime Mail zu verlieren, also ohne E-Mail
komplett abzuschalten. Denk auch an die immensen Kosten, die Spam
verursacht. Vielleicht müßte der Provider ohne die Maßnahmen neue
Mailserver und damit vielleicht auch mehr Bandbreite, dadurch andere
Zugangstechnik, andere Load-Balancing-Hardware usw. anschaffen.
Vielleicht würde er seine Preise erhöhen müssen. Die Maßnahmen des
Providers sind also wohl kaum ein Grund, auf den Serverbetreiber
"einzuschlagen" jedenfalls.
> und nicht der fehlende PTR.
Mit dem Eintragen des PTR ist das Problem gelöst und außerdem gibt es
nicht einen einzigen Grund dafür, keinen Reverse-Lookup zu haben,
außerdem ist der Reverse-Lookup im RFC vorgeschrieben. Also müßig
darüber zu streiten. Einfach den PTR korrekt eintragen und gut is.
> Die rechtliche Seite
> interessiert mich eher generell
Die rechtliche Seite ist meiner Meinung nach völlig offen und keineswegs
klar. Für beide Standpunkte wirst Du jeweils viele Leute finden.
> und hat mit dem konkreten Fall
> eigentlich nix zu tun. Letzlich such ich Informationen, die meine
> Meinung, daß eine solche Filterung BAD ist, untermauern.
Schwierig. Du kannst eigentlich nur Deine Meinung kundtun. Du kannst
aber einem E-Mail-Empfänger nicht vorschreiben, wie er seinen eigenen
Server zu administrieren hat (solange er nicht andere damit direkt
belästigt). Das Internet besteht eben aus vielen eigenständigen
Netzen. Jedes Netz nimmt üblicherweise kostenlos E-Mails von beliebigen
anderen Netzen an. Das ist ein Privileg, keine Erfordernis. Wenn Du also
keinen Vertrag mit dem Empfänger hast, dann wird Dir nichts anderes
übrig bleiben, als auf ein Whitelisting zu hoffen oder bei Fehlern auf
Deiner Seite, diese Fehler zu beheben.
Bernd Hohmann
>>Aus diesem Grunde wird
>>das bei mir automatisch auf die Adresse des Systemverantwortlichen
>>verbogen und die muss angegeben sein, sonst startet der MTA nicht.
>
> Ähm, wer soll denn ansonsten die postmaster-Mail bekommen, wenn nicht
> der Systemverantwortliche für den Mailserver?
Es gibt Kunden, die wollen den Postmaster selber haben. Da streite ich
nicht lange.
Denn was für eine
> vertragliche Vereinbarung solltest *Du* mit dem Kunden des anderen
> Providers haben? Wenn Du diese nicht hast, dann bist Du schließlich auf
> sein Wohlwollen beim Annehmen von E-Mails angewiesen. Er macht das
> schließlich *kostenlos* und *freiwillig*, obwohl es für ihn Kosten
> verursacht.
Hm. Zumindest ich werde dafür bezahlt, dass ich Mails entgegennehme. Und
so wird es bei anderen Systemen auch sein.
Der Kunde des anderen
> Providers könnte natürlich auch sagen, daß ihm der Spam-Block wichtiger
> ist, als die Mail Deines Kunden. Dann wäre die Sache sogar noch klarer.
Jo :-)
Bernd
Wolfgang Jäth
>
> > ist es gaengige Praxis.
>
> Ja, leider. Es macht die Dial-Up-User zu Internetusern zweiter
> Klasse.
Sorry, aber das ist Blödsinn; jeder Dailup-User kann (mindestens) einen
entsprechenden Smarthost und/oder MX benutzen. 'Zweite Klasse' sind
höchstens diejenigen User, die sich keinen eigenen Server leisten
können/wollen, aber trotzdem glauben, unbedingt entsprechende Dienste
anbieten/nutzen zu müssen.
Wolfgang, selber DU-Benutzer
--
Bernd Hohmann
>>Provider filtert ohne das Wissen seiner Kunden nach irgendwelchen
>>obskuren "Geek" Kriterien den inbound.
>
> Was ist, wenn er nicht filtert (das Filtern wirft ja noch weitere
> Probleme auf - der Provider könnte für *Inhalte* in E-Mails
> evtl. verantwortlich gemacht werden), sondern blockt?
Per Definition geht den Betreiber der Inhalt einer E-Mail nichts an
(Fernmeldegeheimnis).
Blocken ist eine andere Sache - da bekommt es der Absender wenigstens
mit (sofern er das will und sich nicht hinter m...@privacy.net versteckt).
Den Inhalt analysieren und dann hinter dem DATA einen 5xx zu liefern,
ist schwierig (Mail geht an 2 User deines Systems, nur ein User filtert)
und birgt das Risiko, dass die Onlineverarbeitung zu lange dauert
(Socket Timeout).
>>Es gibt einen Run der Gutachter und es wird Fahrlässigkeit mit Drang zum
>>Vorsatz festgestellt.
>
> Evtl. wird auch Fahrlässigkeit beim Absender festgestellt, der das
> realtiv unsichere Medium E-Mail für seine im Vergleich dazu wichtige
> E-Mail verwendet hat.
Definiere "unsicher". Wenn ich mit einem Kunden oder Auftraggeber
jahrelang das Medium "E-Mail" ohne Verluste benutze, dann kann ich
daraus eine gewisse Sicherheit ableiten. Wenn die Mail gelöscht wird,
weil einer der Provider wild filtert, dann ist das Medium per se nicht
unsicherer geworden.
Das sind aber wie gesagt alles so Extrembetrachtungen die in der Praxis
so nicht vorkommen.
>>Zu Deiner Frage: per Definition müssen alle Filter mit einem in dieser
>>Sache vertretungsberechtigten Beauftragten des Kunden abgesprochen
>>werden, der sollte dringlichst seine Mitarbeiter darauf hinweisen bzw.
>>per Dienstverfügung bekannt machen.
>
> Ja, die beste Methode ist zweifellos, die verwendeten
> Anti-Spam-Techniken dem Kunden mitzuteilen. Damit sollte es keine
> Probleme mehr geben.
Nicht nur Mitteilen sondern auch absegnen lassen.
>>Bei grossen und klagewütigen Kunden sollte man sich eigentlich wirklich
>>jede Änderung des Serverfilters schriftlich bestätigen lassen.
>
> Die sollte man nach Möglichkeit gar nicht bei sich annehmen ... ;-)
> Dummerweise sieht man es denen oftmals nicht an und rausekeln kann man
> sie ja nicht, sonst hat man gleich die nächste Klage am Hals ;-).
Man kann Verträge durchaus kündigen. Aber meisstens will man sie ja
nicht wirklich loswerden - solange sie ihre Rechnungen pünktlich bezahlen.
Bernd
Ullrich von Bassewitz
> Nicht alles, was hinkt, ist ein Vergleich. :-) Das Abheben
> entspricht nämlich z.B. dem Lesen einer Mail.
Falsch. Das Abheben entspricht dem Annehmen, und das Zuhoeren entspricht dem
Lesen. Logisch, oder?
> Der Dienstleister, der Dir Deine Telefonnummer verschafft hat, darf
> nicht eigenmächtig Anrufe bzw. Anrufsversuche vorenthalten.
Das wuerde in Konsequenz heissen, dass ich die Telekom verklagen kann, wenn
ein Anrufer gassenbesetzt kriegt. Glaubst Du da wirklich dran?
> Wenn jemand eine standardkonforme E-Mail absetzt, dann darf man
> grundsätzlich erwarten, dass sie vom für den Empfänger zuständigen
> MTA angenommen wird.
Anders gesagt: Ein Spammer braucht nur dafuer zu sorgen, dass sein Muell den
RFCs entspricht, und dann kann er davon ausgehen dass dieser Muell auch
angenommen werden muss? Filtern mit DNSBLs ist Deiner Meinung nach
unzulaessig, wenn die Mails standardkonform sind?
Bist Du wirklich sicher, dass Du genau das sagen wolltest?
> Wer Nachrichten *allein* wegen eines fehlenden
> PTR-Records ablehnt, sollte keine Mailserver betreiben. :-> YMMV.
Wer heutzutage Mails nicht filtert, ist praktisch nicht mehr in der Lage,
Email sinnvoll zu nutzen. Ein Bekannter von mir, der nicht filtert, kriegt pro
Tag 300 Emails - praktisch durchweg Spam.
Dass Filtern ein notwendiges Uebel ist, darueber sind sich alle einig. Es kann
also eigentlich nur noch darum gehen, welche Kriterien angewendet werden. Dass
dabei nicht nur die Geschmaecker verschieden sind, sondern dass auch die
unterschiedlichen Environments unterschiedliche Filterkriterien bedingen ist
wohl klar.
Ich weiss nicht, nach welchen Kriterien Du filterst, aber ich bin mir sicher,
dass ich manche davon auch fuer weit hergeholt halten wuerde. Da es aber Deine
Kriterien sind, und da es Dein Mailserver ist, liegt es mir fern, Dir dazu
irgendwelche Vorschriften zu machen. Und ich kaeme auch nicht auf die Idee,
Dir zu sagen Du solltest keinen Mailserver betreiben, bloss weil mir Deine
Filterkritierien nicht passen. Es wuerde mich freuen, wenn Du in dem Bereich
auch etwas toleranter waerest:-)
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
10:47:48 up 31 days, 12:41, 9 users, load average: 0.00, 0.02, 0.00
Ullrich von Bassewitz
> Ja, leider. Es macht die Dial-Up-User zu Internetusern zweiter
> Klasse.
Dialups *sind* Internetuser zweiter Klasse. Wenn dem nicht so waere, welchen
Grund gaebe es dann fuer Provider, diese Zugaenge billiger zu verkaufen, als
"richtige"? You get what you pay for.
Man koennte sich allenfalls fragen, ob es notwendig ist, den sowieso
benachteiligten Dialups auch noch die Direktzustellung von Mail zu verwehren.
Die Frage hat sich aber inzwischen von selber beantwortet, weil Blocken von
Dialups nicht nur ein bisschen, sondern deutlich gegen Spam und diverse Email
Viren/Wuermer hilft.
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
11:11:37 up 31 days, 13:05, 9 users, load average: 0.11, 0.05, 0.01
Bernd Hohmann
>>Der Dienstleister, der Dir Deine Telefonnummer verschafft hat, darf
>>nicht eigenmächtig Anrufe bzw. Anrufsversuche vorenthalten.
>
> Das wuerde in Konsequenz heissen, dass ich die Telekom verklagen kann, wenn
> ein Anrufer gassenbesetzt kriegt. Glaubst Du da wirklich dran?
Erm... Ich dachte wir sprechen vom Filtern ohne Information des Empfängers.
"Gassenbesetzt" bedeutet, dass keine Verbindung aufgebaut werden kann,
weil die Kapazität der Vermittlungsstelle der Telekom oder die
Leitungskapazität zwischen zwei Vermittlungsstellen erschöpft ist.
Bernd
Nils Bronstert
> > > Aus diesem Grunde wird
> > > das bei mir automatisch auf die Adresse des Systemverantwortlichen
> > > verbogen und die muss angegeben sein, sonst startet der MTA nicht.
> >
> > Ähm, wer soll denn ansonsten die postmaster-Mail bekommen, wenn nicht
> > der Systemverantwortliche für den Mailserver?
>
> Es gibt Kunden, die wollen den Postmaster selber haben. Da streite ich
> nicht lange.
Hmm, ich streite auch nicht, ich gebe ihm die Adresse auch auf Wunsch
nicht. Wenn ich der Postmaster bin, dann hab ich die Adresse und nicht
der Kunde, wie es ja auch im RFC steht. Der Kunde kann damit ja sowieso
nichts anfangen, wenn ne Frage oder Bewchwerde zu unserem Mailserver
kommt.
Wenn er einen eigenen Mailserver hat und seine Mails darüber
hereinkommen, dann ist er eben der Postmaster und nicht ich.
> > Denn was für eine
> > vertragliche Vereinbarung solltest *Du* mit dem Kunden des anderen
> > Providers haben? Wenn Du diese nicht hast, dann bist Du schließlich auf
> > sein Wohlwollen beim Annehmen von E-Mails angewiesen. Er macht das
> > schließlich *kostenlos* und *freiwillig*, obwohl es für ihn Kosten
> > verursacht.
>
> Hm. Zumindest ich werde dafür bezahlt, dass ich Mails entgegennehme.
Ja, aber nur von *Deinen* Kunden, also den Empfängern, nicht jedoch von
den Absendern (von der Ausnahme, daß der Absender auch einer Deiner
Kunden ist, mal abgesehen).
> Und
> so wird es bei anderen Systemen auch sein.
Ja. Aber darauf kannst Du schlecht aufbauen. Könntest höchstens
versuchen, den anderen Kunden (den Empfänger), gegen seinen Provider
"aufzustacheln". Aber ob der davon so begeistert wäre?
Florian Laws
Und bekommt der Empfänger davon etwas mit? ;-)
Grüße,
Florian
Klaus Peukert
[...]
>Wichtig ist eine vernünftige
>Begründung, warum man die E-Mail nicht haben will (und daß
>Postmaster und Abuse trotzdem erreichbar sind - ansonsten
>kann man sich gleich selbst bei RFC-Ignorant eintragen).
Im konkreten Fall bouncten auch Mails an den Postmaster des
abweisenden Servers. Ein Zeichen von Weisheit...
Ullrich von Bassewitz
> Erm... Ich dachte wir sprechen vom Filtern ohne Information des Empfängers.
Genau. Wenn mich jemand anrufen will und besetzt kriegt, dann erhalte ich
keinerlei Information ueber den versuchten Anruf. Wenn es sich um den Versuch
handelt, mit einen 45 Mio. Deal zu ermoeglichen, dann sehe ich genauso alt
aus, wie wenn das jemand per Mail probiert.
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
13:57:44 up 31 days, 15:51, 9 users, load average: 0.17, 0.08, 0.02
Klaus Peukert
>> Darf man "einfach so" Mails auf Grund technischer/inhaltlicher
>> Kriterien direkt am Server filtern/abweisen, die für Dritte bestimmt
>> sind?
>Sicher. Beim Blocken dürfte das kein Problem sein. Die Mail wurde ja nie
>übertragen oder vernichtet und der Absender erhält eine Fehlermeldung.
>Der Absender hat also bestimmt kaum eine Grundlage für eine Klage. Wenn
>dann nur der Empfänger. Ich bin aber kein Anwalt. Es gibt schließlich
>manchmal schon sehr seltsame Urteile ...
Wie legitimiere ich das gegenüber meinen Kunden/Mitarbeitern, denen am
Empfang einer solchen Mail ja durchaus gelegen sein kann? *Ich* weiß
doch nicht, welche Mails mein User für wichtig erachtet. Er könnte
sich ja für Viagra o.ä interessieren. Oder über Spam/Viren forschen
bspw.
Ich glaub irgendwie nicht, daß ich Kraft meiner Wassersuppe das
entscheiden darf.
>Du meinst in einem Betrieb, der Mails empfängt? Wird wohl am besten so
>sein. Aber auch ohne Zustimmung könnte ich mir das durchaus
>vorstellen. Schließlich muß man ja als Provider für die störungsfreie
>Zustellung der Mails sorgen, also dafür, daß möglichst keine Mails
>verlorengehen.
Wie sollen Mails verlorengehen, wenn ich *nicht* blocke? Ich krieg ja
dann eher deutlich mehr Mails. Und Fehler/Unachtsamkeiten beim "JHD"
sind Fehler des Users --> sein Pech.
>Der Absender hat meiner Meinung nach dabei nichts zu sagen. Der
>Empfänger evtl. schon (aber nicht unbedingt).
Was, wenn Sender und Empfänger eine geschäftliche Beziehung haben
(oder meinetwegen auch eine persönliche)? Welches Recht habe ich als
Postmaster, diese Kommunikation zu unterbinden? Keins, IMHO.
Klaus Peukert
>Leider stimmt diese Begruendung. Ich kenne SpamAssassin und andere Spamfilter
>nicht so gut, aber es wuerde mich sehr wundern, wenn diese bei fehlendem
>Reverse Lookup nicht auch ein negatives Scoring vergeben wuerden.
Gegen Scoring hat ja keiner was. Da kann der letzliche Empfänger seine
*persönlichen* Präferenzen anhand dieses Scores festlegen und
entsprechend handeln/filtern.
>So eine Diskussion hatten wir schon oefters. Bloss weil ich einen
>Telefonanschluss habe, bin ich nicht gezwungen, auch abzunehmen, wenn Du
>anrufst. Bloss weil ich eine Tuer habe, brauche ich sie noch lange nicht
>aufmachen, wenn Du davorstehst und klingelst. Und bloss weil ich einen
>Mailserver betreibe brauche ich von Dir noch lange keine Mail anzunehmen.
*Du* in der Tat nicht. Aber die Mail ist nicht für Dich bestimmt,
sondern für einen User Deines Servers. Dessen Kommunikation
bevormundest Du ja. Um beim Telefon zu bleiben, du als Admin der
TK-Anlage leitest Anrufer nach gewissen Kriterien direkt auf
"Besetzt".
Für den fehlenden PTR heißt das, Du läßt keine Anrufe rein, bei denen
Du die Nummer nicht im Telefonbuch findest.
>Es geht nicht so sehr um "korrekte" Hosts, sondern um "korrekte" Mailserver.
>Waehrend es bei einem Mail ausliefernden Dialup Host sein kann, dass dieser
>Probleme mit dem DNS hat ist das bei offiziellen Mailservern nur sehr selten
>der Fall. Und Mails von Dialups, ADSL Ranges, Kabelmodems usw. will man
>meistens sowieso nicht haben.
Es *kann* aber der Fall sein. Es gibt keinen technischen Grund, warum
die IP des Mailservers einen PTR haben muss. Man muß auch nicht im
Telefonbuch stehen um jemanden anzurufen.
Klaus Peukert
>Ähm, Du meinst wohl "... oder landet der Name nicht wieder bei der IP,
>kassiert man den 550.", oder? Denn das HELO/EHLO zu prüfen ergibt schon
>so einige False-Positives und widerspricht auch dem RFC, der nur eine
>Syntaxprüfung zuläßt.
So wie ich den Admin am Telefon verstanden habe wird auch das HELO
überprüft und muß "passen". Da der gute Mann auch Mails an postmaster@
bouncen läßt, nunja... Das dürfte die Kompetenz verdeutlichen.
>Jeder, der einen Server betreibt, darf natürlich die Regeln für seinen
>Server selbst bestimmen. Schließlich mußt Du ihm ja keine Mail schicken.
>Sagen wir also lieber: Man sollte vorsichtig sein mit dem, was man
>blockt, sonst verliert man evtl. Mails, die man eigentlich haben wollte.
Ich halte schon den Verlust einer einzigen legitimen und erwünschten
Mail, die für irgendeinen User des Servers wichtig war für
inakzeptabel. Ein "Von denen will man eh keine Mail haben" kann man
IMO nicht ernsthaft behaupten, wenn man einen Mailserver für Dritte
betreibt. Woher weiß ich, was meine User für Mail haben wollen? Eben.
>Kommt auf die AGB, den Vertrag, die Absprachen (bei einer WG z. B.), den
>Arbeitgeber und auf den Provider (der evtl. nur so die Kunden vor dem
>Verlust von E-Mails durch zu viel Spam bewahren kann) drauf an. Kann man
>sicher nicht verallgemeinern.
Ne, natürlich nicht. Man kann durchaus auf Grund technischer Kriterien
blocken (fehlender MX für die Domain der Absenderadresse etwa [1]),
aber die eigentlich *Entscheidung*, was denn gefiltert/geblockt werden
soll kann IMO nur der Nutzer selbst entscheiden
[1] Auch wenn mir mind. ein Fall bekannt ist (> 1a her), wo eine
deutsche Uni Mailadressen der Form us...@institut.uni-posemuckel.de
ohne MX für institut.uni-posemuckel.de betrieben hat. Der Mailserver
lief auf institut.uni-posemuckel.de:25, das durfte man erraten
Klaus Peukert
>> > Hast du irgendeinen Vertrag oder derartiges mit ihm, daß er von dir
>> > Mails annehmen muß? Steht da drin, welche technischen Rahmenbedingungen
>> > einzuhalten sind?
>> Hab ich nicht.
>Das ist der entscheidende Punkt.
Eigentlich ist das überhaupt kein Punkt. Einer meiner User hat ein
berechtigtes Interesse eine E-Mail an einen anderen User zu schicken,
der wiederum ein ebenso berechtigtes Interesse am Empfang dieser Mail
hat.
Jemand möchte einen Geschäftspartner anrufen. Er erreicht Ihn nicht,
weil seine Telco ihn nicht im Telefonbuch eingetragen hat und der
Admin der TK-Anlage beim Angerufenen nur Anrufer reinläßt, die im
Telefonbuch stehen.
Hmm, klingt nicht so, als würde man so etwas wollen. Naja, Vergleiche
hinken ja immer.
Klaus Peukert
>Grundsätzlich darf der Empfänger alles. Er nimmt Deine Mails schließlich
>normalerweise kostenlos und ohne vertragliche oder sonstige
>Gegenleistung von Dir an. Ein Empfänger kann also durchaus alle Mails
>von Providern ablehnen, deren Admin ein grünes Auto fährt oder von allen
>ungeraden IP-Adressen oder von allen Leuten, die "Hinz" oder "Kunz" mit
>Vornamen heißen oder eben von allen Servern, die keinen oder einen
>falschen PTR-Record haben. Ob das sinnvoll ist, kann nur der Empfänger
>für sich entscheiden.
Richtig. Der *Empfänger* darf alles. Der darf von mir aus auch alle
seine Mails ungelesen wegschmeißen. Aber darf auch der *Admin* des
Empfängers alles? Darum ging es mir.
>So ist das, ja. Der Empfänger scheint sich gut auszukennen und weiß
>offensichtlich, was er tut.
Nun, nach mehrmaligen Drüberlesen, scheint mir das nicht so. Wie von
Jost bemerkt steht in dem zitierten Punkt von RFC 1123 ledglich, daß
ein Host die Namensauflösung beherrschen muss. Obendrein läßt der gute
Mann auch Mails an postmaster@ wg. fehlendem PTR bouncen, was dann
doch nicht ganz so doll ist...
[.robustness principle..]
>Ja, den gibt es auch. Leider muß der aber wegen der Spammer hie und da
>etwas eingeschränkt werden, einfach weil es sonst gar nicht mehr
>funktioniert.
Klar gibts technische Kriterien, nach denen man filtern/blocken kann.
Aber die sollten so festgelegt sein, daß false positives nahezu
ausgeschlossen sind und nur wirklich kaputte Mails abgewiesen werden.
Alles andere gehört beim Empfänger (oder in eine Empfänger-abhängige
Einstellung am Server)
Florian Laws
>
>>Grundsätzlich darf der Empfänger alles. Er nimmt Deine Mails schließlich
>>normalerweise kostenlos und ohne vertragliche oder sonstige
>>Gegenleistung von Dir an. Ein Empfänger kann also durchaus alle Mails
>>von Providern ablehnen, deren Admin ein grünes Auto fährt oder von allen
>>ungeraden IP-Adressen oder von allen Leuten, die "Hinz" oder "Kunz" mit
>>Vornamen heißen oder eben von allen Servern, die keinen oder einen
>>falschen PTR-Record haben. Ob das sinnvoll ist, kann nur der Empfänger
>>für sich entscheiden.
>
>Richtig. Der *Empfänger* darf alles. Der darf von mir aus auch alle
>seine Mails ungelesen wegschmeißen. Aber darf auch der *Admin* des
>Empfängers alles? Darum ging es mir.
Das wird der Admin mit seinen Empfängern ausmachen müssen.
Grüße,
Florian
Hatto von Hatzfeld
> Nils Bronstert schrieb:
>
> >Ähm, Du meinst wohl "... oder landet der Name nicht wieder bei der IP,
> >kassiert man den 550.", oder? Denn das HELO/EHLO zu prüfen ergibt schon
> >so einige False-Positives und widerspricht auch dem RFC, der nur eine
> >Syntaxprüfung zuläßt.
>
> So wie ich den Admin am Telefon verstanden habe wird auch das HELO
> überprüft und muß "passen".
Nun, wenn die Nichteinhaltung einer bestimmten Regelung des zuständigen
RfCs ein gutes Spamkriterium ist, dann kann man meines Erachtens auch
danach ablehnend filtern. Ob das hier der Fall ist, weiß ich nicht.
> Da der gute Mann auch Mails an postmaster@ bouncen läßt, nunja... Das
> dürfte die Kompetenz verdeutlichen.
Das ist natürlich schon schlecht.
> >Sagen wir also lieber: Man sollte vorsichtig sein mit dem, was man
> >blockt, sonst verliert man evtl. Mails, die man eigentlich haben wollte.
>
> Ich halte schon den Verlust einer einzigen legitimen und erwünschten
> Mail, die für irgendeinen User des Servers wichtig war für
> inakzeptabel.
Was ist mit "Verlust" gemeint? Einfach wegwerfen darf man natürlich
nicht. Ein "reject" dagegen erzeugt ja erst einmal keinen Verlust,
sondern eine Fehlermeldung.
> Ein "Von denen will man eh keine Mail haben" kann man IMO nicht
> ernsthaft behaupten, wenn man einen Mailserver für Dritte betreibt.
> Woher weiß ich, was meine User für Mail haben wollen? Eben.
In der Praxis wird man aber Kompromisse schließen müssen. Ich blockiere
nach gewissen Blacklists; sonst wäre die Zahl von Mails in manchen
Postfächern nicht mehr tragbar. Die User haben Verständnis dafür.
Im Fall von Korea habe ich sogar das ganze Land blockiert; wer aber aus
Korea schreibt, bekommt eine Fehlermeldung, die ihm weiterhilft und
sagt, wie er über den postmaster (der alles annimmt) doch seinen
Adressaten erreicht (und auch auf eine Whitelist kommen kann).
> Ne, natürlich nicht. Man kann durchaus auf Grund technischer Kriterien
> blocken (fehlender MX für die Domain der Absenderadresse etwa [1]),
> aber die eigentlich *Entscheidung*, was denn gefiltert/geblockt werden
> soll kann IMO nur der Nutzer selbst entscheiden
>
> [1] Auch wenn mir mind. ein Fall bekannt ist (> 1a her), wo eine
> deutsche Uni Mailadressen der Form us...@institut.uni-posemuckel.de
> ohne MX für institut.uni-posemuckel.de betrieben hat. Der Mailserver
> lief auf institut.uni-posemuckel.de:25, das durfte man erraten
Das, finde ich aber nun, ist ganz und gar kein geeignetes
Filterkriterium. Wo steht dann, dass es einen MX-Eintrag geben muss? In
RfC 2821 (Abschnitt 5) steht sogar ausdrücklich, dass bei fehlendem
MX-Record der A-Record als Ersatz zu nehmen ist. Demnach ist nichts zu
erraten, sondern die Sache ist klar, und das Institut in Posemuckel
hat nichts falsch gemacht.
Anders sieht es aus, wenn es die Domain gar nicht gibt. Mit diesem
Kriterium weist mein Mailserver immer noch eine ansehnliche Zahl an
Spammails ab. Was mich etwas wundert; denn ganz neu ist es nicht,
hiernach zu filtern.
Ciao,
Hatto
--
Treffen sich zwei Planeten im Weltall. Sagt der eine: "Du siehst aber
schlecht aus. Fehlt dir was?" Sagt der zweite: "Ach, mir geht's gar
nicht gut. Ich hab' Homo sapiens." Tröstet ihn der andere: "Mach dir
keine Sorgen. Hatte ich auch mal. Das geht schnell vorbei."
Ullrich von Bassewitz
> Richtig. Der *Empfänger* darf alles. Der darf von mir aus auch alle
> seine Mails ungelesen wegschmeißen. Aber darf auch der *Admin* des
> Empfängers alles?
Wenn der Empfaenger das billigt: Ja. Weder Du, noch der Absender der Mail
haben irgendeine Handhabe gegen den Admin des Empfangsrechners. Die hat
ausschliesslich der Empfaenger. Der muss das mit seinem Admin ausmachen.
> Klar gibts technische Kriterien, nach denen man filtern/blocken kann.
> Aber die sollten so festgelegt sein, daß false positives nahezu
> ausgeschlossen sind und nur wirklich kaputte Mails abgewiesen werden.
> Alles andere gehört beim Empfänger (oder in eine Empfänger-abhängige
> Einstellung am Server)
Das ist Deine Meinung. Andere haben andere Meinungen. Und weil Du anderen
schlecht vorschreiben kannst, wie sie ihren Mailserver zu betreiben haben,
musst Du Dich entweder an deren Kriterien halten, oder damit leben, dass Deine
Mails (oder die Deiner Kunden) abgewiesen werden. Dass Dich das stoert ist
verstaendlich, hilft Dir aber nichts. Mir wuerde es auch gefallen, wenn alle
Mailserver so betrieben wuerden, wie *ich* das will:-)
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
18:23:21 up 31 days, 20:17, 9 users, load average: 0.01, 0.08, 0.07
Frank Ellermann
> die Mail ist nicht für Dich bestimmt, sondern für einen User
> Deines Servers. Dessen Kommunikation bevormundest Du ja.
Das liegt in der Natur der Sache. Wer zwanzig Minuten nach dem
HELO immer noch nicht weiss, was er will, dessen SMTP-Sitzung
wird abgeschossen. Wer nach 100 MB DATA immer noch nicht Punkt
sagt, wird auch erschossen, Wer RCPT TO unknown user probiert,
kriegt ein paar Fehler, und wenn er immer so weiter macht, wird
er erschossen, Wer mehr als 1000 Empfaenger... wer mit einer
geblockten IP... wer offensichtlich falsches MAIL FROM... und
so weiter.
> Für den fehlenden PTR heißt das, Du läßt keine Anrufe rein,
> bei denen Du die Nummer nicht im Telefonbuch findest.
Kann doch Sinn machen. Wenn IP 1.2.3.4 was bei Dir einliefern
will, dann moechtest Du im Notfall dem Betreiber dieses smtpd
was mitteilen, Ohne Hostname kann das schief gehen, falls
1.2.3.4 nur ein mailout ist, ohne Name findest Du MX 4.3.2.1
dafuer nicht direkt.
> Es gibt keinen technischen Grund, warum die IP des
> Mailservers einen PTR haben muss.
Extra testen, ob auf 1.2.3.4 auch Mail angenommen wird, waere
wegen SMTP / TCP statt DNS / UDP zuviel Aufwand.
> Man muß auch nicht im Telefonbuch stehen um jemanden
> anzurufen.
Der Angerufene kann Anrufer von unbekannten Nummern abweisen.
Mache ich auf einer MSN so.
Bye, Frank
Frank Ellermann
> das Blocken von dial-Up-Usern finde ich nicht gut.
Wenn ich User bei Dir waere, wuerde ich Dich auf Knien
anflehen, wenigstens spamcast IPs zu blocken. Das hat
IMHO auch was mit dem jeweiligen abuse management zu tun,
Bye, Frank
Bernd Hohmann
> Das liegt in der Natur der Sache. Wer zwanzig Minuten nach dem
> HELO immer noch nicht weiss, was er will, dessen SMTP-Sitzung
> wird abgeschossen.
Bei mir wird nach 10 Responses mit einer Antwort <> "2xx" einfach der
Socket geschlossen. Manchmal kommt die SMTP Kommunikation aus dem Tritt
und ein kleines Attachment kann dann hinter dem DATA viele "xxx Was
willst Du?" produzieren - die nicht vom Socket abgeholt werden und dann
ganz blöde Nebeneffekte haben.
Übrigens: wenn Du ungefähr 10% der Spammer erledigen willst, schicke
ihnen eine Multiline Response am Anfang. Kuckmal Port 25 auf
mail.harddiskcafe.de
Wer nach 100 MB DATA immer noch nicht Punkt
> sagt, wird auch erschossen,
Ich hatte mal einen Kunden aus dem Print & Medienbereich. Natürlich ist
es Unfug, 300MB Rohdaten per Mail zu verschicken (base64 bläht halt),
aber die haben es gemacht. Die Firma hat dann aus anderen Gründen die
Bücher zugeklappt.
[weitere Beispiele wo ein Reject "vonnöten" ist]
>>Es gibt keinen technischen Grund, warum die IP des
>>Mailservers einen PTR haben muss.
>
> Extra testen, ob auf 1.2.3.4 auch Mail angenommen wird, waere
> wegen SMTP / TCP statt DNS / UDP zuviel Aufwand.
Das war aber nicht so recht die Antwort auf Behauptung, dass die IP des
Mailservers einen Backpointer "IP -> Sonstwas" haben muss.
Man kann einen fehlenden Backpointer "hopplahopp aufgesetztes system zum
spamversand" oder als "hopplahopp aufgesetztes system zur kommunikation"
betrachten.
Bei http://www.harddiskcafe.de/dscn0006.jpg hatte ich ganz andere
Probleme als deine ,-)
>>Man muß auch nicht im Telefonbuch stehen um jemanden
>>anzurufen.
>
> Der Angerufene kann Anrufer von unbekannten Nummern abweisen.
> Mache ich auf einer MSN so.
Ja, man sollte seine Anrufer wirklich sorgfältig nach ihrer
Qualifikation bei der Konfiguration eines ISDN-Telefons auswählen.
Bernd
Ralf Döblitz
[...]
> Kann ich die Telekom verklagen, wenn mir telefonisch jemand einen Auftrag
> geben will, und mein Anschluss tut gerade nicht? (oder noch extremer: es ist
> gerade gassenbesetzt?)
Wenn sie die vertraglich zugesicherte Verfügbarkeit damit nicht erfüllt
haben: sicherlich. Fraglich ist nur, bis zu welchem Betrag sie haften,
denn Schadenersatzforderungen, die um Größenordnungen über den Entgelten
für die Erbingung der Leistung liegen, düften in Deutschland wohl
angelehnt werden (zum Glück, sonst hätten wir hier bald amerikanische
Verhältnisse).
Ralf
--
Ralf Döblitz * Schapenstraße 6 * 38104 Braunschweig * Germany
Phone: +49-531-2361223 Fax: +49-531-2361224 mailto:doeb...@doeblitz.net
Homepage: http://www.escape.de/users/selene/
Mit UTF-8 kann man gleichzeitig äöüßÄÖÜæœłø¼½¾¤¹²³¢€£¥¶§¬÷×±©®™¡¿ verwenden.
Ralf Döblitz
[...]
> Was mir noch aufgefallen ist: Welche *rechtlichen* Grundlagen,
> Gesetze, Verordnungen, Bestimmungen etc. greifen hier, wenn man den
> Server nicht privat sondern für Dritte verwaltet, also für Mitarbeiter
> eines Unternehmens und/oder Kunden bspw.?
Grundsätzlich zuerst einmal der Vertragsinhalt: welche Leistungen mußt
du erbringen ("Annahme von Mails, die an Domain XYZ gerichtet sind" oder
eher "Betrieb eines SMTP-Servers für Domain XYZ") ?
> Darf man "einfach so" Mails auf Grund technischer/inhaltlicher
> Kriterien direkt am Server filtern/abweisen, die für Dritte bestimmt
> sind?
Filtern: Nein. Denn Filtern kannst du erst, wenn du die Mail bereits
angenommen hast, sie also dir zur Übermittlung anvertraut wurde. Du mußt
sie danach an deinen Kunden weiterleiten (sofern möglich, ansonsten ist
der Absender über den Fehlschlag der Zustellung zu informieren) bzw. den
Wünschen des Kunden entsprechend zu verarbeiten. Letzteres *kann* auch
Filterung sein, wenn der Kunde dies explizit beauftragt hat.
Abweisung: Ja. Du lehnst damit die Übernahme der Verantwortung für die
weitere Übermittlung der Mail ab. Dies kann unter bestimmten technischen
technischen Voraussetzungen notwendig sein, da du z.B. bei nicht
vorhandenem MX- oder A-RR für die Domain des Absenders bei Fehlschlag
der Zustellung den Absender nicht über den Fehler benachrichtigen
könntest und dich damit dem Vorwurf der Unterdrückung von Mails
aussetzen würdest. Also nimmt man so etwas erst gar nicht an und geht
umgeht damit dieses Risiko. Jedenfalls solange man nichts anderes mit
sienem Kunden vertraglich vereinbart hat.
> Müssen Mitarbeiter darüber aufgeklärt werden und/oder dem
> zustimmen?
Nein. Oder meinst du Kunden, also die intendierten Empfänger der Mails?
> Welche Konsequenzen kann man erwarten, wenn man Mails abweist, die
> )aus Sicht von Sender und Empfänger, also != Admin) dann doch wichtig
> sind?
Streß, nervige Telefonate und evtl. einen Kunden weniger. Falls du
unberechtigt filterst, kann das allerdings auch ein Strafverfahren zur
Folge haben (da du zur Filterung ja Einblick in die Kommunikations-
inhalte nehmen mußt, was ohne Auftrag durch den Kunden unzulässig ist,
da keine technische Notwendigkeit im Rahmen der Tätigkeit als
Übermittler der Emails besteht).
> Wo kann ich mich darüber genauer informieren?
>
> Xpost nach de.soc.recht.datennetze, Followup-To dahin ist gesetzt.
Sicher?
Ralf (IANAL, just postmaster)
Ralf Döblitz
[...]
> Hm. Zumindest ich werde dafür bezahlt, dass ich Mails entgegennehme. Und
> so wird es bei anderen Systemen auch sein.
Nicht unbedingt. Bei uns wird Mailservice entsprechende den geltenden
technischen Normen angeboten. Und das beinhaltet dann nicht nur Annahme
ordnungsgemäßer, sondern eben auch die Abweisung klar fehlerhafter
Mails.
Und wenn ein Reverse Lookup nicht möglich ist, dann ist das schon ein
hinreichend klarer Verstoß gegn die technichen Normen, um damit die
Abweisung zu begründen. Kunden wollen schließlich keinen Müll erhalten
(auch wenn sie selbst oft genug welchen produzieren).
Ralf
Bernd Hohmann
>>Hm. Zumindest ich werde dafür bezahlt, dass ich Mails entgegennehme. Und
>>so wird es bei anderen Systemen auch sein.
>
> Nicht unbedingt. Bei uns wird Mailservice entsprechende den geltenden
> technischen Normen angeboten. Und das beinhaltet dann nicht nur Annahme
> ordnungsgemäßer, sondern eben auch die Abweisung klar fehlerhafter
> Mails.
> Und wenn ein Reverse Lookup nicht möglich ist, dann ist das schon ein
> hinreichend klarer Verstoß gegn die technichen Normen, um damit die
> Abweisung zu begründen. Kunden wollen schließlich keinen Müll erhalten
> (auch wenn sie selbst oft genug welchen produzieren).
Die Interpretation von einem reibungslosen Mailverkehr ist mir
mittlerweile so hinreichend bekannt, dass eine steuerbegünstigte Filiale
in der Nähe von Braunschweig schon wieder gewinnbringend arbeiten könnte.
Nichts für ungut,
Bernd
Ralf Döblitz
[...]
> Dies meinte ich. Der Gegenüber überprüft die IP des Einliefernden, zu
> der IP muß ein PTR existieren, der auf einen Namen zeigt, der wiederum
> vorwärts aufgelöst auf die IP zeigt.
So solte es auch sein.
> Fehlt der PTR oder landet der nicht wieder beim HELO-Namen kassiert
> man den 550.
Was nun? Double Reverse Lookup oder HELO Verification, welches von
beidne meinst du? Ersteres ist IMNSHO vollkommen in Ordnung, letzeres
eindeutig RFC-widrig (bei falschem HELO/EHLO muß die Mail trotzdem
angenommen werden (RFC2821, 4.1.1):
| An SMTP server MAY verify that the domain name parameter in the EHLO
| command actually corresponds to the IP address of the client.
| However, the server MUST NOT refuse to accept a message for this
| reason if the verification fails: the information about verification
| failure is for logging and tracing only.
> Mir ist unklar, wie man ernsthaft eine solche "Lösung" nutzen kann und
> als Begründung mehr oder weniger immer ein "Von solchen Systemen kommt
> eh nur Schrott" kommt. Wenn man keine Mail will, soll man halt keinen
> Server betreiben.
Bei Double Reverse Lookup ist der Hintegrrund ganz simpel: wer so
elemantare Grundlagen nicht hinbekommt (das macht ja normalerweise die
LIR von der man den Netzblock bekommt, falls sie einem die Reverse
Delegation nicht eh gibt), der wird seinen Mailserver erst recht nicht
im Griff haben. Und da erspart man sich viel Ärger, wenn man präventiv
von solch fehlkonfigurierten Systemen erst einmal keine Daten annimmt,
egal ob es nun um Mail, FTP oder SSH-Logins geht. Schließlich besteht
ein Teil der Aufgabe eines Serverbetreibers auch darin, seine Server
(und dait die Daten der Kunden) vor Beschädigung z schützen, egal ob
diese vorsätzlich (Angriffe gegen die Server, Computersabotage) oder
fahrlässig (fehlkonfigurierte Systeeme) verursacht würden.
[...]
> Schließlich kann man die Verbindung auch teergruben,
Könnte man.
> nen X-Header
> einsetzen, was ins Subject schreiben, den "Spam-Score" erhöhen oder
> so.
Nein. Das wäre alles Filterung, eine Modifikation der Kommunikations-
inhalte, *das* genau ist ohne expliziten Auftrag des Kunden *nicht*
zulässig.
> Aber bei dem Risiko, die Mails abzulehnen, daß kann man auf nem
> privaten Host machen, der nur für einen selbst werkelt, aber doch
> nicht wenn Dritte mit dranhängen.
Andersherum: gerade wenn man die Dienste für Dirtte anbietet muß man
sehr genau darauf achten, keinen Müll auf die Systeme zu lassen, der ihre
Stabilität beeinträchtigt - das wäre sonst Fahrlässigkeit, wenn deshalb
Leistungen nicht erbracht werden könnten ...
Ralf Döblitz
> * Ullrich von Bassewitz <u...@spamtrap.musoftware.de> schrieb:
>
>> So eine Diskussion hatten wir schon oefters. Bloss weil ich einen
>> Telefonanschluss habe, bin ich nicht gezwungen, auch abzunehmen,
>> wenn Du anrufst.
>
> entspricht nämlich z.B. dem Lesen einer Mail.
>
> nicht eigenmächtig Anrufe bzw. Anrufsversuche vorenthalten.
Er darf aber Anrufer blocken, die durch vorschriftswidriges Verhalten
den ordnungsgemäßen Betrieb der Infrastruktur behindern oder gefährden,
z.B. durch wiederholten Verbindungsaufbau ohne ausreichende Wartezeiten
zwischen den Versuchen.
Bernd Hohmann
>>Der Dienstleister, der Dir Deine Telefonnummer verschafft hat, darf
>>nicht eigenmächtig Anrufe bzw. Anrufsversuche vorenthalten.
>
> Er darf aber Anrufer blocken, die durch vorschriftswidriges Verhalten
> den ordnungsgemäßen Betrieb der Infrastruktur behindern oder gefährden,
> z.B. durch wiederholten Verbindungsaufbau ohne ausreichende Wartezeiten
> zwischen den Versuchen.
Ich bin es von Deinem "Ortskollegen" Kollegen Helmut Hullen nun
langjährig seit Fido gewohnt, dass sich die Grenze zwischen gnadenloser
Ironie, völliger Realitätsferne und "das meine ich aber völlig Ernst"
erst bei mehrmaligen Lesen erschliesst.
Entweder verstehe ich zuwenig davon, oder zuviel.
Jedenfalls setze ich diese Runde aus.
Bernd
Heiko Schlenker
> In de.admin.net-abuse.mail Klaus Peukert <peu...@gmx.de> wrote:
>> Darf man "einfach so" Mails auf Grund technischer/inhaltlicher
>> Kriterien direkt am Server filtern/abweisen, die für Dritte bestimmt
>> sind?
[...]
> Abweisung: Ja.
So einfach ist's womöglich nicht. § 303a StGB lautet:
| (1) Wer rechtswidrig Daten (§ 202a Abs. 2) löscht, unterdrückt,
| unbrauchbar macht oder verändert, wird mit Freiheitsstrafe
| bis zu zwei Jahren oder mit Geldstrafe bestraft.
|
| (2) Der Versuch ist strafbar.
Aus "http://www.heise.de/ct/03/26/186/":
| Unter Daten versteht man Inhalte, die "elektronisch, magnetisch oder
| sonst nicht unmittelbar wahrnehmbar gespeichert sind oder
| übermittelt werden", also auch E-Mails.
Noch ein Aspekt. Aus dem bereits genannten Dokument:
| Anvertraut ist eine E-Mail dem Empfänger unzweifelhaft spätestens in
| dem Moment, wenn sie vollständig übertragen auf dem Mailserver
| liegt. Schwieriger zu beurteilen ist diese Frage bei Spam-Filtern,
| die bereits anhand der IP-Adresse eingehende Mails blocken, ohne
| dass diese samt Body gespeichert werden. Da jedoch das
| Fernmeldegeheimnis auch die Daten der Übermittlung - zu denen die
| IP-Nummer gehört - umfasst, hat in diesem Moment zumindest ein Teil
| der Mail (der Header) bereits den Empfänger erreicht und ist ihm
| anvertraut. Vergleichbar wäre dies etwa mit der ebenfalls
| unzulässigen Blockade von eingehenden Rufnummernblöcken im
| Telefonbereich.
IANAL, Heiko
Frank Ellermann
> Der Absender interessiert sich für die privaten Spamprobleme
> des Empfängers nicht die Bohne. Es ist reichlich unverschämt,
> wenn der Empfänger dem Absender vorschreiben will, *wie*
> Nachrichten abgeschickt werden müssen.
Du redest wirr. Zur Kommunikation braucht es die Kooperation
zwischen Sender und Empfaenger. Wenn irgendein Server nach
einem Terabyte Muell von spamcast IPs von denen nix mehr direkt
annimmt, dann sind das wohl keine "private Spamprobleme".
> Es reicht, wenn Spammer daran arbeiten, das Medium E-Mail
> unbrauchbar zu machen.
Bist Du in irgendeiner Zeitschleife gefangen ? Das Medium
_IST_ unbrauchbar gemacht worden, jede ungelesen vernichtete
Mail ist mit 75% bis 90% Wahrscheinlichkeit Muell gewesen...
...und bei der Rettung der vergleichsweise geringen Zahl von
erwuenschter Mail helfen Kriterien wie "spamcast IP" durchaus.
Bye, Frank
Bernd Hohmann
>>Der Absender interessiert sich für die privaten Spamprobleme
>>des Empfängers nicht die Bohne. Es ist reichlich unverschämt,
>>wenn der Empfänger dem Absender vorschreiben will, *wie*
>>Nachrichten abgeschickt werden müssen.
>
> Du redest wirr. Zur Kommunikation braucht es die Kooperation
> zwischen Sender und Empfaenger. Wenn irgendein Server nach
> einem Terabyte Muell von spamcast IPs von denen nix mehr direkt
> annimmt, dann sind das wohl keine "private Spamprobleme".
Was Heiko geschrieben hat, verstehe ich mit dem Hintergrund eines
täglichen Umgangs mit Mail und einem MTA ohne Probleme.
Worin genau Dein Problem steckt, verstehe ich nicht. Aber seit Fido ist
es wohl immer noch das Gleiche.
Bernd
Frank Ellermann
> Kuckmal Port 25 auf mail.harddiskcafe.de
Mit dem Multiline hatte mich damals schon Daniels Teergrube
erschreckt, nun bin ich mal gespannt, ob mein HELO.cmd Deine
Version durchhaelt...
<<< 220-Welcome to the Server of .e.n.t.f.e.r.n.t.
<<< 220-Strasse Hausnummer * PLZ Ort * GERMANY
<<< 220-Phone: +49-(0)-9999-123456 * Fax : +49-(0)-9999-123456
<<< 220-WARNING: Your mail will be usually accepted, but filtered
<<< 220-against several lists and RBLs later.
<<< 220 ZeroToaster 2.20w10 Digital VMS 5.1 (8 NODES, 48 CPU, 256 GB RAM)
>>> helo xyzzy.dnsalias.org
<<< 250 OK helo xyzzy.dnsalias.org
>>> mail from:<ab...@xyzzy.dnsalias.org>
<<< 250 OK mail from:<ab...@xyzzy.dnsalias.org>
>>> rcpt to:<postmaster>
<<< 556 RBL Blocked by dnsbl.njabl.org
>>> quit
<<< 221 OK donald.harddiskcafe.de says goodbye
...okay, DATA erlaube ich dem Skript ohnehin nicht, ich halte
nix von HELO ohne smtpd oder nicht-reply-faehigem MAIL FROM ;-)
[Suche eines zur Sender-IP passenden MX]
> Das war aber nicht so recht die Antwort auf Behauptung, dass
> die IP des Mailservers einen Backpointer "IP -> Sonstwas"
> haben muss.
Stimmt, Klaus fragte nach einer _technischen_ Begruendung, und
dazu fiel mir nix Zwingendes ein. Denn die Argumentation...
> Man kann einen fehlenden Backpointer "hopplahopp aufgesetztes
> system zum spamversand" oder als "hopplahopp aufgesetztes
> system zur kommunikation" betrachten.
...basiert doch wohl eher auf Erfahrung, das ist nicht zwingend
technisch kaputt. Also im Prinzip koennte alles, was bei SMTP
so klappen soll (Bounces etc.) funktionieren.
> Bei http://www.harddiskcafe.de/dscn0006.jpg hatte ich ganz
> andere Probleme als deine ,-)
LOL.
>>> Man muß auch nicht im Telefonbuch stehen um jemanden
>>> anzurufen.
>> Der Angerufene kann Anrufer von unbekannten Nummern abweisen.
>> Mache ich auf einer MSN so.
> Ja, man sollte seine Anrufer wirklich sorgfältig nach ihrer
> Qualifikation bei der Konfiguration eines ISDN-Telefons
> auswählen.
Erlaubt ist das (sinnvoll wohl weniger). Ich meinte mit EINER
MSN aber nicht die MSN, die ich normal benutze, sondern meine
i.d.R. ungenutzte dritte MSN. Ich hab so ein lustiges Telefon,
das je nach angerufener MSN anders klingeln kann.
Bye, Frank
Martin Liebeneiner
> *Du* in der Tat nicht. Aber die Mail ist nicht für Dich bestimmt,
> sondern für einen User Deines Servers. Dessen Kommunikation
> bevormundest Du ja. Um beim Telefon zu bleiben, du als Admin der
> TK-Anlage leitest Anrufer nach gewissen Kriterien direkt auf
> "Besetzt".
Hmm, der Vergleich hinkt gewaltig. Wenn dich jemand anruft, dann will er
dich in praktisch allen Fällen auch wirklich erreichen, um Informationen,
die dir etwas bringen, auszutauschen. Bei einem Mailserver gibt es viele
mails, die mich eigentlich gar nicht weiterbringen, aka Spam.
Wenn jetzt meinetwegen bekannt ist, dass Anrufe aus München praktisch alle
keinen Wertgehalt haben, wo ist dann das Problem, die Vorwahl 089 zu
blocken? Natürlich muss man immer noch eine "postmaster"-telefonnummer
haben, die nicht filtert, da stimme ich dir zu.
<persönliche Meinung>
Ich filtere alle Anrufer mit Rufnummer auch aus, bzw. lasse eine Ansage
abspielen, dass sie aus Versehen ihre Rufnummer nicht übermittelt haben und
diese, um mich zu erreichen, bitte einschalten sollen. Die Anzahl an
Umfragen und Werbeanrufen hat extrem nachgelassen. "False positives" hat es
bisher noch nicht gegeben.
</persönliche Meinung>
Und ein nicht unwesentlicher Faktor ist auch, dass du für eingehende
Telefonate im Moment noch keine Trafficgebühren bezahlst. Bei einem
Mailserver schon, und da kann es schon ganz sinnvoll sein, kaputte Server,
die überhaupt keinen PTR haben, zu blocken.
> Für den fehlenden PTR heißt das, Du läßt keine Anrufe rein, bei denen
> Du die Nummer nicht im Telefonbuch findest.
Wenn jemand unbedingt anonym bleiben will, bitte, kein Problem, aber man
darf sich dann halt nicht wundern, wenn andere Leute einen nicht beachten
bzw. die mails, deren Herkunft man nicht tendentiell überprüfen kann, halt
nicht angenommen werden.
Für dich dürfte es doch kein Problem sein, einen PTR zu setzen, warum machst
du hier dann solch ein Problem draus?
>>Es geht nicht so sehr um "korrekte" Hosts, sondern um "korrekte"
>>Mailserver. Waehrend es bei einem Mail ausliefernden Dialup Host sein
>>kann, dass dieser Probleme mit dem DNS hat ist das bei offiziellen
>>Mailservern nur sehr selten der Fall. Und Mails von Dialups, ADSL Ranges,
>>Kabelmodems usw. will man meistens sowieso nicht haben.
>
> Es *kann* aber der Fall sein.
Ach, wenn unter 25000 (geschätzt für letzte Zeit) Spam/Viren-mails von
dial-ups EIN host ist, der seine mails legitim versendet, soll ich also den
Traffic für 25000x $WURM bezahlen?
Da lege ich doch lieber dem einen Sender nahe, sich einen vernünftigen
Provider zu besorgen. Oder die angebotenen smtp-AUTH-server zu nutzen.
Ich bin im übrigen der Meinung, dass man getrost als ISP port 25 sperren
könnte, im Gegenzug muss dann natürlich zwingend ein kostenloser
SMTP-AUTH-Server vom Provider angeboten werden. Wenn ein Kunde unbedingt
selbst auf Port 25 was ausliefern will, kann er das gegen guten Aufpreis
gerne haben.
Wenn wirklich ALLE grossen Provider mitmachen würden und das passend in den
AGBs verankern, inklusive sofortiges Abklemmen plus einen guten Geldbetrag
pro Vorfall bei Wurmversendung, dann würden die User endlich aufwachen. Bei
Geld tuts nämlich erst weh...
Dann könnte man nämlich wunderbar nur mails von MXen annehmen, die in der
Liste der SMTP-AUTH-Server der Provider gelistet sind. Aber wahrscheinlich
wäre das zu einfach, oder ich hab irgendwas übersehen, was es so einfach
macht.
> Es gibt keinen technischen Grund, warum
> die IP des Mailservers einen PTR haben muss.
Stimmt, technisch nicht. Der Grund ist sozial bedingt. Bedank dich bei den
Spammern.
just my 2ct,
cu,
Martin
--
Es ist unwichtig, dass dieses Posting nachts geschrieben wurde.
Bitte auf eventuelle Postingfehler per PM hinweisen.
Ullrich von Bassewitz
>> Sorry, aber das ist Blödsinn; jeder Dailup-User kann (mindestens)
>> einen entsprechenden Smarthost und/oder MX benutzen.
>
> Richtig, *kann*. Es ist aber anmaßend, wenn der Empfänger den
> Absender /erwünschter/ E-Mails zum Gebrauch eines Smarthosts zwingen
> will.
Du unterstellst hier, dass jemand, der keine Mail von Dialups annimmt, das aus
erzieherischen Gruenden tut, oder weil die Einlieferer nicht leiden kann. Das
ist aber falsch. Ich wuerde liebend gerne Mails von Dialups annehmen, und ich
habe das frueher auch getan. Leider sehe ich mich aber nicht mehr dazu in der
Lage, wenn ich die grundsaetzliche Funktionsfaehigkeit des Mediums Email hier
bei mir garantieren will.
Das bedeutet, dass ich niemanden zum Gebrauch eines Smarthosts zwingen will.
Nichts laege mir ferner. Nur ist dann eben eine Maileinlieferung bei mir nicht
mehr moeglich. Das ist aber kein Problem, weil es genug andere Moeglichkeiten
gibt, mit mir (oder anderen, die ich mit Mail versorge) in Verbindung zu
treten. Jemand, der seine Mail nicht loswird, weil er per Dialup einliefert
kann mir gerne per Briefpost schreiben, ein Fax schicken oder was auch immer.
Wie bei vielen anderen Dingen auch ist Maileinlieferung kein Recht. Du kannst
nicht voellig abgerissen in ein Nobelrestaurant kommen, und - nachdem Du vor
die Tuer gesetzt worden bist - rumgreinen, dass es ja wohl Deine Sache waere,
was Du anhast. Natuerlich hast Du da recht - aber nur so lange, wie es
ausschliesslich Dich betrifft. Sobald Du etwas mit anderen zu tun hast, haben
diese aehnliche Rechte wie Du. In diesem Fall ist das das Recht, auf bestimmte
Kleidung zu bestehen. Es gibt genug andere Beispiele aus dem RL, wo es sich
aehnlich verhaelt, und dort ist das ganz normal. Und nur bei der
Emaileinlieferung sollen diese ganz normalen Regeln ploetzlich nicht mehr
gelten?
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
08:46:40 up 32 days, 10:40, 9 users, load average: 0.18, 0.50, 0.33
Ullrich von Bassewitz
>> Dialups *sind* Internetuser zweiter Klasse.
>
> Wie bitte? Wo wird denn das festgelegt?
Die Realitaet legt das fest. Und die hat staerkere Argumente als irgendwelche
RFCs:-)
> Tipp am Rande:
> http://homepages.tesco.net/~J.deBoynePollard/FGA/maps-dul-is-wrong.html
Das ist einer der duemmsten Texte, die ich je gelesen habe (und ja, ich kenne
den Text schon eine Weile), und in meinen Augen disqualifiziert sich jemand,
der diese URL zitiert selber. Wenn *das* die Argument der Dialup Befuerworter
sein sollen, dann gute Nacht.
Der Autor des Textes versucht noch nicht mal, Argumente vorzubringen, warum
man Mails von Dialups annehmen soll, er versucht lediglich die umgekehrten
Argumente zu widerlegen. Und das tut er zum einen lausig, zum zweiten ist der
Text ein paar Jahre alt (was man leicht daran erkennen kann, dass er sich auf
die MAPS-DUL bezieht, die heute nicht mehr sonderlich relevant ist). Das
meiste was er sagt hat sich durch die staendig steigende Spam Flut von selber
erledigt.
> Der Absender interessiert sich für die privaten Spamprobleme des
> Empfängers nicht die Bohne. Es ist reichlich unverschämt, wenn der
> Empfänger dem Absender vorschreiben will, *wie* Nachrichten
> abgeschickt werden müssen.
Dummerweise hat der Absender in diesem Fall aber absolut nichts zu sagen.
Seine Meinung ist aehnlich wichtig, wie der beruehmte Sack Reis, der in China
umfaellt. Es ist der Betreiber des Mailservers, der bestimmt, was er annimmt.
Und wenn Du ihn ueberreden willst, seine Policy zu ueberdenken, dann musst Du
mit Gruenden kommen, warum er Mails von Dialups annehmen soll, und nicht
irgendwas ueber die Rechte und Ansichten von Dialups erzaehlen.
> Derjenige, der filtert, möge doch bitte über die Folgen seines Tuns
> nachdenken, und zwar bevor die Filterregeln die Testphase verlassen.
Der unterschwellige Vorwurf, Leute die Dialups filtern haetten nicht
nachgedacht ist Unfug. Ich filtere seit geraumer Zeit Dialups, A-/S-DSL Pools,
Korea und China und die Folgen davon sind absolut positiv. Ich weiss mich
damit nicht alleine, und kann dieses Vorgehen wirklich jedem nur empfehlen,
der Wert darauf legt, Spam wirksam zu bekaempfen.
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
09:07:24 up 32 days, 11:01, 9 users, load average: 0.00, 0.01, 0.07
Ullrich von Bassewitz
>> Filtern mit DNSBLs ist Deiner Meinung nach unzulaessig, wenn die
>> Mails standardkonform sind?
>
> Kommt drauf an, welche System "blockiert" werden.
Schau her:-) Vorhin hast Du noch verlangt, eine RFC konforme Mail muesse
gruendsaetzlich angenommen werden:
> Wenn jemand eine standardkonforme E-Mail absetzt, dann darf man
> grundsätzlich erwarten, dass sie vom für den Empfänger zuständigen
> MTA angenommen wird.
Jetzt ist das ploetzlich vergessen, und es kommt auf die Filterkriterien an.
Und damit sind wir an dem Punkt, auf den ich im letzten Beitrag hingewiesen
habe: Du willst anderen ihre Filterkriterien vorschreiben. Im selben Atemzug,
in dem Du anderen vorwirfst, sie wuerden Dialup Benutzer zur Verwendung von
Smarthosts "zwingen", hast Du aber keinerlei Problem, von anderen bestimmte
Filterkritierien bei der Annahme von Mails auf ihren Systemen zu fordern.
Findest Du das nicht etwas schizophren?
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
09:20:52 up 32 days, 11:14, 9 users, load average: 0.00, 0.00, 0.00
Hatto von Hatzfeld
> * Ralf Döblitz <doeb...@doeblitz.net> schrieb:
>
> > In de.admin.net-abuse.mail Klaus Peukert <peu...@gmx.de> wrote:
> >> Darf man "einfach so" Mails auf Grund technischer/inhaltlicher
> >> Kriterien direkt am Server filtern/abweisen, die für Dritte bestimmt
> >> sind?
> [...]
> > Abweisung: Ja.
>
> So einfach ist's womöglich nicht. § 303a StGB lautet:
> | (1) Wer rechtswidrig Daten (§ 202a Abs. 2) löscht, unterdrückt,
> | unbrauchbar macht oder verändert, wird mit Freiheitsstrafe
> | bis zu zwei Jahren oder mit Geldstrafe bestraft.
> |
> | (2) Der Versuch ist strafbar.
>
> Aus "http://www.heise.de/ct/03/26/186/":
> | Unter Daten versteht man Inhalte, die "elektronisch, magnetisch oder
> | sonst nicht unmittelbar wahrnehmbar gespeichert sind oder
> | übermittelt werden", also auch E-Mails.
Das nach Annahme einer Mail vorgenommene Herausfiltern (Löschen) einer
Mail (ohne Auftrag des Empfängers oder Absenders der Mail) dürfte wohl
unstrittig unter den Straftatbestand fallen.
Meines Erachtens sieht das beim "Reject" einer Mail aber anders aus.
> Noch ein Aspekt. Aus dem bereits genannten Dokument:
> | Anvertraut ist eine E-Mail dem Empfänger unzweifelhaft spätestens in
> | dem Moment, wenn sie vollständig übertragen auf dem Mailserver
> | liegt. Schwieriger zu beurteilen ist diese Frage bei Spam-Filtern,
> | die bereits anhand der IP-Adresse eingehende Mails blocken, ohne
> | dass diese samt Body gespeichert werden. Da jedoch das
> | Fernmeldegeheimnis auch die Daten der Übermittlung - zu denen die
> | IP-Nummer gehört - umfasst, hat in diesem Moment zumindest ein Teil
> | der Mail (der Header) bereits den Empfänger erreicht und ist ihm
> | anvertraut.
Meines Erachtens wird bei dieser strengen Argumentation nicht
berücksichtigt, dass "Unterdrücken" auch bedeutet, dass die Daten
sozusagen vernichtet werden, vergleichbar mit dem Wegwerfen von
Werbesendungen durch den Postboten. Beantwortet ein Mailserver aber
einen Übertragungsversuch mit einem 5xx Code, dann war es eben nur ein
misslungener Übertragungs-*Versuch*; die Mail wurde nicht angenommen und
liegt bei standardkonformer Reaktion des einliefernden Servers/Clients
immer noch bei diesem. Das ist vergleichbar einem Postler am
Paketschalter, der einem sagt: "Tut mir Leid; dieses Paket hat ein
Format, das unseren Beförderungsbedingungen nicht entspricht." Dem
Absender ist dann klar, dass es nicht angenommen wird; denn er hat die
Sendung sozusagen noch in der Hand.
> | Vergleichbar wäre dies etwa mit der ebenfalls unzulässigen
> | Blockade von eingehenden Rufnummernblöcken im Telefonbereich.
Wo steht eigentlich, dass eine Firma das nicht darf? Nicht, dass ich mir
das nicht vorstellen kann; aber ich wüsste im Augenblick nicht die
Rechtsquelle.
Abgesehen davon hinkt die Analogie darin, dass beim Telefonanruf der
Anrufer den wesentlichen Kostenanteil trägt, während bei der Spammail
den annehmenden Server ein wesentlicher Anteil des Aufwands trifft. Da
müssen dann eigentlich auch andere Maßstäbe an die Pflichten zur Annahme
bzw. das Recht zur Kommunikationsverweigerung gelegt werden.
Grüße,
Hatto
--
Das Shaw-Prinzip:
Entwickle ein System, das narrensicher ist,
und nur ein ein Narr wird es benutzen wollen.
Wolfgang Jäth
>
> > Abweisung: Ja.
>
> So einfach ist's womöglich nicht. § 303a StGB lautet:
> | (1) Wer rechtswidrig Daten (§ 202a Abs. 2) löscht, unterdrückt,
> | unbrauchbar macht oder verändert, wird mit Freiheitsstrafe
> | bis zu zwei Jahren oder mit Geldstrafe bestraft.
Ja und? Inwiefern betrifft das jemanden/einen Server, der sich weigert, die
Daten anzunehmen? Betrachtest Du das Nichtspeichern nichterhaltener Daten
etwa schon als 'löschen'?
> Noch ein Aspekt. Aus dem bereits genannten Dokument:
> | Anvertraut ist eine E-Mail dem Empfänger unzweifelhaft spätestens in
> | dem Moment, wenn sie vollständig übertragen auf dem Mailserver
> | liegt.
Eben; und wenn man die Daten erst gar nicht annimmt, können sie schwerlich
auf dem Server vorliegen ...
Wolfgang
--
Bernd Hohmann
> <<< 250 OK mail from:<ab...@xyzzy.dnsalias.org>
>>>>rcpt to:<postmaster>
> <<< 556 RBL Blocked by dnsbl.njabl.org
Oh Scheisse, da erinnerst Du mich an ein Problem.
Bernd
Clemens Zauner
>>> Sorry, aber das ist Blödsinn; jeder Dailup-User kann (mindestens)
>>> einen entsprechenden Smarthost und/oder MX benutzen.
>>
>> Richtig, *kann*. Es ist aber anmaßend, wenn der Empfänger den
>> Absender /erwünschter/ E-Mails zum Gebrauch eines Smarthosts zwingen
>> will.
> Du unterstellst hier, dass jemand, der keine Mail von Dialups annimmt, das aus
> erzieherischen Gruenden tut, oder weil die Einlieferer nicht leiden kann. Das
> ist aber falsch. Ich wuerde liebend gerne Mails von Dialups annehmen, und ich
> habe das frueher auch getan. Leider sehe ich mich aber nicht mehr dazu in der
Gut, das ist ein vielleicht schlechtes Beispiel, da nicht immer die
Zeit ueberall dazu vorhanden ist. Aber ich pflege meine Dialup-Boesewichte
von Hand.
Alos wenn ein ISP / Netz nicht in der Lage ist, irgendwie seine
User unter Kontrolle zu halten, nehme ich von deren Kundenraum
prinzipiell keine EMails mehr direkt an.
Die Begruendung retourniere ich auch per 55x. Die Folge ist: Kunde bei
einem Whitehat darf direkt einliefern, andere Pools, die permanent negativ
auffallen, nicht (z.B: \..+\.comcast net, abo.wanadoo.fr, dsl.telesp.net.br,
... )
Das ist natuerlich sehr zeitaufwendig. Alleine das mitlesen in nan-ae
verschlingt Stunden ...
cu
Clemens.
--
/"\ / (G. Scott Granados:) And God spoke.
\ / ASCII RIBBON CAMPAIGN/ There shal be packets.
X AGAINST HTML MAIL / And there were packets,
/ \ AND POSTINGS / these packets were good, mostly.
Ralf Döblitz
>> ein hinreichend klarer Verstoß gegn die technichen Normen,
>
Hatte der OP doch schon in seienr Frage mit angegeben: die Vorschriften
aus RFC1123 darüber, was einen ordentlichen Host darstellt. Und ein
System, das bei einem MX Mail einliefern will, muß ganz offensichtlioch
ein Host sein.
Ralf Döblitz
> * Ullrich von Bassewitz <u...@spamtrap.musoftware.de> schrieb:
>
>
> Wie bitte?
Leicht unscharf formuliert, er meinte wohl eher "Dialup-User mit
dynamischer Adreßzuweisung".
> Wo wird denn das festgelegt?
Vom Provider, der ihnen noch nicht einmal eine IP-Adresse zuweist.
Denn User mit fester IP-Adresse kann man bei Fehlverhalten leicht(er)
ermit- teln und auch recht unproblematisch aussperren. (Pseudo-)Anonymi-
tät ist im Geschäftsverkehr nicht überall erwünscht, abseits des Ver-
kaufs dirket über den Ladentisch will man mit soolchen Subjekten keine
Verträge schließen, da man ihre Erfüllung kaum erzwingen kann bzw. dies
viel zu hohen Aufwand verursacht.
Ich hätte auch kein Problem damit, Dialup-User mit dynIP als normale
Netzteilnehmer zu behnadeln,. wenn sie sich z.B. durch SSL-Zertifikate
ausweisen. Damit könnte man sehr gut ein Whitelisting auf dem Mailserver
vornehmen (JFTR: ist rein hypothtisch, da ich dynIP-Dialups bisher nicht
blocke).
Ralf Döblitz
> Ralf Döblitz wrote:
>
>>>Der Dienstleister, der Dir Deine Telefonnummer verschafft hat, darf
>>>nicht eigenmächtig Anrufe bzw. Anrufsversuche vorenthalten.
>>
>> Er darf aber Anrufer blocken, die durch vorschriftswidriges Verhalten
>> den ordnungsgemäßen Betrieb der Infrastruktur behindern oder gefährden,
>> z.B. durch wiederholten Verbindungsaufbau ohne ausreichende Wartezeiten
>> zwischen den Versuchen.
>
> Ich bin es von Deinem "Ortskollegen" Kollegen Helmut Hullen nun
> langjährig seit Fido gewohnt, dass sich die Grenze zwischen gnadenloser
> Ironie, völliger Realitätsferne und "das meine ich aber völlig Ernst"
> erst bei mehrmaligen Lesen erschliesst.
Dir ist noch in Erinnerung, daß Modems Wahlwiederholungssperren
enthalten mußten (bzw. noch müssen)? Daß die Telekom den Anschluß
abschalten konnte, wenn man doch extrem häufig Anwahlen mit minimalem
Abstand ausgelöst hat (natürlich nur solange bis ein Techniker den
anscheinend defekten Anschluß bzw. das scheinbar defekte Endgerät
entstört hat)? Daß man AFAIK immer noch Vermittlungsstellen mit genau
obigem (Fehl-)Verhalten zum Absturz bringen kann? Daß ein abgehobener
Hörer ohne nachfolgenden Wahlversuch ebenfalls nach einigen Stunden zu
einer Deaktivierung des Anschlusses führen konnte?
Ralf Döblitz
> * Ralf Döblitz <doeb...@doeblitz.net> schrieb:
>
>> In de.admin.net-abuse.mail Klaus Peukert <peu...@gmx.de> wrote:
>>> Darf man "einfach so" Mails auf Grund technischer/inhaltlicher
>>> Kriterien direkt am Server filtern/abweisen, die für Dritte bestimmt
>>> sind?
> [...]
>> Abweisung: Ja.
>
> So einfach ist's womöglich nicht. § 303a StGB lautet:
> | (1) Wer rechtswidrig Daten (§ 202a Abs. 2) löscht, unterdrückt,
> | unbrauchbar macht oder verändert, wird mit Freiheitsstrafe
> | bis zu zwei Jahren oder mit Geldstrafe bestraft.
> |
> | (2) Der Versuch ist strafbar.
>
> Aus "http://www.heise.de/ct/03/26/186/":
> | Unter Daten versteht man Inhalte, die "elektronisch, magnetisch oder
> | sonst nicht unmittelbar wahrnehmbar gespeichert sind oder
> | übermittelt werden", also auch E-Mails.
Eben. Das spricht ganz einduetig gegen Filterung, bei einem Reject im
SMTP-Dialog lehnt man aber nur die Übernahme der Verantowrtung für den
weiteren Transport der EMail ab, man nimmt sie einfach nicht an, man
vernichtet diese Daten aber nicht. Wenn letzteres dann durch den MTA des
Absenders geschieht ist das nicht mein Problem, sondern das des Betrei-
bers jenes MTAs und eben genau der Grund, warum ich von bestimmten Enve-
lope-Froms grundsätzlich keine MAils annehme.
> Noch ein Aspekt. Aus dem bereits genannten Dokument:
[...]
> | dass diese samt Body gespeichert werden. Da jedoch das
> | Fernmeldegeheimnis auch die Daten der Übermittlung - zu denen die
> | IP-Nummer gehört - umfasst, hat in diesem Moment zumindest ein Teil
> | der Mail (der Header) bereits den Empfänger erreicht und ist ihm
Das ist ganz klar falsch. Die IP-Adresse des einliefernden Systems
gehört z.B. nicht in den Header und damit hat zu diesem Zeitpunkt eben
nicht "zumindest ein Teil der Mail (der Header) bereits den Empfänger
erreicht". Und die Inofrmation darüber, welches System die Mail einlie-
fert ist für die technische Abwicklung notwendig (TCP) und darf damit
vom Mailprovider ausgewertet werden.
Ralf (IANAL2)
Nils Bronstert
> * Ullrich von Bassewitz <u...@spamtrap.musoftware.de> schrieb:
>
> > Dialups *sind* Internetuser zweiter Klasse.
>
> beispielsweise nicht.
Das ist eben das Problem. Dial-Up-User werden zu Usern zweiter Klasse
abgestempelt. Und es ist traurig, daß Spammer es geschafft haben, das
(sonst gleichberechtigte) Internet in diesem Bereich schon so weit zu
zerstören.
> > Die Frage hat sich aber inzwischen von selber beantwortet, weil
> > Blocken von Dialups nicht nur ein bisschen, sondern deutlich gegen
> > Spam und diverse Email Viren/Wuermer hilft.
>
> Dabei wird allerdings erheblicher Schaden angerichtet. :-( Übrigens,
> gemäß der o.g. RFCs ist die Direktzustellung der *Normalfall*.
> Tipp am Rande:
> http://homepages.tesco.net/~J.deBoynePollard/FGA/maps-dul-is-wrong.html
>
> Der Absender interessiert sich für die privaten Spamprobleme des
> Empfängers nicht die Bohne. Es ist reichlich unverschämt, wenn der
> Empfänger dem Absender vorschreiben will, *wie* Nachrichten
> abgeschickt werden müssen.
Das kann ich jetzt allerdings nicht nachvollziehen. Natürlich darf der
Empfänger dem Absender vorchreiben, wie er Nachrichten abschicken
muß. Es ist in keiner Weise unverschämt. Es ist nur schade, daß sich die
Empfänger den Spammern geschlagen geben.
> Kein normaler Mensch käme auf die Idee,
> einem Briefpost-Absender vorzuschreiben, bestimmte Briefzentren zu
> benutzen.
Schlechter Vergleich.
> Derjenige, der filtert, möge doch bitte über die Folgen seines Tuns
> nachdenken, und zwar bevor die Filterregeln die Testphase verlassen.
Ja, aber das kannst Du natürlich niemandem vorschreiben. Du kannst nur
sagen: "Ich fände es besser, wenn ..." oder "Ich finde es nicht so gut,
wenn ...", aber ansonsten hat natürlich der Empfänger die absolute
Kontrolle über sein eigenes System. Und das ist gut so [tm].
> Es reicht, wenn Spammer daran arbeiten, das Medium E-Mail
> unbrauchbar zu machen. Auf die Unterstützung gedankenloser
> Mailserverbetreiber sind sie nicht angewiesen. :->
Ich sehe es so: Ich werde den Spammern nicht die Freundlichkeit und
Offenheit meines Teils des Internets opfern. Ich werde aber ganz sicher
nicht freundlich und offen zu Spammern oder deren direkten Unterstützern
sein. So kann es meiner Meinung nach funktionieren, wenn viele es so
machen. Alles andere wäre schade und ein echter Verlust für das
Internet.
Gruß
--
Nils Bronstert /// C= Amiga ,''`. In a world without
mailto:bro...@fh-worms.de /// PPC 604e 266 MHz : :' : walls and fences,
\\\/// 68060 50 MHz `. `' nobody needs
\XX/ Debian GNU/Linux `- Windows and Gates.
Nils Bronstert
> Heiko Schlenker <hsc...@gmx.de> wrote:
> > > Sorry, aber das ist Blödsinn; jeder Dailup-User kann (mindestens)
> > > einen entsprechenden Smarthost und/oder MX benutzen.
> >
> > Richtig, *kann*. Es ist aber anmaßend, wenn der Empfänger den
> > Absender /erwünschter/ E-Mails zum Gebrauch eines Smarthosts zwingen
> > will.
>
> Du unterstellst hier, dass jemand, der keine Mail von Dialups annimmt, das aus
> erzieherischen Gruenden tut,
Naja, den Eindruck kann man schon manchmal gewinnen ... aber siehe
unten ...
> [viel Richtiges über die Dial-Up-Problematik]
Du hast natürlich vollkommen Recht. Aber ich glaube auch gar nicht, daß
Dein Vorposter die Lage verkannt hat. Ich denke, den meisten hier ist
völlig klar, daß immer erst einmal gilt: "Dein Server, Deine Regeln".
Ich finde es nur traurig, daß es schon so weit gekommen ist, daß man
völlig Unschuldige, am Spamproblem nicht beteiligte, ohne einen Grund
von E-Mail ausschließt. Das zeugt davon, daß das einst sehr offene und
freundliche Internet, durch die Spammer zu einem Netz des Mißtrauens
wird. User, die eine bestimmte Anbindung ans Internet haben, werden zu
Usern zweiter Klasse degradiert. Ja, natürlich darf jeder selbst
entscheiden, was er annimmt und von wem er es annimmt. Das würde ich
auch niemals ändern wollen. Aber ich finde es einfach traurig, daß man
als Dial-Up-User oft nur noch eingeschränkten Zugang hat - und das nur
wegen der Spammer. Nicht mehr und nicht weniger.
Nils Bronstert
> > > Darf man "einfach so" Mails auf Grund technischer/inhaltlicher
> > > Kriterien direkt am Server filtern/abweisen, die für Dritte bestimmt
> > > sind?
> > übertragen oder vernichtet und der Absender erhält eine Fehlermeldung.
> > Der Absender hat also bestimmt kaum eine Grundlage für eine Klage. Wenn
> > dann nur der Empfänger. Ich bin aber kein Anwalt. Es gibt schließlich
> > manchmal schon sehr seltsame Urteile ...
>
> Wie legitimiere ich das gegenüber meinen Kunden/Mitarbeitern, denen am
> Empfang einer solchen Mail ja durchaus gelegen sein kann?
Z. B. indem ich ihn vorher frage, ob das Blocken von Mails mit Kriterium
x, y und z so in Ordnung geht. Das ist sicher die sauberste Variante.
> *Ich* weiß
> doch nicht, welche Mails mein User für wichtig erachtet. Er könnte
> sich ja für Viagra o.ä interessieren. Oder über Spam/Viren forschen
> bspw.
Wenn er aber sagt, daß er von Open Relays keine Mails erhalten möchte?
Soll ich dann gegen seinen Wunsch handeln? Und damit vielleicht
riskieren, daß sein Postfach überläuft und er gar keine Mails mehr
empfangen kann oder er seine legitimen Mails aus Versehen lösht, weil
99% seiner Mails Spam ist?
> Ich glaub irgendwie nicht, daß ich Kraft meiner Wassersuppe das
> entscheiden darf.
Wenn der Mailbetrieb anders nicht mehr sinnvoll aufrecht zu erhalten
ist, darf man das meiner Meinung nach. Aber es gibt da noch kein Urteil
dazu. Wir wissen es letztlich also beide nicht so genau. Auf der absolut
sicheren Seite dürfte man sich aber befinden, wenn der Kunde das so
wünscht, also das Blocken zur Kenntnis genommen hat und es nicht
deaktiviert haben möchte.
> > Du meinst in einem Betrieb, der Mails empfängt? Wird wohl am besten so
> > sein. Aber auch ohne Zustimmung könnte ich mir das durchaus
> > vorstellen. Schließlich muß man ja als Provider für die störungsfreie
> > Zustellung der Mails sorgen, also dafür, daß möglichst keine Mails
> > verlorengehen.
>
> Wie sollen Mails verlorengehen, wenn ich *nicht* blocke? Ich krieg ja
> dann eher deutlich mehr Mails. Und Fehler/Unachtsamkeiten beim "JHD"
> sind Fehler des Users --> sein Pech.
Naja, ich frage mich, wie ein Kunde das sieht, wenn ich ihm sage, daß
ich gegen Spam nichts unternehme und er aber täglich hunderte bis
tausende von Spams in seinem Postfach hat (davon vielleicht 5 legitime
Mails) und er zum ersten Mal eine wichtige Mail aus Versehen gelöscht
hat, weil er zu schnell auf "Del" gedrückt hat?
Und wie sieht's mit zu vollem Postfach durch Spams aus?
> > Der Absender hat meiner Meinung nach dabei nichts zu sagen. Der
> > Empfänger evtl. schon (aber nicht unbedingt).
>
> Was, wenn Sender und Empfänger eine geschäftliche Beziehung haben
> (oder meinetwegen auch eine persönliche)? Welches Recht habe ich als
> Postmaster, diese Kommunikation zu unterbinden? Keins, IMHO.
Wie sieht's denn aus, wenn der Absender folgendes macht:
| $ telnet mail.empfaengerdomain.example 25
| HELO äöüßÄÖÜß!"§$%&/()=?_
| MAIL FROM: §"$%"§$%§$%&
| RCPT TO: geschaef...@empfaengerdomain.example
| Dies ist meine Nachricht
| Wichtig!
(Ja, das DATA fehlt absichtlich.)
Warum kommt die Nachricht nicht an? Blockst Du etwa Mails? Du hast kein
Recht, die Kommunikation mit dem Geschaeftspartner zu unterbinden. Es
ist doch eindeutig, was der Absender wollte. Er wollte, daß seine
unglaublich wichtige Nachricht an
geschaef...@empfaengerdomain.example ausgeliefert wird. Daß er
allgemeine E-Mail-Regeln nicht beachtet hat, ist ja irrelevant.
Muß aber gar nicht so schlimm sein. Was ist, wenn das DATA vorhanden und
das MAIL FROM: syntaktisch korrekt ist, aber eine nicht existierende
Domain enthält? Muß ich das annehmen? Der Absender ist ja
offensichtlich gefälscht. Oder hat sich der Absender nur vertippt? Was
ist, wenn nur das HELO syntaktisch inkorrekt ist? Was ist, wenn es nicht
syntaktisch aber inhaltlich inkorrekt ist?
Um es kurz zu machen: Muß ich jeden Müll, der ankommt irgendwie
ausliefern, egal wie übel das ist? Wie siehts mit Mails von Open Proxys
aus - also Rechnern, die gar nicht für den Mailversand gedacht
sind. Oder was ist bei Open Relays? Wie ist es mit Mails von Providern,
die unser Netz zu ihrem finanziellen Vorteil (und unserem finanziellen
Nachteil) ausnutzen, um Spam an uns und unsere Kunden auszuliefern? Darf
ich mich und unsere Kunden nicht vor Angriffen aus dem Netz schützen?
Muß ich bildlich gesehen meine Haustür offen stehen lassen?
Nein, nein, so einfach wie Du es darstellst ist es nicht.
Fazit: Jeder blockt Mails, es fragt sich immer nur wie viel man blockt,
also wo die annehmbare Grenze für den eigenen Kunden liegt. Und die
liegt inzwischen meiner Erfahrung nach weit im Bereich des umfassenden
Blockens. Die Kunden "flehen" mich teilweise an, ob ich nicht noch etwas
tun könne, um die Spamflut zu verringern. Natürlich werde ich den
Wünschen *unserer* Kunden entsprechen und nicht etwa den Wünschen
anderer, die mit uns gar keinen Vertrag haben.
Mal ehrlich: Wenn es rechtlich nicht klar ist, was genau zulässig ist
und was nicht und wenn die Mehrzahl der Kunden Anti-Spam-Maßnahmen
*wünscht*, dann dürfte völlig klar sein, was zu tun ist, um Geld zu
verdienen und die Kunden nicht zu verlieren.
Nils Bronstert
> > das Blocken von dial-Up-Usern finde ich nicht gut.
>
> Wenn ich User bei Dir waere, wuerde ich Dich auf Knien
> anflehen, wenigstens spamcast IPs zu blocken.
Kein Problem, :-)
die sind bei uns seit einiger Zeit komplett geblockt (wenn Du die
Blockliste als Neukunde von uns aktivieren läßt, was ich natürlich immer
empfehlen kann). Also kein Grund gleich auf die Knie zu fallen ... ;-)
Blocklisten finde ich nämlich durchaus gut. Auch SPEWS ist kein Problem
für mich. Nur Dial-Up-Listen zum Blocken finde ich eben nicht so gut.
> Das hat
> IMHO auch was mit dem jeweiligen abuse management zu tun,
Ja.
Nils Bronstert
> > Fehlt der PTR oder landet der nicht wieder beim HELO-Namen kassiert
> > man den 550.
>
> Was nun? Double Reverse Lookup oder HELO Verification, welches von
> beidne meinst du? Ersteres ist IMNSHO vollkommen in Ordnung, letzeres
> eindeutig RFC-widrig (bei falschem HELO/EHLO muß die Mail trotzdem
> angenommen werden (RFC2821, 4.1.1):
Wobei im RFC natürlich eine Verifikation des *Inhalts* gemeint ist,
unter der Voraussetzung, daß dieser syntaktisch korrekt ist. Mit anderen
Worten: Eine syntaktisch korrekte aber nicht existierende Domain (wie
z. B. foo.domain.example) im HELO darf man laut RFC nicht abweisen, wohl
aber syntaktisch inkorrekten Datenmüll wie z. B. pc1_foo.domain.example.
> [...]
> > Mir ist unklar, wie man ernsthaft eine solche "Lösung" nutzen kann und
> > als Begründung mehr oder weniger immer ein "Von solchen Systemen kommt
> > eh nur Schrott" kommt. Wenn man keine Mail will, soll man halt keinen
> > Server betreiben.
>
> Bei Double Reverse Lookup ist der Hintegrrund ganz simpel: wer so
> elemantare Grundlagen nicht hinbekommt (das macht ja normalerweise die
> LIR von der man den Netzblock bekommt, falls sie einem die Reverse
> Delegation nicht eh gibt), der wird seinen Mailserver erst recht nicht
> im Griff haben. Und da erspart man sich viel Ärger, wenn man präventiv
> von solch fehlkonfigurierten Systemen erst einmal keine Daten annimmt,
> egal ob es nun um Mail, FTP oder SSH-Logins geht. Schließlich besteht
> ein Teil der Aufgabe eines Serverbetreibers auch darin, seine Server
> (und dait die Daten der Kunden) vor Beschädigung z schützen, egal ob
> diese vorsätzlich (Angriffe gegen die Server, Computersabotage) oder
> fahrlässig (fehlkonfigurierte Systeeme) verursacht würden.
Ja.
> [...]
> > nen X-Header
> > einsetzen, was ins Subject schreiben, den "Spam-Score" erhöhen oder
> > so.
>
> Nein. Das wäre alles Filterung, eine Modifikation der Kommunikations-
> inhalte, *das* genau ist ohne expliziten Auftrag des Kunden *nicht*
> zulässig.
Ähm, da würde ich aber differenzieren. Schließlich schreibt ein
Mailserver immer etwas in den Header der Mail hinein, wenn er eine Mail
annimmt. Somit halte ich ein Einfügen eines "X-RBL-Warning: IP
xxx.xxx.xxx.xxx is in SpamCop" z. B. für völlig unproblematisch. Eine
Veränderung des Subjects oder gar des Bodys einer E-Mail ist natürlich
was anderes. Da wird schließlich die Nachricht selbst verändert. Das
sollte nur mit explizitem Einverständnis des Kunden erfolgen.
> > Aber bei dem Risiko, die Mails abzulehnen, daß kann man auf nem
> > privaten Host machen, der nur für einen selbst werkelt, aber doch
> > nicht wenn Dritte mit dranhängen.
>
> Andersherum: gerade wenn man die Dienste für Dirtte anbietet muß man
> sehr genau darauf achten, keinen Müll auf die Systeme zu lassen, der ihre
> Stabilität beeinträchtigt - das wäre sonst Fahrlässigkeit, wenn deshalb
> Leistungen nicht erbracht werden könnten ...
Genau so sehe ich das auch.
Rainer Zocholl
>* Ullrich von Bassewitz <u...@spamtrap.musoftware.de> schrieb:
>> Dialups *sind* Internetuser zweiter Klasse.
>Wie bitte? Wo wird denn das festgelegt? In RFC 821 bzw. 2821
>beispielsweise nicht.
Bitte klar zwischen "dial ups" und "dynamischen IP" unterscheiden!
Das Problem sind die ständig hinter den dyn-IP wechselnden hosts,
nicht, dass sie nicht ständig online sind!
(Letzeres wäre sogar ein Vorteil)
FYI:
Zwischen ca. dem 20. und 30. Dezember sollten hier ca. 6000 -eindeutige-
Spam+Wurm mails eingeliefert werden, von 3000(!) - in Worten
dreitausend(!)- *unterschiedlichen* T-Online-Dyn-IP!
Das waren weder 3000 unterschiedliche Rechner noch ein
Rechner der 3000 IP bekommen hatte...
Ein gezieltes Blocken der Wurmschleuder/Zombies war somit unmöglich.
Eine Antwort von T-Online das sie die Belästugungen abgestellt
haben habe nicht erhalten. War wohl zuviel Arbeit auf einmal
für die, 3000 IP zu überprüfen und ne Antwort zuschicken und hätte
das 2. Frühstück verhindert? Auch bestände ja die Gefahr das
Ende diesen Monats wieder ne Beschwerde mit zu prüfenden
3000 IP/Uhrzeit Dupels kommen...also schnell "Delete" gedrückt?
Oder soll ich das auf eine tägliche, automatische email umstellen?
Was anderes willst Du machen, als das gesamte T-Online-Gesox
auszusperren, wenn Du Deinen Traffic und Deine Rechner
selbst MBweise BEZAHLEN musst?
Das "Dyn.IP" ist einzig "Marketing". Damit soll(te) nur ein Unterscheidungs-
kriterium zu teueren "Business Tarifen" mit fester IP erzeugt
werden und der (meist traffic intensiver) Serverbetrieb verhindert werden.
Also klar: Dyn.IP ist 2. Wahl.
Aber:
Früher mag das tatsächlich mal funktioniert haben. Heute ist
es obsolete, denn dank dyndns ist es kein Problem sogar einen SMTP-server
auf einer dyn.IP laufen zu haben! Es bleiben aber die Nachteile,
vorallem für das Netz!
Dank "Kazaa"&Co. und dyn-IP haben sogar Leute die NIE etwas
mit P2P-Netzwerken zu tun hatten, einen merklichen Traffic
nur durch die Verbindungsversuche, wenn sie eine IP bekommen,
auf der vorher eine P2P-Software lief...
Natürlich kommt es der Telekom SEHR zu pass, das ihre dyn.IP
geblockt werden! So können sie ihre Kunden weiter abkassieren,
z.B. f. smtp-relay.
Profit auf Kosten des restlichen Netzes, die unter den
nicht sperrbaren Wurmschleudern zu leiden haben und
das Medium SMTP verkrüppeln müssen, wollen sie nicht vor der nächsten
IP-Rechnung zittern.
Die paar IP-# die T-Online mehr bräuchte um zumindest
ihre Flatrate-ADSL User mit einer festen IP versorgen sind
KEIN Problem, das erst mit IPv6 gelöst werden könnte,
weil es ja keine freien v4 mehr gäbe.
Das man keine IP mehr habe ist eine reine Marketing-Gelüge
um weiter am profitablen aber netzschädlichen dyn.IP festzuhalten.
Wilfried Kramer
> Ja, leider. Es macht die Dial-Up-User zu Internetusern zweiter
> Klasse.
Was sie definitiv sind.
Jemand mit einer festen IP-Adresse ist anhand dieser eindeutig
identifizierbar. Jemand mit einem Dial-up nicht.
Gruß von Wilfried
--
Können eines "Chef bestimmt, Du bist jetzt Admin":
In Wirklichkeit besteht die einzige Qualifikation darin, daß die Anderen in
der Firma _noch_ weniger Ahnung haben; und das _geht_ dann früher oder
später schief. [Wolfgang Jaeth in hamster.de.usehamsternet]
Bernd Hohmann
> Natürlich kommt es der Telekom SEHR zu pass, das ihre dyn.IP
> geblockt werden! So können sie ihre Kunden weiter abkassieren,
> z.B. f. smtp-relay.
Ich habe bis heute nicht verstanden, für was man das T-Online SMTP-Relay
überhaupt benötigt.
POP3 mit dem einen Provider und SMTP über den anderen ist irgendwie
nicht so der Bringer.
Bernd
Ralf Döblitz
[...]
> Ähm, da würde ich aber differenzieren. Schließlich schreibt ein
> Mailserver immer etwas in den Header der Mail hinein, wenn er eine Mail
> annimmt.
Ja, aber nur in genau dem Maß, das durch die technsichen Normen vorgege-
ben ist. Alles andere, was darüber hinausgeht und nicht unmittelbar zur
Erbringung der Kommunikationsleistung notwendig ist, ist IMHO vom Kunden
zu legitimieren.
> Somit halte ich ein Einfügen eines "X-RBL-Warning: IP
> xxx.xxx.xxx.xxx is in SpamCop" z. B. für völlig unproblematisch. Eine
> Veränderung des Subjects oder gar des Bodys einer E-Mail ist natürlich
> was anderes. Da wird schließlich die Nachricht selbst verändert. Das
> sollte nur mit explizitem Einverständnis des Kunden erfolgen.
Die Header gehöen auch mit zur Nachricht. Was ist, wenn durch den
eingebrachten Header die Mail beim Kunden geschrottet wird, wegen eines
Headers, der in der Mail des Absneders nicht vorkam? Probier doch mal,
den EICAR-Teststring in einem X-Header in die Mails einzufügen, dürfte
gemäß deiner obigen Aussage ja eigentlich unproblematisch sein.
Ralf