RMX-Einträge im DNS
Erik Griffin
Ich habe vor einigen Tagen gelesen, dass man das SPAM-Problem mit
sogenannten RMX-Einträgen im DNS lösen will. Dazu will man das
DNS-Protokoll entsprechend erweitern. Irgendwie soll das wohl so
vonstatten gehen (ich hab das nicht mehr genau in Erinnerung), dass die
Domain im From-Header überprüft wird, ob sie im entsprechenden
RMX-Eintrag zu finden ist. Falls nicht, wird die Mail nicht verschickt.
Als Problem wurde dargestellt, das man keine Mails mehr über einen
eigenen, via Dial-in angeschlossenen, SMTP-Server verschicken kann. Das
interessiert mich momentan nicht so unbedingt, wird es aber evtl.
irgendwann mal.
Was haltet ihr vom RMX-Einträgen? Sind die sinnvoll? Kann evtl. noch mal
jemand genau erklären was die so machen?
mfg
Erik
Frank Ellermann
> Falls nicht, wird die Mail nicht verschickt.
s/verschickt/angenommen/
> Kann evtl. noch mal jemand genau erklären
Der empfangende Server (MX) notiert sich ohnehin die IP des
sendenden Systems (fuer die Received:-Zeile). Ausserdem
notiert er sich den "Mail From" (fuer den Return-Path:).
An der Stelle schnappt er sich den rechten Teil (@domain)
und fragt via DNS nach dem RMX. Und wenn es einen RMX gibt,
und da eine oder mehrere IPs stehen, und die im am Anfang
notierte IP _nicht_ dabei ist, sagt er "verpiss Dich" (also
nimmt den Spam nicht an).
So zumindest habe ich den Artikel verstanden, siehe auch
parallel <URL:news:3F9553...@xyzzy.claranet.de>
Klingt IMHO nicht schlecht, aber ich kenne DNS nicht gut,
ob das bei _vielen_ IPs (T-Online hat ca. ein Dutzend) auch
hinhaut, waere 'ne Frage.
Probleme mit dynamischen IPs sehe ich nicht spontan. Wenn Du
eine "eigene" DynDNS Domain hast, traegst Du entweder keinen
RMX fuer diese Domain, oder eben die IP, die Du gerade hast...
wenn DynDNS das mal unterstuetzt.
Bye, Frank
Uwe Schröder
> An der Stelle schnappt er sich den rechten Teil (@domain)
> und fragt via DNS nach dem RMX. Und wenn es einen RMX gibt,
> und da eine oder mehrere IPs stehen, und die im am Anfang
> notierte IP _nicht_ dabei ist, sagt er "verpiss Dich"
Super. Dann würde endgültig keine einzige Mailweiterleitung mehr
funktionieren. *kopfschüttel*
usch
Frank Ellermann
> Dann würde endgültig keine einzige Mailweiterleitung mehr
> funktionieren.
Wer relayen will, traegt vielleicht einfach keinen RMX ein.
Oder benutzt eines von diesen altmodischen Relay-Konstrukten
in der Mail From Syntax. Oder uebernimmt die Verantwortung
fuer die Weiterleitung (eigenes Mail From), in der Received-
Zeile notiert, woher es wirklich kam, um spaeter ein Bounce
an die richtige Stelle zurueckleiten zu koennen.
> *kopfschüttel*
Hilft das beim Denken ? Ich glaube, mir hilft eher mal ein
Blick in das, was IETF da angeblich verzapfen will... ;-) Bye
Carsten Krueger
>Ich habe vor einigen Tagen gelesen, dass man das SPAM-Problem mit
>sogenannten RMX-Einträgen im DNS lösen will.
Ich denke, daß ist eine sinnvolle Idee.
Es werden keine großen Änderungen benötigt und Mails von Dial-Ins sind
sowieso fast überall geblockt.
Wenn man auf 'Reisen' muss man halt via VPN zu seinem Heimatmailserver
verbinden.
Auf jeden Fall ist die Idee viel besser als mit irgendwelchen
Zertifikaten.
Gruß Carsten
--
http://learn.to/quote - richtig zitieren
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://oe-faq.de/ - http://www.oe-tools.de.vu/ - OE im Usenet
http://www.spamgourmet.com/ - Emailadresse(n) gegen Spam
Ralf Döblitz
[...]
> Als Problem wurde dargestellt, das man keine Mails mehr über einen
> eigenen, via Dial-in angeschlossenen, SMTP-Server verschicken kann. Das
> interessiert mich momentan nicht so unbedingt, wird es aber evtl.
> irgendwann mal.
Das trifft aber nicht ganz zu. Man kann auch RMX-RRs für exakte
Mailadressen angeben, also z.B. den versand für example.com auf einen
bestimmten Server beschränken, für roadw...@example.com aber wieder
für andere Server freigeben, im Extremfall für 0.0.0.0/0.
> Was haltet ihr vom RMX-Einträgen? Sind die sinnvoll?
Es ist ein IMHO relativ billig implementierbarer Ansatz, der es Spammern
erschweren soll, Absenderangaben zu fälschen. Man kann sie dann entweder
anhand ihrer Domain ermitteln und zur Rechenschaft ziehen oder zuverläs-
sig auf Absender(domains) filtern. Auf MTA-Seite kann man so etwas wohl
bei vielen Systemen relativ leicht ergänzen, auf DNS-Seite wären eigent-
lich neue Nameserver nötig (wegen des neuen RR-Typs) weshalb man in der
Übergangsphase die Daten evtl. auch in TXT-RRs kodieren kann.
> Kann evtl. noch mal jemand genau erklären was die so machen?
Wenn Server X eine Mail mit Absender y...@example.com einliefern will, dann
wird geprüft, ob für die Domain example.com bzw. die Mailadresse
y...@example.com der Server überhaupt berechtigt ist, solche Mails einzu-
liefern. Die Prüfung erfolgt anhand der IP-Adresse des einliefernden
Servers. Die Zuverlässigkeit ist nicht übermäßig groß (IP-Spoofing,
DNS-Spoofing), reicht aber aus, um den Aufwand für Spammer deutlich zu
erhöhen und damit ihr Geschäft evtl. unprofitabel zu machen oder dabei
wenigstens zu helfen.
Falls jemand den Draft noch nicht kennt: draft-danisch-dns-rr-smtp-03.txt
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.
Carsten Krueger
>Kannst Du das irgendwie belegen oder sagst Du das einfach mal so, weil
>es schon alle glauben werden, wenn es nur oft genug behauptet wird?
Ich belege.
Ich kann von T-Online z.B. nicht an Gmx schicken.
>Komischerweise kommen gerade die Mails, die fuer mich wichtig sind, beim
>Empfaenger an und der filter nicht auf Dialups.
?
>Klar!1111
Ja, wo ist das Problem.
>Allerdings sehe ich weniger ein Problem fuer Dialups, denn wer Mails
>direkt versenden will, muss auch einen MTA haben und wenn man das schon
>hat, kann man auch einen RMX fuer seine Absenderdomain einrichten.
Ja, aber nicht ständig den RMX ändern.
Rainer Zocholl
>* Erik Griffin <1f4e5381573d4a9c...@nurfuerspam.de>
>> wrote: Ich habe vor einigen Tagen gelesen, dass man das SPAM-Problem
>> mit sogenannten RMX-Einträgen im DNS lösen will. Dazu will man das
>> DNS-Protokoll entsprechend erweitern. Irgendwie soll das wohl so
>> vonstatten gehen (ich hab das nicht mehr genau in Erinnerung), dass
>> die Domain im From-Header überprüft wird, ob sie im entsprechenden
>> RMX-Eintrag zu finden ist. Falls nicht, wird die Mail nicht
>> verschickt. Als Problem wurde dargestellt, das man keine Mails mehr
>> über einen eigenen, via Dial-in angeschlossenen, SMTP-Server
>> verschicken kann. Das interessiert mich momentan nicht so unbedingt,
>> wird es aber evtl. irgendwann mal.
>Das verstehe ich nicht so recht.
>Beispielsweise ich habe bei dyndns.org eine Domain. Ich setze dort
>(oder lasse setzen) einen MX Record fuer die Domain, die ich dort
>habe. Da koennte ich doch auch einen RMX eintrag setzen.
Das solltest/kannst Du dann tun.
Ein Problem ist natürlich, wenn Du im Absender z.B. gmx.de
verwenden willst und trotzdem direkt auslefern willst.
>Das Problem ist, das koennten dann Spamer auch.
>Der Vorteil ist, jetzt wird es
>a) aufwendig fuer die Spamer
Am DNS rumgebaslet hat Spamford Wallcae damals schon gemacht...
kurze Zeit später gab's die Rule
"if domain von NS=ns*cyberpromo.com then reject"
War unglaublich effektiv! :->
Leider wurde dann begonnen den From zu fälschen
kurze Zeit später gab's die Rule
"if domain von NS=unknown then reject temporary"
Leider wurde dann begonnen im From exitente
Domains zu verwenden, möglich bekannte wie die von AOL.com
die man nicht einfach blocken konnte.
Wozu das geführt hat kann man hier in einem andeeren Thread lesen.
Mit RMX wäre diese -riesen lücke im SMTP Protokol- weitgehend gelöst.
>b) es wird komplizierter, das From zu waehlen
Er kann nur noch eigene Domains verwenden oder
sich in fremde DNS server einhacken...
Beides ist hoch riskant.
>Bei einem offenen Mailout bringt das alles natuerlich nichts, wenn der
>Spamer das zugehoerige From benutzt.
Daszu müsste der Spammer dieses aber erstmal rausbekommen!
Das ist das gleiche Problem wie bei den "halb offenen Relays".
Und hier kannst Du die Froms blocken.
>Das geheimzuhalten waere aber bestenfalls Security by Obscurity.
Jo, es wäre gar nix ;-)
>Ob die Spamer diesen Aufwand treiben werden und wie erfolgreich sie
>dabei sind, dass kann ich allerdings nicht beurteilen.
Es würde ihnen nicht viel bringen.
>> Was haltet ihr vom RMX-Einträgen? Sind die sinnvoll? Kann evtl. noch
>> mal jemand genau erklären was die so machen?
>Das haben ja bereits einige getan.
>Ich bin mir noch nicht sicher, aber auf Anhieb klingt das machbar und
>ohne allzugrossen Aufwand auch umsetzbar.
ACK.
Es klingt SEHR gut!
>Fuer Mailwuermer wird das auch schwieriger. Oder uebersehe ich da was?
Ja, diese müssen natürlich auch die richtigen Domains im FROMs
verwenden. Und da wohl nicht jeder Provider gestatten wird,
das mit seiner Domain von einer dyn-IP aus gemailt werden darf
haben die direkt auslieferen Würmer arge probleme resp. können
sehr leicht zugeordnet werden, da man nicht nur eine IP, sondern
auch eine passende(!) Domain hat.
>Klingt jedenfalls vielversprechender als die Ideen, die hier die
>letzten Wochen diskutiert wurden.
Jo.
War allerdings auch Teil vom wesentlich komplexeren Secure SMTP
von vor 2 Jahren IRC.
Auch ist es wesentlich(!) besser+einfacher als dieser Stuss
mit den Serverzertifakten.
(Wem der Server gehört weiss ich auch so an hand der IP-#.
Das hätte nru Versign eine menge Geld gebracht wen jeder Furz
Mailserver nun ein Zertificat von einer Root-CA haben müsste).
Problematisch ist allerdings wirklich der mail forward
resp. das gewollte relay und der leere from "<>".
Dort muss entweder der envelope FROM geändert werden
und der orginale definiert in den Header gebaut werden..
Oder sich der Server mit seinem "HELO" ausweisen
Also im HELO muss eine gültige Domain stehen.
Mailing listen sind eigentlich kein Problem, da der
"list-owner" eh immer envelope from steht.
Vgl.
http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt
Allerdings hat er auch mit dem folgenden leider recht und ich
frage mal:
Was können wir tun, damit dieser Vorschlag nicht wieder durch
den Druck der Spammer und der kommerziellen Anti-Spammer
in der Schublade verschwindet?
14. General considerations about fighting spam
Is there a concise technical solution against spam? Yes.
Will it be deployed? Certainly not.
Why not? Because of the strong non-technical interests of several
parties against a solution to the problem, as described below.
Since these are non-technical reasons, they might be beyond the
scope of such a draft. But since they are the main problems that
prevent fighting spam, it is unavoidable to address them. This
chapter exists temporarily only and should support the discussion
of solutions. It is not supposed to be included in a later RFC.
14.1. The economical problem
As has been recently illustrated in the initial session of the
IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting,
sending spam is a business with significant revenues.
But a much bigger business is selling Anti-Spam software. This is a
billion dollar market, and it is rapidly growing. Any simple and
effective solution against spam would defeat revenues and drive
several companies into bankrupt, would make consultants jobless.
Therefore, spam is essential for the Anti-Spam business. If there
is no spam, then no Anti-Spam software can be sold, similar to the
Anti-Virus business. There are extremely strong efforts to keep
this market growing. Viruses, Worms, and now spam are just perfect
to keep this market alive: It is not sufficient to just buy a
software. Databases need to be updated continuously, thus making
the cash flow continuously. Have a single, simple, and permanent
solution to the problem and - boom - this billion dollar market is
dead.
That's one of the reasons why people are expected to live with
spam. They have to live with it to make them buy Anti-Spam
software. Content filters are perfect products to keep this market
alive.
Rainer Zocholl
>Hmmm
>Wir reden doch hoffentlich vom Envelope From, oder? Und das sollte bei
>einer Weiterleitung doch entsprechend stimmen, oder?
Noe.
Wenn Du einen .forward machst wird der envelope from nicht geändert.
Was auch sinnvoll ist, geht der bounce ggf. doch dann sofort
an den originalen Absender zurück, da ja der WEiterleiter u.U.
seinen Empfangs account nie liest, dieser also langsam zumüllt
oder die Schreiber das je merken.
>So ist das jedenfalls bei den Mailinglisten, die ich lese und
>so ist das bei Mails, die ich weiterleite.
Wie leitest Du sie weiter?
Uwe Schröder
>
>>Dann würde endgültig keine einzige Mailweiterleitung mehr
>>funktionieren.
>
> Wer relayen will, traegt vielleicht einfach keinen RMX ein.
Falsch... für die FROM-Domain dürfte dann kein RMX eingetragen sein.
Wenn ich für meine Domain einen RMX-Eintrag hätte, könnte ich keine
Mails mehr an Adressen verschicken, die auf "Weiterleitung" geschaltet
sind, weil ich dann darauf bestehe, daß Mails aus meiner Domain nur
direkt von meinem eigenen Smarthost angenommen werden dürfen. Im Prinzip
würde ich mich damit selber Blacklisten.
> Oder benutzt eines von diesen altmodischen Relay-Konstrukten
> in der Mail From Syntax. Oder uebernimmt die Verantwortung
> fuer die Weiterleitung (eigenes Mail From),
Ich glaube nicht, daß GMX wirklich die ganzen Bounces haben möchte, die
durch fehlkonfigurierte Weiterleitungen entstehen können.
usch
Uwe Schröder
> Also, wenn ich mit mutt einen Bounce erzeuge, dann hat der Bounce mein
> envelope From.
Ein Bounce sollte ein leeres Envelope-From haben.
usch
Uwe Schröder
>>b) es wird komplizierter, das From zu waehlen
>
> Er kann nur noch eigene Domains verwenden oder
> sich in fremde DNS server einhacken...
Oder kompromittierte Rechner als Relays verwenden, die alle über ihr
eigenes OE-Konto mit ihrem eigenen From versenden. SWEN hat es
vorgemacht. Der nächste SWEN könnte neben seiner eigenen Replikation
zusätzlich auch noch massenhaft Spam verschicken.
usch
Uwe Schröder
> Stimmt, aber Swen hat sich vornehmlich ueber die Smartrelays der
> Provider verschickt. Und bei grossen Providern kann man einfach zufalls
> Local Parts nehmen.
Nicht zwangsläufig. GMX prüft z.B., ob das Envelope-From zum SMTP-AUTH
paßt, da gehen nur die tatsächlichen Adressen des betreffenden Accounts
durch.
usch
Petr Koval
[..]
> Falls jemand den Draft noch nicht kennt:
> draft-danisch-dns-rr-smtp-03.txt
Es lässt tatsächlich einige der vielen Problemen des Standard Mail
Systems. Dernächste Schritt könnte ich etwa in gegenseitigen
Zertifizierungen auf basis private/public keys passieren. Es wird
allerding das hauptsächliches Problem nicht lösen. Und das ist nicht im
Bereich der Domains (Hostnamen)sondern allein im Bereich der IP
Bereiche. Bei einer einseitigen Senden/Empfangen Verbindung würde man
gerade noch Manipulationen durchführen können, wie etwa das Fälschen der
eigenen IP, aber nicht bei einer Beidseitigen Verbindung, bei der sich
beide (Sender, Empfänger) Partner gegenseitig adressieren müssen, damit
die Kommunikation funkzioniert. Nur am Niveau der IP Adressierung ist
also etwaswirksames machbar.
Aber.
Das Problem ist eine Unterschiedung zwischen nicht misbrauchten und
misbrauchten IP Bereichen. Und da bleiben wir stecken miten drin im
Problem, bei dem keiner mehr mitmachen will. Die Gründe sind dazu schon
lange bekannt. Man will sich vernetzen, man will an dem Netz der Netze
teilnehmen. Man will sich mit jedem vernetzen egal ob er das Netz
einigermassen sinnvoll nutzt oder misbraucht. Es was nur in Netzen wie
fidonet nicht so leicht und nicht auf dauer einfach ein Missbraucher zu
werden. Im Internet ist es eben anders.
Petr
Carsten Krueger
>Oder ist GMX fuer dich jetzt schon "fast überall"?
T-Online nimmt z.B. von seinen Dialups nichts an.
Hab ich gerade nochmal getestet, die Verbindung wird ewig und 3 Jahre
offen gehalten und dann mit Invalid recipient beendet.
Und wenn du Google bemühst findest immer wieder Fälle wo Mails von
DialUps nicht angenommen werden.
>Und davon abgesehen: Leute, ueberprueft, was ihr da behauptet
Es war bis vor ein paar Wochen der Fall!
Zur Zeit ist es nicht der Fall zumindest nicht mit meiner IP als
Absender.
>Den kann man, wenn der DNS Betreiber das ebenso anbietet wie er es mit
>dem MX macht, ebenso aendern.
Jau, aber das geht nur mit "DynDNS" und nicht bei der Domain die
gerade bei Strato liegt ...
>Also Leute, wenn euch Mail nicht gefaellt, dann benutzt es nicht, aber
>erzaehlt nicht so einen Kram und versucht nicht, die Situation durch
>falsche Massnahmen auch noch zu verschlimmern.
?
Carsten Krueger
>Das trifft aber nicht ganz zu. Man kann auch RMX-RRs für exakte
>Mailadressen angeben, also z.B. den versand für example.com auf einen
>bestimmten Server beschränken, für roadw...@example.com aber wieder
>für andere Server freigeben, im Extremfall für 0.0.0.0/0.
Das währe beknackt, Roadwarriror können Tunnel ins Heimnetz nutzen.
RMX sollte man auf 255.255.255.0 beschränken.
gruß Carsten
Nils Bronstert
> Es ist ein IMHO relativ billig implementierbarer Ansatz, der es Spammern
> erschweren soll, Absenderangaben zu fälschen. Man kann sie dann entweder
> anhand ihrer Domain ermitteln und zur Rechenschaft ziehen oder zuverläs-
> sig auf Absender(domains) filtern. Auf MTA-Seite kann man so etwas wohl
> bei vielen Systemen relativ leicht ergänzen, auf DNS-Seite wären eigent-
> lich neue Nameserver nötig (wegen des neuen RR-Typs) weshalb man in der
> Übergangsphase die Daten evtl. auch in TXT-RRs kodieren kann.
Wobei eine Änderung der Nameserver sehr einfach sein dürfte. Es muß ja
nur ein neuer Name aufgenommen werden. Es ist ja nicht so, daß am
Prinzip des Nameservers geändert werden müßte.
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
Er meint die "Bounce"-Funktion von Mutt. Das ist eine Weiterleitung, die
die Mail nicht verändert, sondern sie einfach so wie sie ist
weiterschickt. Nur die Resent-xxx-Header werden eingefügt.
Nils Bronstert
Hatto von Hatzfeld
> (Guido Hennecke) 21.10.03 in /de/admin/net-abuse/mail:
> >bei einer Weiterleitung doch entsprechend stimmen, oder?
>
> Noe.
> Wenn Du einen .forward machst wird der envelope from nicht geändert.
Genau das will der Draft dabei aber auch ändern (siehe dort Nr. 10.3).
Bei vom Empfänger autorisierten Weiterleitungen (z.B. eines 2ary MX) ist
das nicht nötig, wenn der Haupt-MX so konfiguriert ist, dass er Mails
annimmt, die über seinen Ersatz-MX eingeliefert werden.
Das Konzept des Drafts beruht darauf, dem Inhaber derjenigen Domain, die
im Envelope-From (kurz: "From_") genannt ist, die Verantwortung für
diese Mail zu geben. Er drückt mit dem RMX-Eintrag aus, dass er
zustimmt, dass die und die IPs Mails mit seiner Domain im From_
verschicken.
Wenn nun jemand (z.B. eine Mailingliste oder etwa auch ein .forward auf
einem *ix-Mailserver) Mails weiterleitet ("untrusted forwarding"), dann
muss dieser Weiterleiter auch die Verantwortung übernehmen, d.h. im
From_ (aber nicht im From:) eine Adresse mit der eigenen Domain
eintragen (z.B. den Mailinglistenverwalter), wenn er will, dass ein
fremder RMX-sensibler smtp-Server die Mail annimmt. Ich denke, er hat
Recht damit. Denn erstens würde alles andere das Prinzip durchbrechen,
und Spammer könnten Weiterleitungen fingieren. Und zweitens ist in dem
Moment, wo eine Weiterleitung in Aktion tritt, die Mail ja bereits (als
berechtigt) angenommen worden, und die Verantwortung für die korrekte
Konfiguration liegt dort, wo die Weiterleitung eingerichtet ist (falls
sie z.B. an eine nichtexistente fremde Adresse geht, muss das Problem
beim Weiterleiter gelöst werden, nicht beim Absender der Mail).
Der Draft-Autor sagt, dass in diesem Fall (und eigentlich am besten
immer) der Mailserver, der den From_ ändert, die vorige Adresse in seine
Received-Zeile schreiben sollte (so wie das jetzt schon meist mit der
Empfängeradresse geschieht), so dass sie auch im Nachhinein noch
ausgewertet werden kann.
Ich jedenfalls halte den Draft für in sich sehr schlüssig. Natürlich hat
er den Nachteil, dass man nicht mehr mit einer nicht zur IP passenden
Domain im From_ Mails verschicken kann; aber gerade durch diese
Möglichkeit können Spammer ja ihr Unwesen treiben, sobald sie eine IP in
den Fingern haben, und nur dadurch werden Leute hier bis zum DDOS mit
falschen Bounces zugeschüttet.
Gruß,
Hatto
--
E-Mails sind offen wie Postkarten. Aber nicht mehr mit PGP!
E-Mail-Verschlüsselung leicht gemacht: http://www.gnupp.de/
Mein PGP-Schlüssel 0x2504EF40 auf den Keyservern, z.B. über
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x2504EF40
Carsten Krueger
>Das sieht hier aber ganz anders aus.
dafür kann ich nichts.
>Ja, wenn Du Google bemuehst, finden sich auch immer wieder Faelle wo
>Mails von T-Online, GMX oder AOL nicht angenommen werden.
Ja, wenn die gerade in irgendeiner beknackten Blacklist stehen.
Fakt ist aber das GMX geraume Zeit keine Mails die über
T-Online-Dialin-IPs versendet wurden angenommen hat.
Es sind doch vor ein paar Wochen ein paar RBLs vom Netz gegangen,
standen die da drin?
>Du hingegen hast behauptet "fast überall" und das stimmt nunmal nicht.
Wenn du aus dem T-Online-Netz oder AOL etc. kommst schon.
Ich musste mich immer über meine Uni einwählen um via eigenem
Mailserver versenden zu können.
>Nein, war es nicht.
Dann muss ich mir das wohl einfach nur ganz fest eingebildet haben,
daß die Mails nicht zustellbar waren.
Übrigens sind die IPs bei T-Online sehr unterschiedlich (Reseller,
DSL, ISDN/Analog)
>Wenn ich fuer _meine_ Domain nicht die Records setzen kann, die ich
>brauche, dann gehe ich zu einem anderen Anbieter.
Du kannst sie bestimmt nicht ständig von unterwegs umsetzen, außer bei
nem Dyndnsanbieter.
>Da fragst Du noch?
Was ist genau dein Argument gegen RMX?
Carsten Krueger
>> RMX sollte man auf 255.255.255.0 beschränken.
>
>Auch wenn der Besitzer einer Domain ein /8 fuer seine Clients hat?
Brauch er wohl kaum dort überall Mailserver.
Vielleicht hab ich das Prinzip bisher auch nur mißverstanden.
Ich hab ne Domain example.com, 10 Mailserver auf den IPs x.y.z.20-30.
Ich trage also x.y.z.20-30 in den RMX ein und wenn ich die Mail von
einem der Server verschicke wird vom empfangenden Server example.com
aufgelöst und geschaut ob dies einer meiner Mailserver ist.
Wer hat den mehr als 255 Mailserver auf der gleichen Domain?
Von mir aus könnte man das auch so machen, daß man 10 verschiedene
Subnets angeben darf (soll und muss ja nicht immer im selben sein),
aber 0.0.0.0 zu erlauben wäre hirnrissig.
Gruß Carsten
Hatto von Hatzfeld
> Ein groesseres Problem sehe ich darin, dass Software geaendert werden
> muss. Jemand anders hier im Thread schlug berteits vor, TXT Records zu
> verwenden statt einen neuen Record Type einzufuehren. Damit muessten
> nur fuer Mailouts weitere TXT Records erstellt werden. Die Software
> muesste nicht geaendert werden.
Der Vorschlag ist im Draft schon berücksichtigt (Nr. 7.1).
> Make it so!
Auch meine Meinung.
Ciao,
Hatto
--
Treffen sich zwei Geraden. Sagt die eine:
"Beim nächsten Mal gibst du einen aus!"
Hatto von Hatzfeld
> * Erik Griffin <1f4e5381573d4a9c...@nurfuerspam.de> schrieb in...:
>
> > Was haltet ihr vom RMX-Einträgen? Sind die sinnvoll? Kann evtl. noch
> > mal jemand genau erklären was die so machen?
>
> sämtliche Adressen zuläßt.
> (sigh!) Latürlich würde ich das nicht tun aber irgendjemand wird das
> oder etwas antsprechendes tun.
Es wird dann natürlich Domain-Blacklists geben. Und diese Domain steht
dann bald darin. Und wenn dieser jemand weiterhin so Domains anbietet,
dann wird er bald keine mehr anbieten können, die nicht sofort auf der
Blacklist stehen.
> Außerdem sehe ich persönlich nicht ein, warum ich meine Mails nicht
> direkt zustellen können soll.
Das geht auch dann, wenn dieser Draft zu einem umgesetzten RfC geworden
ist. Nur muss die IP eben durch Deine Domain freigeschaltet sein.
Wenn Du diese Voraussetzung nicht akzeptieren willst, sondern jedem die
Möglichkeit lassen willst, mit beliebiger Adresse Mails zu verschicken,
dann hat eben auch jeder Spammer die Möglichkeit, mit beliebiger
(falscher) Adresse Mails zu verschicken.
> Ich fände es bedenklich und würde mich bevormundet fühlen.
Wie bei allem, gibt es hier mehrere Seiten. Ich fühle mich bevormundet,
wenn mir ein paar Tausend Mails im Monat von Leuten aufgedrängt werden,
die falsche Absender angeben und es mir damit sehr schwer machen, ihre
unerwünschten Mitteilungen zu ignorieren.
Wenn dagegen jemand sagt, er möchte nur Mails von Leuten haben, die auch
zur Verwendung des (From_-)Absenders berechtigt sind, dann finde ich
diese Forderung fair. Schließlich will ich ihm ja etwas mitteilen. Der
Danisch-Draft würde, umgesetzt, ihm die Möglichkeit geben, und ich würde
sie auch für mich (meinen Mailserver) nutzen.
Hier ein Zitat dazu aus dem Draft (Abschnitt 14.2):
| But as I saw from the comments on the first version of this draft,
| people religiously insist on sending e-mail with their domain from
| any computer with any IP address in the world, e.g. when visiting a
| friend using her computer. It appears to be impossible to convince
| people that stopping mail forgery requires every one of them to
| give up forging.
Quelle:
http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt
http://www.danisch.de/work/security/txt/draft-danisch-dns-rr-smtp-03.txt
Was mich jetzt (bei nachträglicher Lektüre) allerdings überrascht hat,
ist die Heftigkeit und die Unsachlichkeit, mit der Einige in nanae im
Mai der ersten Version dieses Drafts begegneten. Lesen die Leute
eigentlich die Sachen erst durch, bevor sie sie als "faschistisches"
Zeug verwerfen? (http://groups.google.de/groups?th=552f52d90c3c72bd)
Ciao,
Hatto
--
Ist ein Server schon durch Spammen aufgefallen?
Einfach zu prüfen auf: http://openrbl.org/ oder direkt
mit IP: http://openrbl.org/lookup.php?i=XXX.XXX.XXX.XXX
Siehe auch http://www.salesianer.de/util/rblcheck.html
Hatto von Hatzfeld
> * Guido Hennecke <0d-10...@usenet.kicks-ass.org> schrieb in...:
>
> > [...]
> > Prima, auf die DOmain kann man ja prima filtern.
> >
> > Und man koennte auch auf Domains filtern, deren RMX 0/0 lautet.
>
> Du siehst offenbar das hüpfende Komma nicht: Wozu dann überhaupt der
> ganze Sermon mit den RMX-RR, wenn wir doch eh wieder zum Filtern
> übergehen? Im günstige Fall wäre der RMX-RR also nur ein etwas
> besserer Filter-Anker.
Ich denke, die Erschwernis, die es dem Spammer bedeutet, eine Domain mit
passendem RMX einzurichten und dabei keine Spuren seiner Identität zu
hinterlassen, wird den Spam deutlich senken. Und das, was dann noch an
Spammern bleibt, kann man dann immer noch filtern, und zwar deutlich
leichter.
> Diejenigen, die trotz dynamischer Einwahl direkt zustellen und meist
> auch etwas mehr Ahnung haben, sind dann mal wieder die
> gelackmeierten...
Ja. Bin ich auch. Aber ich habe schon vor einem Jahr auf den Smart Host
umgestellt, weil mir zuviele Mails per Dialup-Lists blockiert wurden.
> womit ich keinen direkten Anlieferungsnachweis für den MXer des
> Adressaten habe
Ein "set dsn_notify='failure,success'" in meinem mutt gibt mir diesen
Nachweis.
Natürlich bringt das Verfahren mit dem RMX Unannehmlichkeiten mit sich.
Aber es (oder ein anderes Verfahren ähnlicher Wirkung) nicht anzuwenden,
ist noch schlechter.
Ciao,
Hatto
--
"Ein Narr sagt, was er weiß; ein Weiser weiß, was er sagt."
(Jüdisches Sprichwort)
Rainer Zocholl
>Rainer Zocholl wrote:
Klar. Den RMX-Vorschlag sähe ich garnicht mal so sehr primär
"gegen spam" sondern als erste(!) ernsthafte Möglichlichkeit, sein
Eigentum, die Domaine, vor Missbrauch zu schützen.
Derzeit ist da ja nix und jedem Laie fällt die Nase aus dem
Gesicht wenn man ihn per telnet demonstriert wie leicht
man eine eMail von George Bush als Georg...@whitehouse.gov
-nicht nur inhaltlich- plausibel fälschen kann.
Das der Domain missbrauch durch Spammer so unterbunden wird
ist m.E. nur ein (sehr erwünschter) Nebeneffekt.
Auch alle anderen Arten von Fakes werdern sehr erschwert.
Derzeit hat man NICHTS das verhindert das ein Fremder die eigene
Domain missbraucht. Wie soll man klagen?
Rainer Zocholl
>* Rainer Zocholl <UseNet-Posting...@zocki.toppoint.de>
>> Wenn Du einen .forward machst wird der envelope from nicht geändert.
>> Was auch sinnvoll ist, geht der bounce ggf. doch dann sofort
>> an den originalen Absender zurück, da ja der WEiterleiter u.U.
>> seinen Empfangs account nie liest, dieser also langsam zumüllt
>> oder die Schreiber das je merken.
>Wieso sollte ich eine Mail ueber einen Account an einen dich
>weiterleiten, wenn ich diesen Account garnicht lese?
An Dich selbst.(s.u.)
Haben wir beide eine unterschiedliche Definition von "forward"?
Es sieht so aus.
Ich meine nicht: Du liest auf der Mailingliste einen
Interessanten artikel und willst diesen an mich weiterleiten.
Da steht dann natürlich Dein Name im enevelope.
>Irgendwie verstehe ich den Sinn gerade nicht.
Wir haben viele User die ungerne mit "t.online" "uni-kiel"
oder so mailen wollen (u.a. weil kein procmail.). So mailen sie lieber
mit "toppoint" und leiten ihre darauf empfangenen eMails weiter,
um sie irgendwo anders zu lesen. Nebenbei filtern sie sie
teilweise mit procmail nach.
>>>So ist das jedenfalls bei den Mailinglisten, die ich lese und
>>>so ist das bei Mails, die ich weiterleite.
>> Wie leitest Du sie weiter?
>Also, wenn ich mit mutt einen Bounce erzeuge, dann hat der Bounce mein
>envelope From. Bei einem Forward sowieso. Mit Procmail mache ich das
>ebenfalls so.
Hm, das dann eine Konfigurationssache zu sein?
Wäre dem so, hätten wir nicht immer wieder ärger, weil einige
Leute die Weiterleitung völlig vergessen haben und den
Spam dann (ohne in den Header zu schauen) an spamcop verfüttern...
Bodo Eggert
> Wenn nun jemand (z.B. eine Mailingliste oder etwa auch ein .forward auf
> einem *ix-Mailserver) Mails weiterleitet ("untrusted forwarding"), dann
> muss dieser Weiterleiter auch die Verantwortung übernehmen, d.h. im
> From_ (aber nicht im From:) eine Adresse mit der eigenen Domain
> eintragen (z.B. den Mailinglistenverwalter), wenn er will, dass ein
> fremder RMX-sensibler smtp-Server die Mail annimmt.
Nehmen wir an, es existiere ein .forward von b...@example.com auf
f...@example.org. Die Mailbox f...@example.org sei voll. An wen geht die
Fehlermeldung jetzt? Richtig, über b...@example.com an f...@example.org.
Auf dem Weg dorthin wird das Envelope-From auf b...@example.com gesetzt,
so daß die Fehlermeldung über die Fehlermeldung (die garnicht erzeugt werden
sollte) über b...@example.com an f...@example.org zugestellt wird. ...
Letztendlich führt dies zu einem stillen Verlust von Emails.
--
Keep your hands off strong drink. It can make you shoot at the tax collector
and miss.
-- R.A. Heinlein
Friß, Spammer: or...@comms4.com newsl...@argentinianexplorer.com
Hatto von Hatzfeld
> Hatto von Hatzfeld <ha...@salesianer.de> wrote:
>
> > Wenn nun jemand (z.B. eine Mailingliste oder etwa auch ein .forward auf
> > einem *ix-Mailserver) Mails weiterleitet ("untrusted forwarding"), dann
> > muss dieser Weiterleiter auch die Verantwortung übernehmen, d.h. im
> > From_ (aber nicht im From:) eine Adresse mit der eigenen Domain
> > eintragen (z.B. den Mailinglistenverwalter), wenn er will, dass ein
> > fremder RMX-sensibler smtp-Server die Mail annimmt.
>
> Nehmen wir an, es existiere ein .forward von b...@example.com auf
> f...@example.org. Die Mailbox f...@example.org sei voll. An wen geht die
> Fehlermeldung jetzt? Richtig, über b...@example.com an f...@example.org.
> Auf dem Weg dorthin wird das Envelope-From auf b...@example.com gesetzt,
> so daß die Fehlermeldung über die Fehlermeldung (die garnicht erzeugt werden
> sollte) über b...@example.com an f...@example.org zugestellt wird. ...
Das ist sicher ein Problem. Mögliche Lösung: Beim Wechsel des From_ wird
der Return-Path (falls noch nicht vorhanden) auf den Wert des vorigen
From_ gesetzt. Wenn nun der Server, an den weitergeleitet wird, die Mail
annimmt, dann aber einen Bounce zurückschickt, dann sollte der ja direkt
an die im Return-Path angegebene Adresse gehen (dafür ist diese ja da).
Und damit ist sie an der richtigen Stelle.
Weiß hier jemand, ob normale MTAs das auch so machen? (Wohlgemerkt: Ich
spreche von einer nach _Annahme_ der Mail erstellten Fehlermeldung.)
Gruß,
Hatto
--
"IcH fInDe AuCh, dAsS eS nIcHt So WiChTig IsT, eInEn TeXt In KoRrEcKtEr
gRoSs- Und KlEiNsChReIbUnG zU vErFaSsEn, Da DiEs DeR LeSbArKeIt KaUm
AbBrUcH tUt UnD zUdEm AuSdRuCk MeInEr InDiViDuAlItAeT iSt."
[Joachim Kromm in dsnu]
Uwe Schröder
>>Ein Bounce sollte ein leeres Envelope-From haben.
>
> Aber wohl kaum, wenn der MUA des Users es erzeugt.
Wie definierst du dann "Bounce"?
usch
Ralf Döblitz
> Ralf Döblitz <doeb...@doeblitz.net> wrote:
>
>>Das trifft aber nicht ganz zu. Man kann auch RMX-RRs für exakte
>>Mailadressen angeben, also z.B. den versand für example.com auf einen
>>bestimmten Server beschränken, für roadw...@example.com aber wieder
>>für andere Server freigeben, im Extremfall für 0.0.0.0/0.
>
> Das währe beknackt, Roadwarriror können Tunnel ins Heimnetz nutzen.
> RMX sollte man auf 255.255.255.0 beschränken.
Eine Adresse mit obiger Maske (0.0.0.0/0) wäre IMHO wie eine adresse zu
behandeln, für die RMX nicht existiert. Und das bedeutet nach weiter
Verbrietung des Systems, daß man sie als potentiellen Spam behandeln
würde.
Mir persönlich reicht ja bereits SMTP AUTH bzw. TLS mit Client-Zertifi-
kat für den Roadwarrior-Einsatz aus, da würden solche Probleme nicht
entstehen.
Ralf Döblitz
> Guido Hennecke <0d-10...@usenet.kicks-ass.org> wrote:
>
>>> RMX sollte man auf 255.255.255.0 beschränken.
>>
>>Auch wenn der Besitzer einer Domain ein /8 fuer seine Clients hat?
>
> Brauch er wohl kaum dort überall Mailserver.
Doch, gerade dann will man das haben. In so einer Situation will man das
Netz vernünftig segmentieren können (z.B. nach Firmenstandorten) und für
jedes Segment einen Mailserver, der auch dann noch funktioniert (und
damit für die lokalen Clients erreichbar ist), wenn die Anbindung zum
Rest des Firmennetzes abreißt.
Aber IMNSHO sollte es kein Problem darstellen, diese Server dann auch
einzeln (bzw. in kleinen Subnetzblöcken) einzutragen.
Ralf Döblitz
[...]
> Fände ich geil. Dann würde ich den Spammern eine Domain anbieten, die
> sämtliche Adressen zuläßt.
> (sigh!) Latürlich würde ich das nicht tun aber irgendjemand wird das
> oder etwas antsprechendes tun.
Na und? Dann filtert man eben diese Domain aus, andere Domains kann der
Spammer ja trotzdem nicht erfolgreich faken. Das ist doch der Vorteil:
du kannst dann ziemlich zuverlässig auf Absenderadressen bzw. -domains
filtern.
> Außerdem sehe ich persönlich nicht ein, warum ich meine Mails nicht
> direkt zustellen können soll. Damit habe ich etwas fast so gutes wie
> eine Empfangsbestätigung, was man ja durchaus hin und wieder braucht.
Kannst du doch. Einfach deinen Rechner für deine Mailadresse mit RMX-RR
im DNS verewigen (kann ja auch per dynamic update geschehen) und schon
geht das. Die Prüfung erfolgt ja direkt bei der Einlieferung, während du
also online und der DNS-Eintrag gültig ist.
IIRC steht dieses Szenarion auch im Draft drin.
Hatto von Hatzfeld
> * Henning Hucke <h_hucke+...@remove.aeon.icebear.org> wrote:
> >> > Außerdem sehe ich persönlich nicht ein, warum ich meine Mails nicht
> >> > direkt zustellen können soll.
> > Kann ich nicht. Ich habe zwar eine eigene Domain aber keine feste IP.
>
> Denn aenderst Du den RMX Eintrag fuer deine Domain auf deine IP und
> schon kannst Du senden.
Könnte höchstens wegen DNS-Caches Probleme geben, oder? Bei dynamischen
IPs brauchte man schon eine sehr geringe Gültigkeitsdauer ge-cache-ter
Einträge. (Aber um das zu sagen, kenne ich DNS zu wenig.)
> Oder Du sendest ueber ein Relay deiner Wahl, auf deren IP Du deinen
> RMX setzt.
Das geht dem Draft nach auf jeden Fall.
> Ich muss mir mal den Draft genau durchlesen, wie der MX denn genau
> aufgebaut sein soll, vielleicht kann man ja nicht nur eine IP, sondern
> auch einen FQDN angeben.
Auch das geht (siehe Nr. 5.4).
> > Diejenigen, die trotz dynamischer Einwahl direkt zustellen und meist
> > auch etwas mehr Ahnung haben, sind dann mal wieder die
> > gelackmeierten...
>
> So wie ich es bisher verstanden habe, muesste ich nur (vorrausgesetzt
> dyndns.org wuerde die Moeglichkeit bieten), den RMX zusatezlich zu den
> anderen Parametern setzen, wenn ich mich neu einwaehle.
Exakt.
Ciao,
Hatto
--
WWW-Links auf Usenet-Postings? Ganz einfach:
http://groups.google.com/groups?selm=XXXXXXX
und statt "XXXXXXX" die Msg-ID ohne Klammern
Die Msg-ID steht in den Kopfzeilen/Quelltext
Uwe Schröder
> Denn aenderst Du den RMX Eintrag fuer deine Domain auf deine IP und
> schon kannst Du senden.
Bei _meiner_ Domain schön und gut.
Ich habe aber noch eine alte Compuserve-Adresse, die ich gelegentlich
für "offizielle" Mails benutze. Einen eigenen RMX-Eintrag auf ihrem DNS
wird mich Compuserve wohl nicht vornehmen lassen :) - weder auf meine
eigene aktuelle IP, noch auf den Smarthost meines ISPs. Also wäre ich
wohl dazu verdonnert, über smtp.compuserve.com zu versenden. Der aber
akzeptiert nur Mails, wenn man über das Compuserve-Netzwerk eingewählt
ist - was ich als DSL-Benutzer mangels Modem gar nicht mehr kann.
Wo darf ich in so einem Fall meine Mails abkippen?
usch
Rainer Zocholl
>* Henning Hucke <h_hucke+...@remove.aeon.icebear.org> wrote:
>> Damit habe ich etwas fast so gutes wie eine Empfangsbestätigung, was
>> man ja durchaus hin und wieder braucht. Alternativ könnten die
>> Provider auf die Zuteilung von festen IP-Adressen umstellen.
>Mit IPv4 wird das nichts mehr werden. Jedenfalls nicht im grossen
>Stil.
Emm, wenn man sich IPv4 anschaut wären da noch genug Löcher.
Nur, natürlich, wollen die Dial-Up Provider das nicht!
Dann könnte ja jeder Kunde ganz einfach "seinen" Server
fest ins Netz stellen. (Das das dank dyn-dns eh obsolete ist haben
diese Provider noch nicht realisiert).
Also: Ich vermute mal, das auch bei IPv6 der "normal Verbrucher"
weiterhin dynamische IPs bekommt, da man nru so die festen teurer
Verkaufen kann.
Rainer Zocholl
>* Carsten Krueger <usenet22.e...@neverbox.com> wrote:
>> Guido Hennecke <0d-10...@usenet.kicks-ass.org> wrote:
>>>> RMX sollte man auf 255.255.255.0 beschränken.
>>>Auch wenn der Besitzer einer Domain ein /8 fuer seine Clients hat?
>> Brauch er wohl kaum dort überall Mailserver.
>Hast Du eine Ahnung, wieviele Webserver in so einem Rechenzentrum
>stehen koennen, die alle Mails verschicken wollen?
Emm, aber jeder dieser guten Kunden hat eine eigne Domain...
>Nein, das machen nicht alle ueber ein zentrales Relay.
Es sei denn, sie benutzen doch die Domain des Providers.
>Ist auch besser fuer die guten Kunden, wenn sie ihre Mails auch noch
>los werden, obwohl zwei schwarze Schafe beim selben Provider sind.
Jo.
>In den meisten faellen wird ein /24 schon mehr als grosszuegig fuer
>den RMX sein, aber pauschal zu behaupten, man braeuchte nicht mehr,
>das ist eben Unsinn.
Klar.
Man kann aber auch einen RechnerNamen definieren der Versenden
darf.
>Ich wuerde es allerdings fuer sinnvoll halten, wenn man den RMX nicht
>nur pro Domain sondern am Besten sogar pro Email Adresse setzen
>koennte (nicht muesste! Koennte!).
Ist möglich IIRC.
Allerdings ist das auch eine "klasse liste" gültiger eMail-Adressen
die Spammer im TO verwenden können un ihern Dreck dorthin zusenden.
>Wenn man schon einen neuen Record
>einfuehrt, ist das wohl kaum ein grosser Unterschied.
Jo.
>So koennte auch jeder Kunde selbst bestimmen, von wo er Mails mit
>seiner Adresse verschicken kann.
Rainer Zocholl
>Oder Du sendest ueber ein Relay deiner Wahl, auf deren IP Du deinen
>RMX setzt. Ich muss mir mal den Draft genau durchlesen, wie der MX
>denn genau aufgebaut sein soll, vielleicht kann man ja nicht nur eine
>IP, sondern auch einen FQDN angeben.
Ja. Das geht auch.
>So wie ich es bisher verstanden habe, muesste ich nur (vorrausgesetzt
>dyndns.org wuerde die Moeglichkeit bieten), den RMX zusatezlich zu den
>anderen Parametern setzen, wenn ich mich neu einwaehle.
ACK. dyndns.org & Co. würden natürlich solche Records erlauben.
>Ich sehe da kein Problem.
Verdammt, ich auch nicht.
Was übersehen wir?
Das kann doch nicht so einfach ein? ;-)
Wie ist das mit pop3?
Was ist mit remixern?
Der einzige Haken ist das envelope rewriting beim forwarding
und die Bounces daraus, die ja "falsch" laufen.
Man müsste die alte(n) envelope addresse(n) besser mit in den
neuen enevlope einbauen, denn ich glaube nicht das es immer
möglich sein wird, das jeder Kunde eigene "trusted" relays
definieren darf.
Carsten Krueger
>>Hast Du eine Ahnung, wieviele Webserver in so einem Rechenzentrum
>>stehen koennen, die alle Mails verschicken wollen?
Was haben Webserver mit Mailservern zu tun?
Und wenn du dir solche Jumboprovider wie Strato anschaust verwenden
die nur relativ wenige IPs vor allem verstehe ich nicht wozu EINE
Domain über mehr als 255 Mailserver Post verschicken können muss.
>>In den meisten faellen wird ein /24 schon mehr als grosszuegig fuer
>>den RMX sein, aber pauschal zu behaupten, man braeuchte nicht mehr,
>>das ist eben Unsinn.
>
>Klar.
Nenne doch mal ein Bsp. wo eine einzelne Domain über sonstwieviele
Mailserver ihre Mails rauspusten muss.
Was spricht gegen 8 oder 16 IPs oder 255er-Adressblöcke (für
Faulheit)?
Vielleicht hab ich nurnoch nicht klar ausgedrückt was ich meine.
>>Ich wuerde es allerdings fuer sinnvoll halten, wenn man den RMX nicht
>>nur pro Domain sondern am Besten sogar pro Email Adresse setzen
>>koennte (nicht muesste! Koennte!).
>
>Ist möglich IIRC.
>Allerdings ist das auch eine "klasse liste" gültiger eMail-Adressen
>die Spammer im TO verwenden können un ihern Dreck dorthin zusenden.
Erstens das und zweitens würden dann die DNS-Server zusammenklappen.
>>Wenn man schon einen neuen Record
>>einfuehrt, ist das wohl kaum ein grosser Unterschied.
Doch. Ein DNS-Server ala GMX oder Hotmail müsste plötzlich Millionen
von Einträgen enthalten.
Carsten Krueger
>Man muss doch nicht von vornherrein vollkommen ohne jeden Grund den
>Bereich einschraenen.
Doch, so daß die Leute garnicht erst aus Schlampigkeit riesen
IP-Blöcke freigeben können.
Bodo Eggert
>> Nehmen wir an, es existiere ein .forward von b...@example.com auf
>> f...@example.org. Die Mailbox f...@example.org sei voll. An wen geht die
>> Fehlermeldung jetzt? Richtig, über b...@example.com an f...@example.org.
>> Auf dem Weg dorthin wird das Envelope-From auf b...@example.com gesetzt,
>> so daß die Fehlermeldung über die Fehlermeldung (die garnicht erzeugt werden
>> sollte) über b...@example.com an f...@example.org zugestellt wird. ...
>
> Das ist sicher ein Problem. Mögliche Lösung: Beim Wechsel des From_ wird
> der Return-Path (falls noch nicht vorhanden) auf den Wert des vorigen
> From_ gesetzt.
Der Return-Path wird von dem zustellenden Server auf das Envelope-From
gesetzt. Theoretisch kann es klappen, den Return-Path zu belassen, aber
das müßte genauer untersucht werden (aber nicht jetzt).
> Weiß hier jemand, ob normale MTAs das auch so machen? (Wohlgemerkt: Ich
> spreche von einer nach _Annahme_ der Mail erstellten Fehlermeldung.)
Aus der Exim-Dokumentation:
return_path_remove
Type: boolean
Default: true
RFC 822 states that the Return-path: header is 'added by the final
transport system that delivers the message to its recipient' (section
4.3.1), which implies that this header should not be present in an
incoming message, where the return path is carried in the envelope. If |
this option is true, any existing Return-path: headers are removed from
messages as they are read. Exim's transports have options for adding
Return-path: headers at the time of delivery. They are normally used only
for final local deliveries.
--
Funny quotes:
18. Mind like a steel trap - rusty and illegal in 37 states.
Friß, Spammer: die__ch...@hotmail.com aristo...@ubid.ymc1.net
Frank Ellermann
>> Ich sehe da kein Problem.
> Verdammt, ich auch nicht.
> Was übersehen wir?
> Das kann doch nicht so einfach ein? ;-)
Das Beispiel Visitenkarte-Domain und damit nicht
zusammenhaengende Dial-Up IP hakt schon, also die
Domain kannst Du nicht im Mail From nehmen bei
direkter Zustellung.
Ausweichen auf DynDNS Host geht auch nur bedingt:
falls die direkte Zustellung klappt oder sofort
scheitert (mit dem DynDNS Host im Mail From), ist
alles klar.
Aber wenn _spaeter_ ein Bounce geschickt werden
soll, und der Direktversender gerade offline ist
oder gar keinen SMTPd hat, sieht es schlecht aus.
Und falls seine zuletzt eingetragene IP gerade
jemand anders gehoert, der einen SMTPd hat, dann
wuerde der Bounce im Wald landen.
IMHO sollen gelegentliche DialUP-User aber ohnehin
die Finger vom Direktversand lassen, das ist auch
jetzt schon so und kein RMX-Problem. Mit einem
MX bei einem Drittanbieter wuerde es klappen, den
Dienst gibt's aber nirgends umsonst (inzwischen
auch von DynDNS selbst angeboten).
Bye, Frank
Carsten Krueger
>> Erstens das und zweitens würden dann die DNS-Server zusammenklappen.
>
>Aehm, warum das denn bitte?
na s.unten.
>> Doch. Ein DNS-Server ala GMX oder Hotmail müsste plötzlich Millionen
>> von Einträgen enthalten.
>
>Und?
Man müsste komplett neue DNS-Server schreiben, man müsste neue
Maschinen haben wo das alles in den RAM passt.
Stefan Froehlich
> >>[...] wenn man den RMX nicht nur pro Domain sondern am Besten sogar
> >>pro Email Adresse setzen koennte (nicht muesste! Koennte!).
> Ein DNS-Server ala GMX oder Hotmail müsste plötzlich Millionen von
> Einträgen enthalten.
Wieso denn? GMX oder Hotmail werden kaum fuer jede Mailadresse andere
Mailserver verwenden wollen, oder?
Servus,
Stefan
--
http://kontaktinser.at/
Die kostenlose oesterreichische Kontaktboerse
Stefan Froehlich
> Ich habe aber noch eine alte Compuserve-Adresse, die ich gelegentlich
> für "offizielle" Mails benutze. Einen eigenen RMX-Eintrag auf ihrem
> DNS wird mich Compuserve wohl nicht vornehmen lassen :)
Ist auch gut so. Und im From: kannst Du Deine Compuserve-Adresse ja
weiterhin ungestraft angeben, lediglich im Envelope sollte sie nicht
auftauchen - IMHO durchaus zurecht.
Carsten Krueger
>On Thu, 23 Oct 2003 00:03:21 +0200 Carsten Krueger wrote:
>> >>[...] wenn man den RMX nicht nur pro Domain sondern am Besten sogar
>> >>pro Email Adresse setzen koennte (nicht muesste! Koennte!).
>
>> Ein DNS-Server ala GMX oder Hotmail müsste plötzlich Millionen von
>> Einträgen enthalten.
>
>Wieso denn? GMX oder Hotmail werden kaum fuer jede Mailadresse andere
>Mailserver verwenden wollen, oder?
Nein, aber es soll für jede Adresse ein Rekord existieren!
Lutz Frommberger
> Bei einem solchen Provider wuerde ich genauso schnell verschwinden wie
> bei einem, der ohne meine Einverstaendnis Mails an mich scannt und
> unterschlaegt oder gar veraendert.
Würdest du auch kündigen?
Ich habe eine dienstliche Mailadresse. Solange ich in meinem Büro
sitze, kann ich darauf zugreifen. Sobald ich aber meinen IP-Bereich
verlasse, ist damit Essig.
Und nun?
gruß,
--
Lutz Frommberger
http://www.aussagekraft.de/
pgp key on request
Hatto von Hatzfeld
> Rainer Zocholl wrote:
>
> >> Ich sehe da kein Problem.
>
> > Verdammt, ich auch nicht.
>
> > Was übersehen wir?
>
> > Das kann doch nicht so einfach ein? ;-)
>
> Das Beispiel Visitenkarte-Domain und damit nicht zusammenhaengende
> Dial-Up IP hakt schon, also die Domain kannst Du nicht im Mail From
> nehmen bei direkter Zustellung.
Da musst Du dann halt doch den Relay des Providers nehmen. Man kann
nicht alles haben: Schutz vor gefälschten Absendern und zugleich über
jede IP mit beliebigem Absender verschicken können.
Im Übrigen möchte ich noch darauf aufmerksam machen, dass man durch die
Festlegung des Envelope-From ja immer noch nicht an eine bestimmte
Angabe im From: gebunden ist (es sei denn, bei t-online :-( ).
Ciao,
Hatto
--
Es gibt drei Arten von Mathematikern:
Die, die bis drei zaehlen koennen, und die, die dies nicht koennen.
Hatto von Hatzfeld
> Es gefaellt mir immer besser.
>
> Gibt es schon MTAs, die sowas unterstuetzen?
Jein. Siehe http://www.danisch.de/software/rmx/
Übrigens ist ein Vorteil des Drafts ja seine Abwärtskompatibilität.
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.
Hatto von Hatzfeld
(zu Vorschlägen, wie man das Problem der vom Danisch-Draft vorgesehenen
Änderung des Envelope-Froms im Fall von Weiterleitungen [und zwar
"untrusted forward"] lösen kann)
> Der Return-Path wird von dem zustellenden Server auf das Envelope-From
> gesetzt. Theoretisch kann es klappen, den Return-Path zu belassen, aber
> das müßte genauer untersucht werden (aber nicht jetzt).
>
> > Weiß hier jemand, ob normale MTAs das auch so machen? (Wohlgemerkt: Ich
> > spreche von einer nach _Annahme_ der Mail erstellten Fehlermeldung.)
>
> Aus der Exim-Dokumentation:
> return_path_remove
>
> Type: boolean
> Default: true
>
> RFC 822 states that the Return-path: header is 'added by the final
> transport system that delivers the message to its recipient'
> (section 4.3.1), which implies that this header should not be
> present in an incoming message, where the return path is carried
> in the envelope. If this option is true, any existing Return-path:
> headers are removed from messages as they are read. Exim's
> transports have options for adding Return-path: headers at the
> time of delivery. They are normally used only for final local
> deliveries.
Das entspricht auch dem, was RfC 2821 in Abschnitt 4.4 sagt. Demnach ist
ein Return-Path eigentlich nur vorgesehen, wenn die Mail sich nicht im
Transportvorgang von SMTP befindet. Bei Auslieferung dürfen etwaig doch
vorhandene Return-Path-Header auch gelöscht werden, während gleichzeitig
dafür zu sorgen ist, dass (mindestens) ein Return-Path-Header da ist.
Ein weiterleitender Mailserver darf sich dagegen nicht ("MUST NOT") um
die etwaig vorhandenen Return-Path-Header kümmern. Ein Gateway von einem
anderen Protokoll zu SMTP soll dagegen Return-Path-Header sogar
entfernen und den Inhalt im Envelope-From verwenden, und zwar entweder
direkt übernehmen (gemeint wohl für den Fall, dass das eine von SMTP
sinnvoll interpretierbare Adresse ist) oder daraus eine funktionierende
Rückkehradresse bauen (Beispiel: i...@p36.f1011.n2443.z2.fidonet.org) und
diese ins Envelope-From setzen.
Zusammenfassend gesagt: Der Return-Path hat nach der SMTP-Übertragung
die Funktion des Envelope-From, nämlich den Weg anzugeben, den
Fehlermeldungen nehmen sollen. Beiden Angaben nun unterschiedliche
Funktionen zuzuweisen, ist daher problematisch. Aber nicht unlösbar,
falls das gewünschte Verhalten (Erhalt eines vorhandenen Return-Path
beim ausliefernden Mailserver) in Standardinstallationen bereits gegeben
ist (das wäre zu prüfen).
Andere Idee:
Wie wäre es, wenn das weiterleitende Relay im SMTP-Dialog (nach RfC 821)
so etwas im Envelope-From angeben würde:
@example.org:urspruenglic...@example.com
Laut RfC 2821 (F.2) müssen aktuelle Server das noch unterstützen, dürfen
aber bei Nutzung der Adresse (hier: im Fall von Bounces) auch direkt die
letztgenannte Adresse anschreiben. Ob es damit nicht doch Probleme gibt,
weiß ich nicht. Mein sendmail übernimmt einfach die hinter dem ":"
angegebene Adresse, was ja unproblematisch ist.
Dann müsste im Draft spezifiert werden, dass bei solchen Angaben die
erste Domain ("example.org") als Grundlage der RMX-Abfrage zu nehmen
ist.
Konsequenz wäre, dass derjenige, der "untrusted forwarding" machen will,
bei Umsetzung dieses Vorschlags seine Software so umstellen müsste, dass
die Domain des Relays im Envelope-From wie oben im Beispiel example.com
eingebaut wird.
Ciao,
Hatto
--
Eine gültige Mailadresse zu verwenden IST eine Regel. Eine ganz normale.
Etwa so verbindlich wie die Regeln des Mensch-ärgere-dich-nicht. Keiner
kann dich zwingen, dich an diese Regeln zu halten. Aber irgendwann will
vielleicht keiner mehr mit dir spielen. [Rudolf Polzer in danam]
Hatto von Hatzfeld
> UseNet-Posting...@zocki.toppoint.de (Rainer Zocholl) wrote:
> >>Ich wuerde es allerdings fuer sinnvoll halten, wenn man den RMX
> >>nicht nur pro Domain sondern am Besten sogar pro Email Adresse
> >>setzen koennte (nicht muesste! Koennte!).
> >
> >Ist möglich IIRC.
> >Allerdings ist das auch eine "klasse liste" gültiger eMail-Adressen
> >die Spammer im TO verwenden können un ihern Dreck dorthin zusenden.
>
> Erstens das und zweitens würden dann die DNS-Server zusammenklappen.
Vorausgesetzt, dass sehr viele Domains das für sehr viele ihrer Adressen
einzeln regeln würden. Das ist aber nicht sehr wahrscheinlich.
> >>Wenn man schon einen neuen Record
> >>einfuehrt, ist das wohl kaum ein grosser Unterschied.
>
> Doch. Ein DNS-Server ala GMX oder Hotmail müsste plötzlich Millionen
> von Einträgen enthalten.
Um das obige zu zitieren: "koennte (nicht muesste! Koennte!)"
Gruß,
Hatto
--
Zwei Dinge scheinen unendlich zu sein: das Universum
und die menschliche Dummheit. Beim Universum bin ich
mir nicht so sicher... (Albert Einstein)
Hatto von Hatzfeld
> Guido Hennecke wrote:
>
> > Denn aenderst Du den RMX Eintrag fuer deine Domain auf deine IP und
> > schon kannst Du senden.
>
> Bei _meiner_ Domain schön und gut.
>
> Ich habe aber noch eine alte Compuserve-Adresse, die ich gelegentlich
> für "offizielle" Mails benutze. Einen eigenen RMX-Eintrag auf ihrem DNS
> wird mich Compuserve wohl nicht vornehmen lassen :) - weder auf meine
> eigene aktuelle IP, noch auf den Smarthost meines ISPs.
Das vermute ich auch :-)
> Also wäre ich wohl dazu verdonnert, über smtp.compuserve.com zu
> versenden.
Ja. Es ist ja der Sinn des Drafts, dass der Domaininhaber es freigeben
soll, wenn jemand mit seiner Domain Mails verschicken darf.
> Der aber akzeptiert nur Mails, wenn man über das Compuserve-Netzwerk
> eingewählt ist - was ich als DSL-Benutzer mangels Modem gar nicht mehr
> kann.
Dann sollte Compuserve SMTP AUTH einführen. Und ich vermute, dass sie
das auch tun werden, falls der Draft zu einem RfC wird und immer mehr
Leute Probleme bekommen und sich beschweren. Oder sie machen es wie
t-online und geben Kunden, die sich nicht über das eigene Netzwerk
einwählen, wenigstens einen Webmail-Zugang :->
Stefan Froehlich
> >> Ein DNS-Server ala GMX oder Hotmail müsste plötzlich Millionen von
> >> Einträgen enthalten.
> >Wieso denn? GMX oder Hotmail werden kaum fuer jede Mailadresse andere
> >Mailserver verwenden wollen, oder?
> Nein, aber es soll für jede Adresse ein Rekord existieren!
Ich lese das jetzt nicht extra noch einmal im Detail nach (also bitte
korrigieren, wenn ich mich irre), aber: es reicht doch jeweils _ein_
Eintrag fuer gmx.{$TLD}, der die eigenen Mailserver (fuer alle Adressen)
freigibt. GMX wird es nicht notwendig haben, fuer einzelne Adressen
individuelle Records zu spezifizieren.
Carsten Krueger
>Ich lese das jetzt nicht extra noch einmal im Detail nach (also bitte
>korrigieren, wenn ich mich irre), aber: es reicht doch jeweils _ein_
>Eintrag fuer gmx.{$TLD}, der die eigenen Mailserver (fuer alle Adressen)
>freigibt. GMX wird es nicht notwendig haben, fuer einzelne Adressen
>individuelle Records zu spezifizieren.
Also zur Zeit muss der GMX-Server z.B. www.gmx.net - www70.gmx.net,
www.gmx.de - www70.gmx.de und nen bisschen Gmxpro-Mail, Topmail und
Fundomains verwalten. Die Daten können schätzungsweise (ich hab keine
Ahnung wie groß ein wirklicher DNS-Rekord ist) keine 100 kb sein.
Wenn du jetzt plötzlich 5 Mio Emailadressen da reintust ist das doch
irgendwie ein Unterschied.
Vielleicht kann ja mal jemand das noch genauer beleuchten. Für ne
"normale" Domain mit 1000 Adressen wird das wohl kein Problem sein.
Sebastian Posner
>>> Doch. Ein DNS-Server ala GMX oder Hotmail müsste plötzlich Millionen
>>> von Einträgen enthalten.
>>Und?
> Man müsste komplett neue DNS-Server schreiben, man müsste neue
> Maschinen haben wo das alles in den RAM passt.
Wie kommst du auf *den* schmalen Ast? Die Nameserver müssen exakt um
einen RR-Typ erweitert werden (wenn man es nicht sogar per TXT-RR löst),
und davon gibt es auch keine Millionen. Im Normalfall 2-3 pro
Absenderdomain, bei großen Domains mit vielen Mailouts entsprechend
mehr. Aber keine Millionen. Ich glaube, du hast da was lahcfs
verstanden. Es muß nicht für jede Mailadresse ein RR eingetragen werden.
Sebastian
--
"Ja der weiße Mann aus Texas / Brät den Teufel heut am Spieß,
Und alle, die ein anderes Lied singen / grillt der Mann im Fegefeuer mit"
Fink feat. Peter Lohmeyer / Bagdad Blues ( Der weiße Mann aus Texas)
Carsten Krueger
>> Doch. Ein DNS-Server ala GMX oder Hotmail müsste plötzlich Millionen
>> von Einträgen enthalten.
>
>Um das obige zu zitieren: "koennte (nicht muesste! Koennte!)"
Ja, aber WENN Hotmail oder AOL die Adressen alle in den DNS packt
währe das ja kritisch für alle Server die die Anfragen cachen.
Carsten Krueger
>Wie kommst du auf *den* schmalen Ast? Die Nameserver müssen exakt um
>einen RR-Typ erweitert werden (wenn man es nicht sogar per TXT-RR löst),
>und davon gibt es auch keine Millionen. Im Normalfall 2-3 pro
>Absenderdomain, bei großen Domains mit vielen Mailouts entsprechend
>mehr. Aber keine Millionen. Ich glaube, du hast da was lahcfs
>verstanden. Es muß nicht für jede Mailadresse ein RR eingetragen werden.
Dann hab ich da wirklich was grob falsch verstanden.
Wie genau soll den gespeichert werden ob die Adresse gültig ist?
In irgendeinem Text-Rekord oder?
Ich hab den Draft zwar gelesen, kenne mich aber nicht wirklich gut
damit aus.
Carsten Krueger
>Ich habe eine dienstliche Mailadresse. Solange ich in meinem Büro
>sitze, kann ich darauf zugreifen. Sobald ich aber meinen IP-Bereich
>verlasse, ist damit Essig.
VPN, SMTP-Auth
Hatto von Hatzfeld
> Guido Hennecke <0d-10...@usenet.kicks-ass.org> wrote:
> > Bei einem solchen Provider wuerde ich genauso schnell verschwinden wie
> > bei einem, der ohne meine Einverstaendnis Mails an mich scannt und
> > unterschlaegt oder gar veraendert.
>
> Würdest du auch kündigen?
>
> Ich habe eine dienstliche Mailadresse. Solange ich in meinem Büro
> sitze, kann ich darauf zugreifen. Sobald ich aber meinen IP-Bereich
> verlasse, ist damit Essig.
>
> Und nun?
Wenn der Arbeitgeber ein Interesse daran hat, dass seine Mitarbeiter
auch von außerhalb des Arbeitsplatzes Mails mit Dienstadresse
verschicken, dann wird er für diese Möglichkeit sorgen (wofür es viele
denkbare Möglichkeiten gibt).
Im Übrigen kannst Du (falls Du nicht z.B. den Standard-Mailserver von
t-online als Relay nutzt) im "From:" der Mail ja auch einen anderen
Eintrag machen als im Envelope-From (geeignete Software natürlich
vorausgesetzt).
Lutz Frommberger
> auch von außerhalb des Arbeitsplatzes Mails mit Dienstadresse
> verschicken, dann wird er für diese Möglichkeit sorgen
Was er nicht tut. Und wenn er es tut: s.u.
> Im Übrigen kannst Du (falls Du nicht z.B. den Standard-Mailserver von
> t-online als Relay nutzt) im "From:" der Mail ja auch einen anderen
> Eintrag machen als im Envelope-From (geeignete Software natürlich
> vorausgesetzt).
Ich mag das vielleicht können. Aber extrem viele Mitarbeiter können
das nicht und werden das auch nach sorgfältiger Schulung nicht
lernen.
Das ist in meinen Augen das Hauptproblem dieses Drafts: Email
versenden wird für technisch weniger versierte Menschen eine
wirkliche Herausforderung. VPN bspw. muss erstmal angeboten
werden - und dann muss es auch clientseitig laufen. Wenn ich
bedenke, wieviel Arbeitszeit ich bereits verschwendet habe,
um ein halbwegs ortunabhängiges Mailsystem auf meinem Notebook
zum Laufen zu bringen, wird mir übel.
Frank Ellermann
> Im Übrigen möchte ich noch darauf aufmerksam machen, dass man
> durch die Festlegung des Envelope-From ja immer noch nicht an
> eine bestimmte Angabe im From: gebunden ist
Jepp (wobei ich ca. zwei Jahre gebraucht habe, um zu kapieren,
was bei Netscape 3.x eigentlich abgeht, wenn ich mit Adresse A
was ins Outbound stelle, und das dann mit einer Konfiguration
fuer Adresse B spaeter verschicke... auhauahauaha ;-)
Also fuer den hier im Thread, der unbedingt direkt zustellen
will mit einer DialUP IP: In den From-Header traegt er seine
Lieblingsadresse ein (Domain vom Webspace o.ae.)
Dein Vorschlag waere, dass er dann im Mail-From (Umschlag) beim
Direktversand die Adresse angibt, die er bei dem ISP hat, ueber
den er gerade eingewaehlt ist. Also z.B. die T-Online-Adresse.
Dann muesste aber T-Online im RMX-Record nicht nur die paar IPs
ihrer mailouts notieren, sondern saemtliche IPs, die an DialUP-
User vergeben werden. Ich tippe mal, dass sie da mauern (oder
es als tolle neue kostenpflichtige Zusatzleistung anbieten ;-)
> (es sei denn, bei t-online :-( ).
Sigh... bye, Frank
--
<URL:http://purl.net/xyzzy/t-online.htm>
<URL:http://purl.net/xyzzy/home/thehun.net/pc77.t-online.htm>
Sebastian Posner
>>Ich lese das jetzt nicht extra noch einmal im Detail nach (also bitte
>>korrigieren, wenn ich mich irre), aber: es reicht doch jeweils _ein_
>>Eintrag fuer gmx.{$TLD}, der die eigenen Mailserver (fuer alle Adressen)
>>freigibt. GMX wird es nicht notwendig haben, fuer einzelne Adressen
>>individuelle Records zu spezifizieren.
> Also zur Zeit muss der GMX-Server z.B. www.gmx.net - www70.gmx.net,
> www.gmx.de - www70.gmx.de und nen bisschen Gmxpro-Mail, Topmail und
> Fundomains verwalten. Die Daten können schätzungsweise (ich hab keine
> Ahnung wie groß ein wirklicher DNS-Rekord ist) keine 100 kb sein.
> Wenn du jetzt plötzlich 5 Mio Emailadressen da reintust ist das doch
> irgendwie ein Unterschied.
Du *tust* da keine 5 Mio Emailadressen rein.
$ORIGIN gmx.de
IN RMX host:www.gmx.de
$GENERATE 1-70 IN RMX host:www$.gmx.de
$ORIGIN gmx.net
IN RMX host:www.gmx.de
$GENERATE 1-70 IN RMX host:www$.gmx.de
Und weitere 3 Zeilen pro Domain. Wo ist da jetzt das Volumenproblem?
Toni Grass
[.....]
> <Provokation>Ich bin meinerseits dafür, dass der Internet-Führerschein
> eingeführt wird und User ohne diesen keinerlei Dienste mehr im Internet
> benutzen dürfen. Alleine dadurch würden neunzig Prozent aller unleserli-
> chen Mails und Postings, verkorkst konfigurierte Mail- und News-Reader,
> Flamewars darüber und sonstiges mehr vermieden</Provokation>
Ach, da wird doch auch nur wieder gezeigt, wie man mit OjE ein X-Post
absetzt und daß man eine ungültige Adresse angeben muß um vor Spam
sicher zu sein. Halt ähnlicher Mist wie der Computerführerschein.
Toni
Sebastian Posner
>>> Doch. Ein DNS-Server ala GMX oder Hotmail müsste plötzlich Millionen
>>> von Einträgen enthalten.
>>Um das obige zu zitieren: "koennte (nicht muesste! Koennte!)"
> Ja, aber WENN Hotmail oder AOL die Adressen alle in den DNS packt
> währe das ja kritisch für alle Server die die Anfragen cachen.
Das würden Hotmail oder AOL aber nicht tun, WEIL dann in der Tat ihre
Server verrecken würden. Außerdem wäre das viel zu viel Aufwand für
nichtzahlendes Kundschaftsvieh.
Sebastian Posner
>>Wie kommst du auf *den* schmalen Ast? Die Nameserver müssen exakt um
>>einen RR-Typ erweitert werden (wenn man es nicht sogar per TXT-RR löst),
>>und davon gibt es auch keine Millionen. Im Normalfall 2-3 pro
>>Absenderdomain, bei großen Domains mit vielen Mailouts entsprechend
>>mehr. Aber keine Millionen. Ich glaube, du hast da was lahcfs
>>verstanden. Es muß nicht für jede Mailadresse ein RR eingetragen werden.
> Dann hab ich da wirklich was grob falsch verstanden.
> Wie genau soll den gespeichert werden ob die Adresse gültig ist?
GAR nicht. Das liegt nicht im Einzugsbereich des Drafts.
> In irgendeinem Text-Rekord oder?
Nein.
> Ich hab den Draft zwar gelesen, kenne mich aber nicht wirklich gut
> damit aus.
Er soll nur bezwecken, daß man verifizieren kann, ob ein Mailserver
berechtigt ist, für eine gewisse Domain Mails zu verschicken.
Nicht mehr, aber auch nicht weniger.
Hatto von Hatzfeld
> Sebastian Posner <spo...@gmx.de> wrote:
>
> >Wie kommst du auf *den* schmalen Ast? Die Nameserver müssen exakt um
> >einen RR-Typ erweitert werden (wenn man es nicht sogar per TXT-RR löst),
> >und davon gibt es auch keine Millionen. Im Normalfall 2-3 pro
> >Absenderdomain, bei großen Domains mit vielen Mailouts entsprechend
> >mehr. Aber keine Millionen. Ich glaube, du hast da was lahcfs
> >verstanden. Es muß nicht für jede Mailadresse ein RR eingetragen werden.
>
> Dann hab ich da wirklich was grob falsch verstanden.
> Wie genau soll den gespeichert werden ob die Adresse gültig ist?
Es wird nicht irgendwo gespeichert, ob eine Adresse gültig ist, sondern
zu jeder Domain, dessen Besitzer sich gegen Missbrauch seiner Domain
schützen will, wird gespeichert, von welchen IPs aus Mails mit dieser
Domain im Absender (genauer: im Envelope-From) verschickt werden dürfen.
Statt IPs können auch Hostnamen angegeben werden, zu denen sich die IPs
rückwärts auflösen lassen. Oder ein Verweis auf den RMX einer anderen
Domain (meist wohl den des Providers, der so nur einen RMX-Eintrag
pflegen muss).
Statt nur einer ganzen Domain können (einem neuerlich ergänzten
Vorschlag zufolge) auch einzelnen Adressen die jeweiligen IPs (oder
Hostnamen) zugeordnet werden.
Es gibt auch die Möglichkeit, erst einen oder mehrere Blöcke von IPs
freizugeben und dann davon einen Teil wieder zu verbieten.
> In irgendeinem Text-Rekord oder?
Eigentlich in einem eigenen RMX-Record. Bei DNS-Servern, die den noch
nicht kennen, alternativ auch im TXT-Record. (Man kann bei einem
DNS-Server jeweils einen bestimmten Typ von Infos abfragen, wie etwa den
MX, also die zuständigen Mailempfangsserver, oder zukünftig eben
vielleicht einen RMX, also die erlaubten Mailversandserver.)
Ciao,
Hatto
--
"Ein Narr sagt, was er weiß; ein Weiser weiß, was er sagt."
(Jüdisches Sprichwort)
Hatto von Hatzfeld
> Stefan...@Froehlich.Priv.at (Stefan Froehlich) wrote:
>
> >Ich lese das jetzt nicht extra noch einmal im Detail nach (also bitte
> >korrigieren, wenn ich mich irre), aber: es reicht doch jeweils _ein_
> >Eintrag fuer gmx.{$TLD}, der die eigenen Mailserver (fuer alle Adressen)
> >freigibt. GMX wird es nicht notwendig haben, fuer einzelne Adressen
> >individuelle Records zu spezifizieren.
>
> Also zur Zeit muss der GMX-Server z.B. www.gmx.net - www70.gmx.net,
> www.gmx.de - www70.gmx.de und nen bisschen Gmxpro-Mail, Topmail und
> Fundomains verwalten. Die Daten können schätzungsweise (ich hab keine
> Ahnung wie groß ein wirklicher DNS-Rekord ist) keine 100 kb sein.
> Wenn du jetzt plötzlich 5 Mio Emailadressen da reintust ist das doch
> irgendwie ein Unterschied.
Der RMX-Eintrag gibt dann einfach nur 213.165.64.20 für alle GMX-Nutzer,
also für gmx.net, gmx.de, gmx.at u.ä., frei. Die liefern ihre abgehenden
Mails dann authentifiziert beim GMX-Server ein und fertig.
Hatto von Hatzfeld
> Hatto von Hatzfeld <ha...@salesianer.de> wrote:
>
> >> Doch. Ein DNS-Server ala GMX oder Hotmail müsste plötzlich
> >> Millionen von Einträgen enthalten.
> >
> >Um das obige zu zitieren: "koennte (nicht muesste! Koennte!)"
>
> Ja, aber WENN Hotmail oder AOL die Adressen alle in den DNS packt
> währe das ja kritisch für alle Server die die Anfragen cachen.
OK; man sollte eine Maximalgröße der Einträge für einzelne Domains
festlegen.
Aber AOL wäre ja auch schön blöd, wenn die alle Nutzer einzeln
aufführen. Es genügt doch, die Domain zu nehmen.
Ciao,
Hatto
--
Join the AAAAA!
What is the AAAAA?
Oh, I thought you'd know that. It's the famous
Anonymous Association Against Acronym Abuse.
Hatto von Hatzfeld
> Das ist in meinen Augen das Hauptproblem dieses Drafts: Email
> versenden wird für technisch weniger versierte Menschen eine
> wirkliche Herausforderung. VPN bspw. muss erstmal angeboten
> werden - und dann muss es auch clientseitig laufen. Wenn ich
> bedenke, wieviel Arbeitszeit ich bereits verschwendet habe,
> um ein halbwegs ortunabhängiges Mailsystem auf meinem Notebook
> zum Laufen zu bringen, wird mir übel.
Es muss ja nicht VPN sein. Es reicht, irgend ein Mailrelay im Netz zu
haben, dessen IP im RMX der Domain angegeben ist und das SMTP AUTH kann.
Die typischen Mailclients wie Outlook und Outlook Express brauchen
sowieso ein Smart Relay. Der einzige Zusatzaufwand ist, das Häkchen bei
"beim Postausgangsserver anmelden" zu machen.
Ciao,
Hatto
--
Treffen sich zwei Geraden. Sagt die eine:
"Beim nächsten Mal gibst du einen aus!"
Hatto von Hatzfeld
> * Ralf Döblitz <doeb...@doeblitz.net> schrieb in de.admin.net-abuse.mail:
> Ich wähle mich bei T-Offline ein. Meine Domain liegt anderswo und der
> DNS läßt sich nicht dynamisch updaten. Und schon haben wir das
> Schlamassel.
Stimmt; mit RMX müsstest Du dann das Direkt-Versenden aufgeben. Ich
finde das inzwischen aber auch in Ordnung. Anders ist dem Missbrauch von
fremden Domains in Absender IMO eben nicht beizukommen.
Dann musst Du halt entweder den Mailserver Deines Domainproviders nutzen
(oder gibt es einen, bei dem das nicht geht?). Oder - wenn Du im großen
Stil oder große Mengen an Mails rausschickst - einen Root-Server im Netz
mieten. Oder eine DSL-Leitung mit fester IP anmieten (die sind auch
nicht mehr so teuer).
Ich sehe jedenfalls nicht mehr ein, dass die Rücksicht auf einige wenige
Leute, die direkt versenden wollen, Spammern Tor und Tür öffnet. Und ich
bringe auch selbst meine "Opfer" - seit einem Jahr habe ich den Direkt-
Versand aufgegeben. Es gab zuviele Bounces wegen Dialup-Blocklisten.
Lutz Frommberger
> Was ist an "Denn aenderst Du den RMX Eintrag fuer deine Domain
> auf deine IP und schon kannst Du senden" eingentlich so
> kompliziert?
Wie schnell propagieren die Nameserver diese Änderung?
Lutz Frommberger
> * Lutz Frommberger <Lutz.Fro...@gmx.de> wrote:
> Die Frage ist wohl eher, wie gross die TTL fuer das entsprechende Zone
> File ist.
Ich weiß leider nicht, was eine TTL ist.
Aber ernsthaft: Kann man sicherstellen, dass die Nameserver eine
Änderung schneller propagieren als die Mail ankommt?
Carsten Krueger
>Er soll nur bezwecken, daß man verifizieren kann, ob ein Mailserver
>berechtigt ist, für eine gewisse Domain Mails zu verschicken.
Es ging doch gerade auch darum auf Wunsch EINZELNE Adressen zu
speichern.
Carsten Krueger
>Nachdem ich den Draft nun gelesen habe, entfaellt das in dieser Version
>ohnehin, da explizit erwaehnt wird, dass lediglich der Domain Part aber
>_nicht_ der Local Part in den RMX Eintrag kommt.
Ich hab den Draft so verstanden, daß explizit der Local Part auch
erlaubt sein KANN.
Wenn das falsch ist, entfällt natürlich alles was ich hier geschrieben
hab.
Carsten Krueger
>Und zwar nur fuer die Adressen, deren Inhaber nicht ueber GMX versenden
>wollen. Fuer den Rest reicht der Domaineintrag mit den Mailouts.
Ah ok, jetzt hab ichs.
Danke, das erklärt alles.
Frank Ellermann
> Ein kostenloser Dyndns Account und diese Domain als
> _envelope_ from und schon kannst Du senden wie ein
> Weltmeister!
Reicht IMHO nur bei Flattratten, die 24/7 online sind, und
etwaige Bounces mit eigenem SMTPd empfangen. Oder alternativ
bei "Spendern" (donator), die ihren Host aktiv als offline
melden koennen. Oder (vermutlich beste Loesung) Leute mit MX
bei einem verlaesslichen System (geht auch bei DynDNS, aber
die zweite und dritte Variante ist nicht mehr kostenlos.
Du kannst natuerlich auch sagen, dass Dich Bounces im Fall von
Diektversand nicht kuemmern und mit einer "manchmal bin ich
online" IP hantieren, das faende ich aber dubios. Bye, Frank
Sebastian Posner
>>Er soll nur bezwecken, daß man verifizieren kann, ob ein Mailserver
>>berechtigt ist, für eine gewisse Domain Mails zu verschicken.
> Es ging doch gerade auch darum auf Wunsch EINZELNE Adressen zu
> speichern.
Wo?
Hatto von Hatzfeld
> Carsten Krueger meinte kundzutun:
>
> >>Er soll nur bezwecken, daß man verifizieren kann, ob ein Mailserver
> >>berechtigt ist, für eine gewisse Domain Mails zu verschicken.
> > Es ging doch gerade auch darum auf Wunsch EINZELNE Adressen zu
> > speichern.
>
> Wo?
Im Draft ist diese Möglichkeit unter 3.3 und 4.2 erwähnt; der Autor
hatte das in den ersten Versionen nicht vorgesehen, in Version 3 aber
auf Wunsch anderer als noch zu diskutierende *Möglichkeit* ergänzt.
Er meint aber auch, dass Administratoren das nur selten in Anspruch
nehmen, sondern sich wohl meist mit Einträgen für die ganze Domain
begnügen würden.
Ciao,
Hatto
--
WWW-Links auf Usenet-Postings? Ganz einfach:
http://groups.google.com/groups?selm=XXXXXXX
und statt "XXXXXXX" die Msg-ID ohne Klammern
Die Msg-ID steht in den Kopfzeilen/Quelltext
Hatto von Hatzfeld
> * [Ingrid] Guido Hennecke <0d-10...@usenet.kicks-ass.org> wrote:
> > Weisst Du, wie gross ein Zonefile mit 2 Millionen Eintraegen ist?
> > Das sind vielleicht 40 MB.
>
> Nachdem ich den Draft nun gelesen habe, entfaellt das in dieser
> Version ohnehin, da explizit erwaehnt wird, dass lediglich der Domain
> Part aber _nicht_ der Local Part in den RMX Eintrag kommt.
Das war in den ersten beiden Versionen des Drafts so. In der aktuellen
Version 3 wird unter 3.3 (und 4.2) zur Diskussion gestellt, auch den
Eintrag einzelner local parts zu ermöglichen. Um es klar zu sagen: Dies
ist dann eine *Möglichkeit*, die ein Administrator hat. Meist wird er
wohl pauschal für die ganze Domain einen Eintrag machen und höchstens
für bestimmte Einzelfälle einen weiteren ergänzen.
Rainer Zocholl
>* Guido Hennecke <0d-10...@usenet.kicks-ass.org> schrieb in...:
>> [...]
>> Vorrausgesetzt es wird auch ueberall so implementiert, dass man als
>> Adressinhaber immer noch selbst bestimmen kann, ueber welche IP
>> Adressen Mails mit diesem Absender verschickt werden duerfen, [...]
>ROTFL 8-D Ja, klar doch! *Natürlich* wird das Marketing entscheiden,
>dass eine nette Web-Seite zur Verfügung gestellt wird, auf der man
>seinen RMX "dynamisch" eintragen kann... Prust :).
Ja, natürlich.
Ich kenne Provider, die haben ein Web interface mit dem
all diese Sachen komplett(!) einstellen kann.
Andere machen das nur per eMail.
Aber da IP-# zu ändern ist Null Problemo.
>Damit treibst Du den Teufel mit dem Belzebub aus!
Wieso?
Welcher Sack wird denn aufgerissen um das Loch "Domänen Missbrauch"
zu stopfen?
Wenn Du eines siehst: Zögere nicht es zu nennen!
>Das ist im übrigen
>genau die selbe Argumentation, die momentan als Begründug für die
>Anti-Terror-Maßnahmen
Absurder Vergleich. Es besteht ein ganz klarer, individueller Bedarf daran
die eigene Domain zu schützen.
Schau doch hier mal wie oft bei "Meine Domain wird missbraucht" oder
"Wir ersaufen in Bounces" die Frage: "Was kann ich tun" gestellt wird
und eigentlich nur "Schulterzucken" und "Aussitzen" als Rat geerntet
werden kann.
>(deren Wirksamkeit vermehrt in Frage gestellt wird;
Die "Anti-Terrormassnahmen" liegen schon seit langer Zeit
in den Schubladen der Geheimdienste und haben NICHTS mit
"Anit-Terror" zu tun!
Teilweise wurde auch schon zurückgerudert.
>was das wohl in Bezug auf Maßnahmen wie RMXer oder ähnliches
>bedeuten mag?
Das frage ich mich auch...
><unschuldig_pfeif/>) verwendet wird: "Was habt ihr gegen
>die Einschränkung eurer Freiheits- und Persönlichkeitsrechte? Wir
>geben euch dafür doch Sicherheit."...
Emm, Du unterliegst doch wohl nicht der oft zulesenden aber
absurden und gefährlichen Auffassung, das Du durch das
Fälschen des Absenders anonym seiest?
Bitte suche nach "anon remailer" "mixer" etc.
Nur mit solchen Systemen bist Du einigermassen anonym!
>> Nur sehe ich das bei RMX nicht so.
>Tcha, das werden viele andere Nicht-Fachleute ebenso sehen.
Die bekommen das gar nicht mit.
>Und da die Mehrheit entscheidet...
Ala Verisign? 80% aller durch sitewinder belästigten fanden
dessen Meldung besser als die -bekanntlich völlig bescheuerte-
Fehlermeldung des IE...
Rainer Zocholl
>Das ist in meinen Augen das Hauptproblem dieses Drafts: Email
>versenden wird für technisch weniger versierte Menschen eine
>wirkliche Herausforderung.
Ach mei. Wir boten lange Zeit "nur" die Möglichkeit
per ssh-Tunnel eMails von fremden IP zu versenden.
Nun haben wir smtp-auth der server heisst smtp-auth und trotzdem
versuchen einige über den server "smtp" zu relayen...
tagelang...
>VPN bspw. muss erstmal angeboten werden -
>und dann muss es auch clientseitig laufen.
Naja, webmail oder ssh tunnel funktionieren ganz pirma.
>Wenn ich bedenke, wieviel Arbeitszeit ich bereits verschwendet habe,
>um ein halbwegs ortunabhängiges Mailsystem auf meinem Notebook
>zum Laufen zu bringen, wird mir übel.
Wenn ich daran denke wieviel Zeit tausende von Admins
damit zugebracht Spam schnellst möglich zu entsorgen,
ohen das ihnen die Myriaden der Bounces die Leitung zuziehen.
Rainer Zocholl
>Lutz Frommberger <Lutz.Fro...@gmx.de> wrote:
>>Ich habe eine dienstliche Mailadresse. Solange ich in meinem Büro
>>sitze, kann ich darauf zugreifen. Sobald ich aber meinen IP-Bereich
>>verlasse, ist damit Essig.
>VPN, SMTP-Auth
"webmail" nicht zu vergessen
"webmail"-robots nicht zu vergessen, die die Daten schon heute
in das Webmailinterface pumpen, weil den Benutzern die 2,95E für
den relay host (berechtigt) zu teuer ist.
Das sind aber solche raren Ausnahmen die so eine
Krücklösung erlaubt. (Erinnere Dich an den smtp-after-pop-Murks
mit dem millionen von Kunden zurecht kommen mussten.)
Rainer Zocholl
>Guido Hennecke <0d-10...@usenet.kicks-ass.org> wrote:
>> * Lutz Frommberger <Lutz.Fro...@gmx.de> wrote:
>> Die Frage ist wohl eher, wie gross die TTL fuer das entsprechende
>> Zone File ist.
>Ich weiß leider nicht, was eine TTL ist.
Emm, sollte man aber.
Das ist so ungefähr als wenn ein Maurer sagt, das er nicht weiss
was ein Zentimeter oder ein rechter Winkel ist...(kommt leider
oft vor das er es nicht weiss, aber nicht zugibt. Maurer ebend ;-))
TTL = Time To Live
Also die "Lebenserwartung"
>Aber ernsthaft: Kann man sicherstellen, dass die Nameserver eine
>Änderung schneller propagieren als die Mail ankommt?
Wenn die email nicht angenommen wird, merkt das Dein(!)
localer Mailserver und kann die Mail für 10 Minuten zurück stellen
ehe er esnochmal probiert.
Rainer Zocholl
>Guido Hennecke <0d-10...@usenet.kicks-ass.org> wrote:
>>Nachdem ich den Draft nun gelesen habe, entfaellt das in dieser
>>Version ohnehin, da explizit erwaehnt wird, dass lediglich der Domain
>>Part aber _nicht_ der Local Part in den RMX Eintrag kommt.
>Ich hab den Draft so verstanden, daß explizit der Local Part auch
>erlaubt sein KANN.
Das hab ich auch gelesen.
Vermutlich haben das einige andere übersehen oder
wir beide haben ds missverstanden.
Allerdings ist ein "localpart spezifischer" RMX durchaus nützlich.
>Wenn das falsch ist, entfällt natürlich alles was ich hier geschrieben
>hab.
Nunja, es wäre ebend extrem aufwändig, aber eine
prima Einnahmemöglichlichkeit T-Online.
(Deren "relay host" wohl nutzlos werden würde... oder
irgendwann so viele Domains versenden darf, das es wieder
für Spammer interessant wird. D.h. t-online muss natürlich prüfen
ob die Domain genau für diesen Kunden auch freigeschaltet worden ist!
Derzeit wird das wohl eher nicht geprüft. Wer den relay host
bezahlt, darf jede Domain verwenden. AFAIK.)
Rainer Zocholl
>* Rainer Zocholl <UseNet-Posting...@zocki.toppoint.de>
>> Dann könnte ja jeder Kunde ganz einfach "seinen" Server
>> fest ins Netz stellen. (Das das dank dyn-dns eh obsolete ist haben
>> diese Provider noch nicht realisiert).
>Oh doch, das haben schon einige bemerkt.
Und was tun sie dagegen? ;-)
>Ausserdem denke ich, dass es eher der hohe Traffic ist, warum die
>Provider genau das nicht wollen.
Ja, klar ist es der Traffic:
Ein Server wird ja nun mal immer "per Defintion"
von mehreren Nutzern im Netz benutzt...
>Dank Filesharing sind es aber gerade die Dialups, die viel Traffic
>erzeugen und denen ist es egal, ob sie eine feste IP haben oder nicht.
bei Filesharing ist eine feste IP sogar von echtem Vorteil!
Ich sehe bei mir (wir haben feste IP an den Dial-ups )
z.B. nie grossartige "Kaaza"-Suchereien.
Bei dyn-IP kommen immer noch lange Zeit später tausende von Anfragen,
wenn der Vorgänger mal einen Server laufen hatte...
>> Also: Ich vermute mal, das auch bei IPv6 der "normal Verbrucher"
>> weiterhin dynamische IPs bekommt, da man nru so die festen teurer
>> Verkaufen kann.
>Das waere moeglich, aber vollkommen unsinnig.
Wenn man damit Geld machen kann ist es leider nicht unsinnig...
wie man aus einer unsinnigen, unnötigen Sache Geld machen
kann beweist ja der enorme Erfolg des T-Online Löhn-relayhosts!
(die Leuten müssten nur minimal Umkonfigurieren...aber zahlen
statt dessen lieber 36(!) Euro im Jahr. Soviel hat einstmal
der komplette BTX-Zugang gekostet...)
>Siehe oben, das Nutzerverhalten hat sich geaendert und eine feste IP
>ist eher eine Erleichterung fuer den Provider und vielleicht sogar die
>einzige Chance, schwarze Schafe aus der eigenen Kundschaft ueberhaupt
>identifizieren zu koennen.
ACK.
>Wenn dank /64 dann allerdings jeder Depp sein komplettes Lan ins
>Internet routet und umgekehrt, dann duerfen wir uns auf noch groessere
>Wurmschwemmen freun.
Uwe Schröder
>
> Ist auch gut so. Und im From: kannst Du Deine Compuserve-Adresse ja
> weiterhin ungestraft angeben, lediglich im Envelope sollte sie nicht
> auftauchen - IMHO durchaus zurecht.
Das ist mir klar.
Einwand 1: Nur um über den Smarthost meines Zugangsproviders versenden
zu können, müßte ich meine bisher sorgsam gehütete Kunden-Mailadresse
preisgeben. Da braucht nur eine einzige Mail in die falschen Hände zu
geraten, und schon ist auch diese Adresse verbrannt.
Einwand 2: Dann würde gewaltiger Nachbesserungsbedarf bei den MUAs
bestehen. Keins der Programme, mit denen ich regelmäßig arbeite, bietet
die Möglichkeit, From: und From_ unabhängig voneinander zu setzen.
Einwand 3: Wenn ich das From_ eh so wählen muß, daß es zum Smarthost
paßt, und das From_ eh von jedem Relay neu gesetzt werden muß, dann kann
der Smarthost ja auch gleich mein From_ ignorieren und eigenhändig etwas
Passendes eintragen - er weiß schließlich am besten, für welche Domains
er versenden darf. Letztlich bleibt von dem originalen From_ kein Bit
mehr übrig und es hat seine eigentliche Funktion - eine Adresse für
Status- und Fehlermeldungen zu übermitteln, völlig verloren. Das hätte
man IMHO mit einem leicht modifizierten, verifizierbaren (meinetwegen
auch über RMX-Records, die Idee an sich ist gar nicht schlecht) HELO
billiger haben können, ohne die ganzen Seiteneffekte, die das
Herumpfuschen im From_ mit sich bringt.
usch
Ralf Döblitz
[...]
> Wo darf ich in so einem Fall meine Mails abkippen?
Nirgends, wenn Compuserve der Meinung sein sollte, daß Mails mit ihrer
Domain auch über ihre Server laufen sollten. Das ist halt der Preis, den
man für die erhöhte Sicherheit zahlen muß: weniger (mißbrauchbare)
Flexibilität.
Ich persönlich sehe da aber überhaupt kein Problem. Dann kann man eben
eine bestimmte Adresse nicht mehr als Absender im Envelope-From
benutzen. Das hindert dich doch nicht dran, eine deiner anderen Adressen
dafür zu verwenden und die Compuserve-Adresse nur in der Message zu
benutzen.
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.
Walter Hofmann
>
> Das war in den ersten beiden Versionen des Drafts so. In der aktuellen
> Version 3 wird unter 3.3 (und 4.2) zur Diskussion gestellt, auch den
> Eintrag einzelner local parts zu ermöglichen. Um es klar zu sagen: Dies
> ist dann eine *Möglichkeit*, die ein Administrator hat. Meist wird er
> wohl pauschal für die ganze Domain einen Eintrag machen und höchstens
> für bestimmte Einzelfälle einen weiteren ergänzen.
Zumal dann Spammer das DNS nach Emailadressen absuchen können, sei es um
sie zu bespammen oder um an ungeschützte Absenderadressen zu kommen.
Walter
Ralf Döblitz
[...]
> Ähmmm... Ich wähle mich bei T-Offline ein. Meine Domain liegt anderswo
> und der DNS läßt sich nicht dynamisch updaten.
Wieso nicht? Wenn es die eigene Domain ist, dann sollte das machbar
sein. Wenn nicht, ahemm, dann muß eben die vom Domaininhaber vorgesehe-
nen Versandwege benutzen. Darin sehe ich nichts schlimmes.
Außerdem kann man mit APL-Verweisen auch für eine bestimmte Mailadresse
auf einen Eintrag iverweisen, der auf einem ganz anderen Nameserver
(dynamisch) gepflegt wird.
> Und schon haben wir das Schlamassel. Und dann würde ich auch erstmal
> sehen wollen, dass die Provider den dynamic update so sicher bekommen,
> dass Spammer nicht darin rumpfuschen können...
Du hättest ja nicht kündigen müssen. ;-)
Und du weißt, wo du feste IP-Adresse, dynamic DNS etc. bekommen kannst.
Rainer Zocholl
>Einwand 3: Wenn ich das From_ eh so wählen muß, daß es zum Smarthost
>paßt, und das From_ eh von jedem Relay neu gesetzt werden muß, dann
>kann der Smarthost ja auch gleich mein From_ ignorieren und
>eigenhändig etwas Passendes eintragen - er weiß schließlich am besten,
>für welche Domains er versenden darf.
Nunja, aber welche der 16000 Domains soll er nehmen?
>Letztlich bleibt von dem originalen From_ kein Bit mehr übrig
>und es hat seine eigentliche Funktion - eine Adresse für Status-
>und Fehlermeldungen zu übermitteln, völlig verloren.
Wieso? Der Localpart erlaubt doch eindeutige Rückschlüsse.
Der Haken ist aber die Bounce bearbeitung,
wenn der einliefernde nicht auch im envelope genannt wird.
>Das hätte man IMHO mit einem leicht
>modifizierten, verifizierbaren (meinetwegen auch über RMX-Records, die
>Idee an sich ist gar nicht schlecht) HELO billiger haben können,
"Noch" hat man es nicht... ;-)
Aber wenn nur man den "HELO" definiert (was ja auch vorgesehen ist)
so das er einen passenden RMX hat, wäre ja auch schon etwas gewonnen.
Zumal bisher der "HELO" ja eh "nur nicht auf . enden darf" und
insofern nirgends wirklich ausgewertet wird.
Was würde man gewinnen?
Versand über offene Proxy wäre weiterhin möglich,
da der Spammer in seinem DNS den RMX eintrag machen würde.
Man könnte natürlich diesen Nameserver/diese Domains nicht akzeptieren.
Die Spammer würden ausserdem die vollkommene Anonymität verlieren
die er jetzt bei offenen Proxies hat.
Offene relays könnten aber weiterhin benutzt werden,
da sie ja einen gültigen HELO hätten, wenn der Admin
einen RMX eintrag gemacht hat...
Dyn-IP müssten sich auch um RMX Einträge kümmern
>ohne die ganzen Seiteneffekte,
Irgendwie bringt das aber auch nicht sooo viel:
Wir bekommen weiterhin pro Tag hunderttausende von Bounces,
AOL bekommt zig Millionen solcher Bounces
weil ein Arsch die Domains als From missbraucht.
AOL kann vielleicht mal einen Spammer erwischen und
verknacken, aber alle anderen deren Domain missbraucht wird?
Es sei denn, alle anderen Mailserver blocken den NS des Spammers
und offene Relays...(mittels leicht angreifbarer RBLs...)
>die das Herumpfuschen im From_ mit sich bringt.
Tja. Leider haben unsere Vorgänger an dieser Stelle etwas vergessen...
Norbert Hoffmann
> (Deren "relay host" wohl nutzlos werden würde... oder
> irgendwann so viele Domains versenden darf, das es wieder
> für Spammer interessant wird. D.h. t-online muss natürlich prüfen
> ob die Domain genau für diesen Kunden auch freigeschaltet worden ist!
> Derzeit wird das wohl eher nicht geprüft. Wer den relay host
> bezahlt, darf jede Domain verwenden. AFAIK.)
Es wird wohl eher eingeschränkt werden auf die Verwendung der
T-Online-Adresse im Envelope. Das dürfte aber nur die wenigsten stören. Man
sieht aber, dass bis zur Nutzung von RMX-Records noch viel Zeit vergehen
muss. Für die bisherige (nicht spammende) Funktionalität von Mail müssten
ja noch die Clients angepasst werden, damit sie mit unterschiedlichem
Envelope-From (passend zum genutzten Smarthost) und From: (je nach
gewünschter Antwort-Mailbox) umgehen können.
Norbert
Bodo Eggert
> Henning Hucke <h_hucke+...@remove.aeon.icebear.org> wrote:
>> Ähmmm... Ich wähle mich bei T-Offline ein. Meine Domain liegt anderswo
>> und der DNS läßt sich nicht dynamisch updaten.
>
> Wieso nicht? Wenn es die eigene Domain ist, dann sollte das machbar
> sein.
Weil die Update-Zeit einer DNS-Zone üblicherweise auf _langes_ cachen
ausgelegt ist. Update erfolgt mit Glück über Telefon, mit Pech über Email
(Henne, Ei), garantiert aber langsamer (üblich ist ein Tag) als die
Zwangstrennung.
> Außerdem kann man mit APL-Verweisen auch für eine bestimmte Mailadresse
> auf einen Eintrag iverweisen, der auf einem ganz anderen Nameserver
> (dynamisch) gepflegt wird.
Was passiert nach dem Trennen der Online-Verbindung mit dem dyndns-Eintrag?
--
Our last fight was my fault: My wife asked me "What's on the TV?"
I said, "Dust!"
Friß, Spammer: p...@dyxnet.com sup...@new-offers.net
Bodo Eggert
> Zusammenfassend gesagt: Der Return-Path hat nach der SMTP-Übertragung
> die Funktion des Envelope-From, nämlich den Weg anzugeben, den
> Fehlermeldungen nehmen sollen. Beiden Angaben nun unterschiedliche
> Funktionen zuzuweisen, ist daher problematisch. Aber nicht unlösbar,
> falls das gewünschte Verhalten (Erhalt eines vorhandenen Return-Path
> beim ausliefernden Mailserver) in Standardinstallationen bereits gegeben
> ist (das wäre zu prüfen).
Mal sehen:
>> return_path_remove
>>
>> Type: boolean
>> Default: true
Verloren!
> Andere Idee:
>
> Wie wäre es, wenn das weiterleitende Relay im SMTP-Dialog (nach RfC 821)
> so etwas im Envelope-From angeben würde:
> @example.org:urspruenglic...@example.com
1) Dann wird dort eine Domain eingesetzt, die keinen rmx hat oder einen
von 0/0. Das hebelt die Koexistenz aus.
2) Bei Fehlermeldungen ergibt sich:
|MAIL FROM: <@example.org:>
|501 <@example.org:>: missing or malformed local part
> Laut RfC 2821 (F.2) müssen aktuelle Server das noch unterstützen, dürfen
> aber bei Nutzung der Adresse (hier: im Fall von Bounces) auch direkt die
> letztgenannte Adresse anschreiben. Ob es damit nicht doch Probleme gibt,
> weiß ich nicht. Mein sendmail übernimmt einfach die hinter dem ":"
> angegebene Adresse, was ja unproblematisch ist.
exim schneidet ^.*: ab, diese Information geht also verloren.
--
Top 100 things you don't want the sysadmin to say:
86. What do you mean that wasn't a copy?
Friß, Spammer: in...@er.uqam.ca postm...@handpickeddeals.com
Hatto von Hatzfeld
> Letztlich bleibt von dem originalen From_ kein Bit mehr übrig und es
> hat seine eigentliche Funktion - eine Adresse für Status- und
> Fehlermeldungen zu übermitteln, völlig verloren.
Wie Guido schon dargelegt hat, wird so im Gegenteil abgesichert, dass
die Fehlermeldung nicht an irgendeine angebliche, sondern mit viel
höherer Wahrscheinlichkeit an die echte Absenderadresse geht.
> Das hätte man IMHO mit einem leicht modifizierten, verifizierbaren
> (meinetwegen auch über RMX-Records, die Idee an sich ist gar nicht
> schlecht) HELO billiger haben können
Der Missbrauch fremder Domains im Envelope-From (mit der Folge von
Spam-Bounces) wäre damit aber immer noch möglich.
Ciao,
Hatto
--
Sollte es wirklich Progr@mme geben, die @lles, w@s n@ch einer
M@iladresse @ussieht, zum Zwecke des Sp@mmens eins@mmeln?
Stefan Froehlich
> > [...] im From: kannst Du Deine Compuserve-Adresse ja weiterhin
> > ungestraft angeben, lediglich im Envelope sollte sie nicht
> > auftauchen - IMHO durchaus zurecht.
> Das ist mir klar.
> Einwand 1: Nur um über den Smarthost meines Zugangsproviders
> versenden zu können, müßte ich meine bisher sorgsam gehütete
> Kunden-Mailadresse preisgeben.
Nein, das wiederum nicht. Du darfst nicht eine Compuserve-Adresse im
Envelope-From angeben, wenn Du ueber t-Online eingewaehlt bist, weil
Compuserve sich (dann, ggf.) das Recht vorbehaelt, zu bestimmen,
welche Mailserver das tun duerfen. Du darfst aber sehr wohl
umgekehrt fuer Domains unter _Deiner_ Kontrolle bestimmen, dass
Mails mit deren Absenderadresse z.B. von Deiner jeweiligen IP aus
verschickt werden duerfen.
Es ist genau umgekehrt: nicht der Adressinhaber bestimmt, welche
Domains verwendet werden duerfen, sondern der Domaininhaber
bestimmt, welche Adressen zum Versand benutzt werden duerfen (auch
fremde, wenn gewuenscht).
> Einwand 2: Dann würde gewaltiger Nachbesserungsbedarf bei den MUAs
> bestehen. Keins der Programme, mit denen ich regelmäßig arbeite,
> bietet die Möglichkeit, From: und From_ unabhängig voneinander zu
> setzen.
Das ist allerdings ein gewisser Jammer. Andererseits:
Otto-Normalverbraucher wird das nicht sehr hart treffen (dem ist eh
egal, was wo eingetragen wird, solange seine Mail nur irgendwie
ankommt). Vom Rest hat wohl ein guter Teil Systeme und MUAs, die so
etwas mitspielen... naja, und wenn genug Bedarf da ist, wird fuer
die verbleibenden Leute schon eine Loesung entwickelt werden, oder?
> [...] dann kann der Smarthost ja auch gleich mein From_ ignorieren
> und eigenhändig etwas Passendes eintragen - er weiß schließlich am
> besten, für welche Domains er versenden darf.
Nein, siehe Einwand 1.
Servus,
Stefan
--
http://kontaktinser.at/
Die kostenlose oesterreichische Kontaktboerse
Stefan Froehlich
> Was passiert nach dem Trennen der Online-Verbindung mit dem
> dyndns-Eintrag?
Das sollte erst einmal egal sein, weil Du nach dem Trennen der
Verbindung ja auch keine Mail mehr verschicken wirst. Der RMX Record
wird ja immer nur dann abgefragt, wenn ein fremdes System von Dir
kontaktiert wird. (Die Chance, dass jemand anders Deine alte IP-Adresse
zugewiesen bekommt und irgendwie herausfindet, dass er damit jetzt Mails
mit Deinem From_ verschicken darf UND das auch noch tut, halte ich fuer
vernachlaessigbar gering)
Hatto von Hatzfeld
> Hatto von Hatzfeld <ha...@salesianer.de> wrote:
>
> > Zusammenfassend gesagt: Der Return-Path hat nach der SMTP-Übertragung
> > die Funktion des Envelope-From, nämlich den Weg anzugeben, den
> > Fehlermeldungen nehmen sollen. Beiden Angaben nun unterschiedliche
> > Funktionen zuzuweisen, ist daher problematisch. Aber nicht unlösbar,
> > falls das gewünschte Verhalten (Erhalt eines vorhandenen Return-Path
> > beim ausliefernden Mailserver) in Standardinstallationen bereits gegeben
> > ist (das wäre zu prüfen).
>
> Mal sehen:
> >> return_path_remove
> >>
> >> Type: boolean
> >> Default: true
>
> Verloren!
Und bei sendmail scheint das auch so zu sein, wie mein Test eben ergab.
Pech gehabt. Allerdings könnte man nun bei einem Server, den man auf RMX
sensibilisiert, dieses Verhalten auch gleich mit ändern.
> > Andere Idee:
> >
> > Wie wäre es, wenn das weiterleitende Relay im SMTP-Dialog (nach RfC 821)
> > so etwas im Envelope-From angeben würde:
> > @example.org:urspruenglic...@example.com
>
> 1) Dann wird dort eine Domain eingesetzt, die keinen rmx hat oder einen
> von 0/0. Das hebelt die Koexistenz aus.
Der empfangende Server prüft hier ja, ob das Relay einen RMX-Eintrag
hat, der diesem erlaubt, mit @example.org Mails zu verschicken. Das
Relay kann hier also nicht "irgendeine" Domain einsetzen.
Das Problem dagegen, dass jemand Domains mit einem 0/0-RMX angibt,
existiert unabhängig von dem hier diskutierten Relay-Problem.
> 2) Bei Fehlermeldungen ergibt sich:
> |MAIL FROM: <@example.org:>
> |501 <@example.org:>: missing or malformed local part
Klar. Da muss ja auch eine Adresse hinter dem ":" stehen, um der Syntax
von RfC 821 zu entsprechen. Und zwar die des ursprünglichen Absenders.
Oder meinst Du den Fall, dass ein Bounce weitergeleitet wird? Dann darf
das Envelope-From eben nicht geändert werden, sondern muss "<>" bleiben.
Die Frage aber, wie bei einem "<>" eine RMX-Abfrage gemacht werden soll,
existiert unabhängig von dem hier diskutierten Relay-Problem und wird in
Abschnitt 4.3 des Drafts damit beantwortet, das in solchen Fällen der im
HELO angegebene Hostname für die RMX-Abfrage herangezogen wird.
> > Laut RfC 2821 (F.2) müssen aktuelle Server das noch unterstützen, dürfen
> > aber bei Nutzung der Adresse (hier: im Fall von Bounces) auch direkt die
> > letztgenannte Adresse anschreiben. Ob es damit nicht doch Probleme gibt,
> > weiß ich nicht. Mein sendmail übernimmt einfach die hinter dem ":"
> > angegebene Adresse, was ja unproblematisch ist.
>
> exim schneidet ^.*: ab, diese Information geht also verloren.
Das macht sendmail auch so. Dann sieht die ankommende Mail ganz genauso
aus wie sie derzeit (ohne Änderung des Envelope-From) aussieht; niemand
hat also einen Nachteil. Ein RMX-sensibler Server dagegen wird diese
Information für die RMX-Abfrage auswerten (das ist mein Vorschlag) und
in der Received-Zeile oder einem anderen Header niederlegen (siehe
Abschnitt 10.3 im Draft).
Im Übrigen ist die im Draft vertretene Auffassung, dass ein (per
.forward, Mailingsliste o.ä.) weiterleitender Server durchaus eine
eigene Adresse in den Envelope-From eintragen sollte, da er ja
schließlich mit der Weiterleitung die Verantwortung für den Versand der
Mail übernimmt, auch nicht so einfach von der Hand zu weisen. Mir
passiert es z.B. nicht selten, dass ich an einen Role-Account schreibe
(z.B. ab...@example.net), dieser dann an z.B. 5 verschiedene Adressen
weiterleitet, wovon z.B. 2 aus irgendwelchen Gründen bouncen. Es ist
eigentlich weder in meinem Sinn noch im Sinn der betreffenden Firma,
dass ich nun erfahre, dass me...@abt5.example.net einer der Mitarbeiter
des Abuse-Desks ist, sein Postfach aber, da in Urlaub, gerade überläuft,
während mue...@abt5.example.net anscheinend nicht mehr dort arbeitet
und Mails an ihn mit "User unknown" bouncen.
Gruß,
Hatto
--
"IcH fInDe AuCh, dAsS eS nIcHt So WiChTig IsT, eInEn TeXt In KoRrEcKtEr
gRoSs- Und KlEiNsChReIbUnG zU vErFaSsEn, Da DiEs DeR LeSbArKeIt KaUm
AbBrUcH tUt UnD zUdEm AuSdRuCk MeInEr InDiViDuAlItAeT iSt."
[Joachim Kromm in dsnu]
Hatto von Hatzfeld
> * Walter Hofmann <abe...@mx2.homelinux.com> wrote:
> > Zumal dann Spammer das DNS nach Emailadressen absuchen können, sei es um
> > sie zu bespammen oder um an ungeschützte Absenderadressen zu kommen.
>
>
> Es sei denn, jemand laesst Zone Transfers fuer jeden zu, was ohnehin
> eine aehnliche Fehlkonfiguration wie ein offenes Relay ist.
>
> Wenn ich das bisher richtig verstanden habe, dann fragt der Client
> (Empfangende MX) lediglich den RMX zu <email@adresse> oder nur den
> Domain Part der Adresse ab und bekommt als Antwort IP Adressen bzw.
> Netze und/oder Domains, die mit der _abgefragten_ Absenderadresse
> Mails versenden duerfen.
>
> Ist also kein Zonetransfer moeglich, kann man so keine Email Adressen
> abfragen.
>
> So kann man auch nicht gezielt abfragen, fuer welche Adressen/Domains
> ein Relay absenden darf.
>
> Oder sehe ich hier was falsch?
Der letzte Absatz in Abschnitt 3 des Danisch-Draft (Version 3)
beschreibt es so wie Du sagst. Ich zitiere einmal:
| One method could be to query the full address, and if no RMX records
| were found to query the domain part only. A different approach would
| be to query the domain part only, and if it's RMX record contain a
| special entry, then a new query for the full address is triggered. A
| third way would be to always query the full address and to leave the
| problem to the wildcard mechanism of DNS. This still has to be
| discussed and will be described in future versions of this draft.
Falls eine der ersten beiden Möglichkeiten realisiert wird, dann hat man
das Problem, was man schon mit dem SMTP-Befehl "verify", der aus gutem
Grund bei den meisten Servern deaktiviert ist, hatte: Man kann damit
zwar nicht abfragen, welche Adressen es gibt, aber verifizieren, ob eine
bestimmte einzelne Adresse existiert.
(Anmerkung zur Vorbeugung vor überhasteten Antworten durch flüchtige
Mitleser: Das Problem besteht, wie aus dem Zusammenhang des Teilthreads
hervorgeht, nur dann, wenn ein Administrator meint, er müsse einzelnen
Adressen unterschiedliche RMX- Einträge zuordnen.) :-)
Ciao,
Hatto
--
Aktion für mehr Demokratie im Usenet:
http://www.christkath.ch/usenet/Mitmach-FAQ.txt
Hatto von Hatzfeld
> Man sieht aber, dass bis zur Nutzung von RMX-Records noch viel Zeit
> vergehen muss. Für die bisherige (nicht spammende) Funktionalität von
> Mail müssten ja noch die Clients angepasst werden,
Eigentlich nicht. Denn beim durchschnittlichen Mail-Nutzer gehören die
von ihm verwendete Domain und der von ihm verwendete Postausgangsserver
(aka Smarthost) zum selben Provider, und da wird der passende
RMX-Eintrag kein Problem sein.
> damit sie mit unterschiedlichem Envelope-From (passend zum genutzten
> Smarthost) und From: (je nach gewünschter Antwort-Mailbox) umgehen
> können.
Nur zur Erinnerung: Für die gewünschte Antwort-Mailbox ist nicht From:,
sondern Reply-To: gedacht. Man kann diese durchaus für den vorgesehenen
Zweck nutzen.
Ciao,
Hatto
--
Fast alle Menschen haben mehr Beine als der Durchschnitt.
Lutz Frommberger
> Emm, sollte man aber.
Nein, braucht man nicht.
> Das ist so ungefähr als wenn ein Maurer sagt, das er nicht weiss
> was ein Zentimeter oder ein rechter Winkel ist...(kommt leider
> oft vor das er es nicht weiss, aber nicht zugibt. Maurer ebend ;-))
Ich möchte nicht die Mauer bauen, ich möchte in dem entstehenden
Haus wohnen. Mehr nicht. DNS hat mich bislang nur marginal
interessiert, und das hat sich auch nicht weiter geändert. Ich
finde es überhaupt schon bedenklich, wieviel Systemwissen ich
in den letzten Jahren anhäufen musste, nur um das weiter tun
zu können, was ich schon seit über einem Jahrzehnt tue: Emails
versenden.
> Wenn die email nicht angenommen wird, merkt das Dein(!)
> localer Mailserver und kann die Mail für 10 Minuten zurück stellen
> ehe er esnochmal probiert.
Das bedeutet für Dialup-Hosts: 10 Minuten online bleiben. Das
ist keine akzeptable Lösung.
gruß,
--
Lutz Frommberger
http://www.aussagekraft.de/
pgp key on request