seit ca. 1 Jahr kommen des öfteren, vermutlich Newsletters, von einem Server für verschiedene Benutzer und werden jedesmal mit 550 abgewiesen. Soweit so gut, jetzt dreht das Mailsystem allerdings völlig durch: So wurden gestern 161 Zustellversuche allein für eine, nicht mehr zustellbare, Adresse gemacht - in der folgenden Art sind alle abgewiesen worden:
reject: RCPT from smtp (dot) wvi (dot) de[212 (dot) 66 (dot) 8 (dot) 43]: 550 <nicht_mehr_existenten@user_in _der_domain.welt>: Recipient address rejected: User unknown in local recipient table; from=<wuvlist (at) efvnews (dot) de> to=...
Mein Anruf bei der technischen Ansprechperson ergab, die Geschäftsleitung würde das ausdrücklich so wünschen, und Fehler würden daher nicht bearbeitet, ich kann das seit ca. 1 Jahr betstätigen.
Ich betrachte dieses abusive Verhalten mit Skepsis und frage mich was man da tun kann?
> Mein Anruf bei der technischen Ansprechperson ergab, die > Geschäftsleitung würde das ausdrücklich so wünschen, und Fehler würden > daher nicht bearbeitet, ich kann das seit ca. 1 Jahr betstätigen.
> Ich betrachte dieses abusive Verhalten mit Skepsis und frage mich was > man da tun kann?
Du könntest mal die neue Sportart "extreme ignoring" antesten...
Markus Neubauer <mein_nachn...@spamcop.net> wrote: > Mein Anruf bei der technischen Ansprechperson ergab, die Geschäftsleitung würde das ausdrücklich so wünschen, und Fehler würden daher nicht bearbeitet, ich kann das seit ca. 1 Jahr betstätigen.
(Äh, Zeilenlänge?)
> Ich betrachte dieses abusive Verhalten mit Skepsis und frage mich was > man da tun kann?
Komplett blacklisten, wenn das nicht hilft, Firewall oder Nullroute davor, wenn du so weit gehen willst.
Allerdings ist natürlich niemand verpflichtet, aus einer Fehlermeldung eine Lehre zu ziehen. Nervig ist das allerdings schon.
S°
-- Fachbegriffe der Informatik - Einfach erklärt 118: Chipkarten auslesen Mit rauchender Salpetersäure rumblubbern und schief anschielen. (Matthias Brüstle)
>Das fällt leider aus, da viele Domains über den Server laufen, >aber (nur?) 30 User sinnlos zugeballert werden.
>Gibt es da irgenwas in der Richtung t5?
ich denke, Du hast einen Unterlassungsanspruch gegen das Unternehmen.
Mahn ihn eben nochmal an, setze ihm nochmal eine Frist zur Beseitigung des Problems und weisse ihn darauf hin, dass Du ansonsten einen Anwalt einschalten musst. Das würde ihn dann eben Geld kosten.
Die Welt kommt sicher gut ohne Anwälte aus....aber wenn es einen extremen Fall gibt, dann sind sie wohl nötig. Oder zumindest die Androhnung inkl. Kosten....
> seit ca. 1 Jahr kommen des öfteren, vermutlich Newsletters, von einem Server für verschiedene Benutzer und werden jedesmal mit 550 abgewiesen. > Soweit so gut, jetzt dreht das Mailsystem allerdings völlig durch: So wurden gestern 161 Zustellversuche allein für eine, nicht mehr zustellbare, Adresse gemacht - in der folgenden Art sind alle abgewiesen worden:
> Ich betrachte dieses abusive Verhalten mit Skepsis und frage mich was man da tun kann?
wenn es dich gar zu sehr nervt, drohe ihnen halt an, einen kaputten autoresponder auf die betroffenen adressen anzusetzen, der den muell an die subscribe-adresse des newsletters zurueckschickt, spaeter ggf. mit CC an weitere adressen des betreibers.
RFC 821 kann niemand mehr verletzen, weil der durch RFC 2821 außer Kraft gesetzt wurde. RFC 1123 ist an den entscheidenden Stellen ebenfalls durch RFC 2821 aktualisiert worden. RFC 2505 gibt Empfehlungen für das empfangende System, nicht für das sendende.
Bliebe also RFC 2821. Und da wäre die Frage, ob es sich um wiederholte Zustellversuche _derselben_ Mail trotz 5xx handelt (das wäre in der Tat ein RFC-Verstoß), oder ob da tatsächlich so viele unterschiedliche Mails für denselben Empfänger in der Queue lagen. AFAIK ist ein Relay nicht verpflichtet, sich ein "mailbox not found" zwischen verschiedenen Transaktionen zu merken und weitere Mails an dasselbe MAIL TO quasi vorauseilend zu bouncen, ohne überhaupt einen Zustellversuch zu unternehmen.
Das wird man letztlich nur herausfinden können, indem man die Mails erst einmal annimmt und erst nach dem DATA ein 5xx sendet.
> > Ich betrachte dieses abusive Verhalten mit Skepsis und frage mich was man da tun kann?
> wenn es dich gar zu sehr nervt, drohe ihnen halt an, einen kaputten > autoresponder auf die betroffenen adressen anzusetzen, der den muell > an die subscribe-adresse des newsletters zurueckschickt, spaeter ggf. > mit CC an weitere adressen des betreibers.
> -- > frobnicate foo
Frank,
das hatte ich schon, war aber leider ohne Wirkung verpufft.
Am Fri, 6 Aug 2004 16:15:52 +0200 schrieb Markus Neubauer:
> "frank paulsen" <frank.paul...@gmx.net> schrieb im Newsbeitrag news:cevvle$5o2$3@ebel.dfakt.de... >> wenn es dich gar zu sehr nervt, drohe ihnen halt an, einen kaputten >> autoresponder auf die betroffenen adressen anzusetzen, der den muell >> an die subscribe-adresse des newsletters zurueckschickt, spaeter ggf. >> mit CC an weitere adressen des betreibers.
> das hatte ich schon, war aber leider ohne Wirkung verpufft.
Uwe Schröder schrieb am 06. August 2004 17:36:53 CEST folgendes:
> Jens Wahnes wrote: >> Das wird auch durch ständiges Wiederholen nicht wahr. Standard ist nach >> wie vor 821, 2821 ist proposed standard. > Nun ja, auf http://www.rfc-editor.org/categories/rfc-standard.html ist > RFC0821 jedenfalls schon als "Obsoleted" markiert.
Ah, danke. Genau so eine Liste suche ich schon lange. Da hab ich wohl nicht richtig hingeschaut, bzw. anscheinend immer nur auf ietf.org statt auf rfc-editor.org.
Dann ersetzen wir in <4113844A.40...@office-1.ohrbelag.de> im zweiten Absatz das 2821 durch 0821; an der Schlußfolgerung ändert das allerdings nichts.
(Florian L. Klein) 06.08.04 in /de/admin/net-abuse/mail:
>[Zeilenlänge auf 72 Zeichen gekürzt] >Markus Neubauer wrote:
>[Absender ignoriert 5xx-Rejects]
>> Ich betrachte dieses abusive Verhalten mit Skepsis und frage mich >> was man da tun kann? >Sofern du den Mailserver selbst betreibst, hilft bei merkbefreiten >5xx-Ignoranten nur die Holzhammermethode: ># route add -host $ip reject
Recejt? Wäre "drop" nicht besser?
>Durch das Nullrouting wird dem Absender irgendwann in Form einer >wachsenden Queue auffallen, dass er etwas flahcs macht.
Meinst Du der merkt das? Der wird sich wohl eher ne neue 200GB platte holen...
Je nach dicke der Leitungen (die man hat oder die man mitbenutzen kann) kann man natürlich die emails, em, bouncen lassen. Natürlich sollen man die bounces nicht gezielt deren Relayhost laufen lassen oder auf beiden Rechnern abliefern....
Hm, wollen die etwa ne Annahme erzwingen in dem sie 550er ignorieren und massiv wiederholen? Macht ja Sinn, wenn sie nach "zugestellten email" bezahlt werden resp. ihre Vorturner über den "Erfolg" täuschen wollen. Ausserderm kostet es natürlich erhebliche Zeit und damit geld, mit ungeeigneter Software eine Mailingliste fahren zu wollen. Bei den heutigen IP-Preisen kann man schon nachvollziehen das da in den Köpfe vorgeht, gerade wenn es der Firma nicht wirklich gut geht...
Dann wäre es sinnvoller den Newletter nicht zu rejecten, sondern immer mit ner 400er zu rejeten, aber mitten im Datenverkehr. "Oh ich weiss nicht wann Herr XY wieder im Hause ist, versuchen Sie es doch später".
Hübsch sind auch immer wieder Mailsschleifen. Aber schwierig zumachen.
Oder ne Teergrube? Der OP sagte ja, das die schon eMails von dort bekommen möchten.
Ansonsten den Uplink-Provider frage, oder die Bounces diesem ins Postfach werfen? Wenn er seriös ist, und man die Beschwerde-Email-Zustellung logarithmisch beschleunigt, wird er aus Sorge um sein Ticketsystem schon reagieren.
Uwe Schröder wrote: >> Das wird auch durch ständiges Wiederholen nicht wahr. >> Standard ist nach wie vor 821, 2821 ist proposed standard. > Nun ja, auf > http://www.rfc-editor.org/categories/rfc-standard.html > ist RFC0821 jedenfalls schon als "Obsoleted" markiert.
Das ist logischerweise der Vorschlag in RfC 282?. Wenn Du in RfC 3700 den Status fuer Juli 2004 erforschst, kommt das raus:
| 3. Current Technical Specifications | | 3.1. Standard Protocols Ordered by STD | | Mnemonic Title RFC# STD# [...] | SMTP Simple Mail Transfer Protocol 821 10 | SMTP-SIZE SMTP Service Extension for Message Size 1870 10 | Declaration | MAIL Standard for the format of ARPA Internet text 822 11 | messages
Das duerfte fuer den Umgang mit 5xx Fehlern aber ziemlich egal sein. Dass sich ein Absender merken "muss", wenn RCPT TO nicht geht, steht ziemlich sicher weder in 821 noch in 2821.
Allein schon die Frage, wie lange das gelten soll, waere so spannend, dass wir hier davon gehoert haetten, wenn es sowas gaebe.
Spannend finde ich, dass RfC 2505 diverse "MUST" enthaelt, ich dachte, dass das in BCP nicht geht. Oder verwexle ich BCP mit FYI ? Bye, Frank
Frank Ellermann wrote: > Das ist logischerweise der Vorschlag in RfC 282?. [...]
> Das duerfte fuer den Umgang mit 5xx Fehlern aber ziemlich egal > sein.
Eben. Der Einwand war bestenfalls ein Ablenkungsmanöver.
> Dass sich ein Absender merken "muss", wenn RCPT TO nicht > geht, steht ziemlich sicher weder in 821 noch in 2821.
Ich würde sogar eher vermuten, daß er es nicht einmal DARF.
Also: DARF ein Relay auf ein 5.1.1 hin alle anderen Mails in seiner Queue an denselben Empfänger gleich mit bouncen, oder MUSS es für jede Mail mindestens einen Zustellversuch unternehmen und sich den zu erwarteten Fehlerstatus abholen?
Uwe Schröder wrote: > Frank Ellermann wrote: >>Dass sich ein Absender merken "muss", wenn RCPT TO nicht >>geht, steht ziemlich sicher weder in 821 noch in 2821. > Ich würde sogar eher vermuten, daß er es nicht einmal DARF.
> Also: DARF ein Relay auf ein 5.1.1 hin alle anderen Mails in seiner > Queue an denselben Empfänger gleich mit bouncen, oder MUSS es für jede > Mail mindestens einen Zustellversuch unternehmen und sich den zu > erwarteten Fehlerstatus abholen?
Daswird wohl nicht im RFC stehen (Policy, nicht Technik), aber es nicht zu versuchen ist in vilen Fällen einfach Schwachsinn:
> Ihre Mail konnte nicht zugestellt werden, weil vor drei Wochen > eine 100MB-Mail an die gleiche Adresse unzustellbar war.
Oder war 5.1.1 jetzt ein spezifischer Extended-Code zu "gibt es nicht"?
Jost Krieger wrote: >> Ihre Mail konnte nicht zugestellt werden, weil vor drei Wochen >> eine 100MB-Mail an die gleiche Adresse unzustellbar war.
> Oder war 5.1.1 jetzt ein spezifischer Extended-Code zu "gibt es nicht"?
Natürlich. "Bad destination mailbox address". Außerdem sprach ich nicht davon, den Status drei Wochen zu cachen, sondern einmal in die Queue zu schauen und alles zu bouncen, was in diesem Augenblick noch für diesen Empfänger ansteht. Selbst wenn es die Adresse jetzt gerade nicht gibt, könnte sie ja fünf Minuten später zufällig eingerichtet werden.
(Uwe Schröder) 07.08.04 in /de/admin/net-abuse/mail:
>Frank Ellermann wrote: >> Dass sich ein Absender merken "muss", wenn RCPT TO nicht >> geht, steht ziemlich sicher weder in 821 noch in 2821. >Ich würde sogar eher vermuten, daß er es nicht einmal DARF. >Also: DARF ein Relay auf ein 5.1.1 hin alle anderen Mails in seiner >Queue an denselben Empfänger gleich mit bouncen, oder MUSS es für jede >Mail mindestens einen Zustellversuch unternehmen und sich den zu >erwarteten Fehlerstatus abholen?
Nein, darf er nicht.
Manche Mailfilter rejecten aufgrund des unerwünschten oder nicht auflösbaren Absenders mit einer "550 User unknown"
Ob das ne schlaue Idee ist, so zu tun, als gäbe es den user nicht, anstatt klipp und klar zusagen was Sache ist, ist wohl diskutierbar...ändert aber an der Praxis nix.
Ausserderm: Mir ist mindestens ein Billig-Provider bekannt, der keinerlei Mail Quue betreibt! D.h. egal ob 4xx oder 5xx die Mail geht sofort zum Absender zurück. Und der Kunde muss halt mit seinem MUA "Mailquue" spielen. Ist halt "Billig"...
Rainer Zocholl wrote: > Manche Mailfilter rejecten aufgrund des unerwünschten oder nicht > auflösbaren Absenders mit einer "550 User unknown"
Ich weiß, GMX zum Beispiel :( Wobei "550" aber eigentlich nur "Requested action not taken" bedeutet, also durchaus auch "Zugriff verweigert" heißen kann. Der Kommentar hinter dem Statuscode ist ja nicht standardisiert, und daß da "User unknown" steht, ist zwar ärgerlich und irritierend, aber technisch gesehen nicht falsch, weil es eh nicht maschinell auswertbar ist.
Deswegen sprach ich ausdrücklich von 5.1.1 "Bad destination mailbox address" nach RFC 1893.
