Was ist zu tun wenn ein Maillistenbetreiber sich weigert 550 bounces zu bearbeiten ?
Markus Neubauer
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?
Markus
Christoph Kliemt
[...]
> 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...
hth christoph
--
sig lost
Sven Hartge
> 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)
Markus Neubauer
"Markus Neubauer" <mein_n...@spamcop.net> writes:
[...]
[...]
> Du könntest mal die neue Sportart "extreme ignoring" antesten...
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?
Fragt Markus
Uli Bernt
..
>
>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....
uli
Frank Elsner
>
> Hi *,
>
> 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:
Bei http://www.rfc-ignorant.org/ melden.
Die verletzen RFC 821, 2821, 2505 und 1123
--Frank Elsner
frank paulsen
[ Newsletterbetreiber ignoriert Bounce ]
> 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
Uwe Schröder
> Bei http://www.rfc-ignorant.org/ melden.
>
> Die verletzen RFC 821, 2821, 2505 und 1123
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.
usch
Markus Neubauer
"frank paulsen" <frank....@gmx.net> schrieb im Newsbeitrag news:cevvle$5o2$3...@ebel.dfakt.de...
Frank,
das hatte ich schon, war aber leider ohne Wirkung verpufft.
Markus
Jens Wahnes
> RFC 821 kann niemand mehr verletzen, weil der durch RFC 2821 außer Kraft
> gesetzt wurde.
Das wird auch durch ständiges Wiederholen nicht wahr. Standard ist nach
wie vor 821, 2821 ist proposed standard.
Jens
--
Alle Wege führen an Redmond vorbei.
Lothar Kimmeringer
> "frank paulsen" <frank....@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.
Dann halt direkt an die Geschaeftsleitung.
Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: spam...@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)
Always remember: The answer is forty-two, there can only be wrong
questions!
Uwe Schröder
> 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.
usch
Florian L. Klein
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
Durch das Nullrouting wird dem Absender irgendwann in Form einer
wachsenden Queue auffallen, dass er etwas flahcs macht.
/.
DocSnyder.
--
Friss, Spammer: <webm...@allinternal.com> <sup...@allinternal.com>
<in...@allinternal.com> <sa...@allinternal.com> <he...@allinternal.com>
<rem...@allinternal.com> <ma...@allinternal.com> <a...@allinternal.com>
<off...@allinternal.com> <ne...@allinternal.com> <b...@allinternal.com>
Jens Wahnes
Und unter <http://www.rfc-editor.org/rfcxx00.html> kannst du die Liste
der offiziellen Standards abrufen.
Uwe Schröder
> Und unter <http://www.rfc-editor.org/rfcxx00.html> kannst du die Liste
> der offiziellen Standards abrufen.
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 <4113844...@office-1.ohrbelag.de> im zweiten
Absatz das 2821 durch 0821; an der Schlußfolgerung ändert das allerdings
nichts.
usch
Werner Jakobi
>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=...
Welcher Mailserver produziert denn das? Das sieht doch stark nach einem
ganz normalen Logfileeintrag aus.
Gruss, Werner
--
Morver, der Rollstuhl fuer kranke Windows-Newsreader und fuer OE.
Aktuelle Version 1.0.305: http://www.morver.de/
Daniel Fuchs
ist....
Daniel
Rainer Zocholl
>[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.
Ralph Angenendt
> "Markus Neubauer" <mein_n...@spamcop.net> posted:
>
>>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=...
>
> Welcher Mailserver produziert denn das? Das sieht doch stark nach einem
> ganz normalen Logfileeintrag aus.
Sieht nach Postfix aus. Warum?
Ralph
--
Suchmaschine - Standard - Rückgrat - Stegreif - Toleranz - Platitüde
hören - Paket - asozial - Terabyte - umbrochen - entgelten - intellektuell
Gebaren - Lizenz - delegieren - hältst - spülen - übertakten - lies nach
selbstredend - Algorithmus - Haken - projizieren - nachweislich - voraus - eklig
Frank Ellermann
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
Uwe Schröder
> 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?
usch
Jost Krieger
> 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"?
Gruß Jost |8-))
Uwe Schröder
>> 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.
usch
Rainer Zocholl
>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"...
Uwe Schröder
> 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.
usch
Markus Neubauer
> 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"...
Hat jemand Erfahrung was dann mit greylist Verfahren passiert ?
Versagt es dann hierbei völlig und bounced quasi alles?
?Markus
Rainer Zocholl
>"Rainer Zocholl" schrieb
Nein, wenn der user die eMail einmal nochmal schickt,
ist der Absender ja bekannt.
Die Message-ID wird ja nicht geprüft.
Unangehm wird es aber, wenn der Empänger mehrer MXe hat,
die alle Greylisten. Da ein "normaler" MTA (blöderweise?)
die erneute Zustellung immer wieder bei der beim ersten mal
ermittelten IP-# wieder holt, müssten die MXe keine gemeinsame
Datenbank benutzen. Ein User hätte dann aber gute chancen
ca. ((Anzahl MX/2)+1) versuche machen zu müssen...
Genau das ist natürlich das was die Spammersarsche machen werden:
Die werden einfach alle eMails 2mal schicken.
Kost' doch nicht ihr Geld!
Irgendwelche mail queues brauchen sie nicht, weil ja der
Text immer derselbe ist. Sie müssen nur den Addressenbesatnd
2mal durchgehen.
Greylist treibt den Teufel offenbar mit dem Belzelbub aus.
Jost Krieger
> Jost Krieger wrote:
>>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.
Was die Frage aufwirft, ob jemand, der eine Mail schreibt, in der
Hoffnung, dass die Zieladresse eingerichtet wird, bis die Mail ankommt,
eine ernstzunehmende Zielgruppe repräsentiert :-)
Auch nicht ganz RFC-gedeckt ist mein Verfahren, Mailadressen als
*Absender* zu blockieren, wenn sie Doublebounces verursachen.
Begründung: Wenn man deren Mail annimmt, kann man sie nicht mehr
benachrichtigen. Gut für eigene Kunden, die Ihre eigene Adresse nicht
richtig schreiben.
Werden im Fall des OP die Bounces eigentlich angenommen?
Gruß Jost |8-))
Jost Krieger
> 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.
Ein Grund für diese Reaktion ist meiner Erinnerung die Tatsache,
dass eine ganze Reihe (oder ein verbreiteter) MTAs Fehlermeldungen nach
"MAIL FROM:" mit einem sofortigen Neuversuch "belohnten".
Und SMTP sieht halt nicht vor, auf "RCPT TO:" mit
"Deine Nase gefällt mir nicht" zu reagieren.
> 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"...
Auf jemanden, der *vorsätzlich* essentielle Standards verletzt, sollte
man keine Rücksicht nehmen.
Gruß Jost |8-))
Rainer Zocholl
>Rainer Zocholl wrote:
>> 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"...
>Auf jemanden, der *vorsätzlich* essentielle Standards verletzt, sollte
>man keine Rücksicht nehmen.
Dessen Kunden wissen das doch nicht. Die sehen nur "billig".
Die sehen auch nur, das die email zurückgekommen ist.
Da hat natürlich der "ablehnende" Server schuld...bei
allen anderen klappt es ja...
ANDERE(!) Provider haben dann das Problem dem Billigheimer-Kunden
zu erklären, das das ein Fehler seines scheiss Providers ist!
Aber schreibt RfC wirklich festvor, das mehrerererere Zustellversuche
gemacht werdern MÜSSSEN?
Uwe Schröder
> Aber schreibt RfC wirklich festvor, das mehrerererere Zustellversuche
> gemacht werdern MÜSSSEN?
RFC 821 und 2821 sagen beide "the sender-SMTP is encouraged to try
again". Das ist noch nicht einmal ein SHOULD.
usch
christian mock
> Unangehm wird es aber, wenn der Empänger mehrer MXe hat,
> die alle Greylisten. Da ein "normaler" MTA (blöderweise?)
> die erneute Zustellung immer wieder bei der beim ersten mal
> ermittelten IP-# wieder holt, müssten die MXe keine gemeinsame
> Datenbank benutzen. Ein User hätte dann aber gute chancen
> ca. ((Anzahl MX/2)+1) versuche machen zu müssen...
in solchen situationen muss man das greylisting halt intellent
implementieren; ich hab letztens fuer einen kunden so ein design fuer
N (>1) MXe gemacht.
> Genau das ist natürlich das was die Spammersarsche machen werden:
> Die werden einfach alle eMails 2mal schicken.
[...]
> Greylist treibt den Teufel offenbar mit dem Belzelbub aus.
hast du da empirische daten? meine logs verraten mir zwar, dass manche
spammer offenbar bei _jeglichem_ 4xx oder 5xx einfach ueber den
naechsten proxy nochmal kommen, in der hoffnung, dass man es dann
annimmt, aber besondere mengen von mehrfach eingeliefertem spam sind
mir noch nicht aufgefallen.
ciao,
cm.
--
** christian mock in vienna, austria -- http://www.tahina.priv.at/~cm/
Vielleicht ist es aber auch nur einfach Zeit, dem Wolfi wieder den
root-Account wegzunehmen. Er ist noch zu klein dafuer.
Ferdinand Goldmann in at.gesellschaft.politik
Ralph Angenendt
Aber nur bei einem 4xx. Bei einem 5xx sollte einfach klar sein, dass da
nix ist.
Jost Krieger
Lies bitte noch mal den Abschnitt 4.5.4 von RFC 2821, insbesondere
> while mail that
> cannot be transmitted immediately MUST be queued and periodically
> retried by the sender
Irgendwo weiter unten steht übrigens auch:
> More significantly, 5yz
> responses to the MAIL command MUST NOT be cached.
Gruß Jost |8-))
Uwe Schröder
>> while mail that
>> cannot be transmitted immediately MUST be queued and periodically
>> retried by the sender
Wer ist der "Sender"? In dem Fall, daß der Mailprovider gar keinen
Smarthost betreibt, sondern lediglich einen SMTP-Proxy, der dem MUA das
Nachschlagen des zuständigen MX abnimmt, ist das wohl der MUA selber.
Oder würdest du SMTP-Proxies generell als RFC-widrig ansehen?
> Irgendwo weiter unten steht übrigens auch:
>
>> More significantly, 5yz
>> responses to the MAIL command MUST NOT be cached.
Ja, ich weiß. Das beantwortet aber immer noch nicht die Frage, ob ein
5yz als Antwort auf RCPT gecached werden darf oder sollte.
usch
Jost Krieger
> Jost Krieger wrote:
>
>
>>> while mail that
>>> cannot be transmitted immediately MUST be queued and periodically
>>> retried by the sender
>
>
> Wer ist der "Sender"? In dem Fall, daß der Mailprovider gar keinen
> Smarthost betreibt, sondern lediglich einen SMTP-Proxy, der dem MUA das
> Nachschlagen des zuständigen MX abnimmt, ist das wohl der MUA selber.
>
> Oder würdest du SMTP-Proxies generell als RFC-widrig ansehen?
Kurz gefasst, nicht konform. Der RFC beschreibt sie zumindest als
solche.
> SMTP clients that transfer all traffic, regardless of the
> target domain names associated with the individual messages, or that
> do not maintain queues for retrying message transmissions that
> initially cannot be completed, may otherwise conform to this
> specification but are not considered fully-capable. Fully-capable
> SMTP implementations, including the relays used by these less capable
...
Ein System, bestehend aus dummem MUA und dummen SMTP-Proxy, ist kein
vollwertiger Teilnehmer am SMTP-Mailverkehr. Zuschalten eines echten
MTAs repariert das. Anders ausgedrückt: Wenn so jemand sich als
"Mailprovider" bezeichnet, dürfte das UWG greifen (und
Schadenersatzansprüche auch). Wenn er dagegen nur genau sagt, was er
tut, sind seine Kunden eben die Dummen (vorher und nachher).
>>Irgendwo weiter unten steht übrigens auch:
>>
>>
>>> More significantly, 5yz
>>> responses to the MAIL command MUST NOT be cached.
>
>
> Ja, ich weiß. Das beantwortet aber immer noch nicht die Frage, ob ein
> 5yz als Antwort auf RCPT gecached werden darf oder sollte.
Ups. Lesen bildet, gründlich lesen bildet mehr :-;
Gruß Jost |8-))
Uwe Schröder
> Ein System, bestehend aus dummem MUA und dummen SMTP-Proxy, ist kein
> vollwertiger Teilnehmer am SMTP-Mailverkehr.
Die Intelligenz liegt in dem Fall nicht beim Proxy, sondern beim MUA. So
dumm sind die in der Regel nämlich gar nicht, schließlich sprechen sie
auch mit dem Smarthost SMTP und verwalten ihre eigene Queue.
> Zuschalten eines echten
> MTAs repariert das. Anders ausgedrückt: Wenn so jemand sich als
> "Mailprovider" bezeichnet, dürfte das UWG greifen (und
> Schadenersatzansprüche auch). Wenn er dagegen nur genau sagt, was er
> tut, sind seine Kunden eben die Dummen (vorher und nachher).
ACK. Also sind's jetzt die AGB, nicht die RFCs :)
usch
Bernd Hohmann
> Deswegen sprach ich ausdrücklich von 5.1.1 "Bad destination mailbox
> address" nach RFC 1893.
FYI: RFC1893 Enhanced Mail System Status Codes -> Obsoleted by RFC3463
Bernd
Bernd Hohmann
> | wvi.de.abuse.rfc-ignorant.org has address 127.0.0.4 Not supporting
> | postmaster
>
> Und wer keinen Postmaster Account hat, von dem nehme ich keine Mails an,
> ich haette ja bei Problemen nichtmal einen Ansprechpartner.
> set querytype=mx
> usenet.kicks-ass.org
Server: donald.harddiskcafe.de
Adresse: 80.242.134.170
usenet.kicks-ass.org
preference = 10, mail exchanger = debian.dyndns.org
--#--
C:\>telnet -p 25 debian.dyndns.org
220 debian.dyndns.org ESMTP Sun, 15 Aug 2004 03:34:37 +0200
helo world
250 debian.dyndns.org Hello p548151d0.dip.t-dialin.net [84.129.81.208]
mail from:<>
250 OK
rcpt to:<postm...@usenet.kicks-ass.org>
550 "Syntactically invalid argument! world"
rcpt to:<postm...@kicks-ass.org>
550 We do not relay
quit
--#--
Bernd
Rainer Zocholl
>Guido Hennecke wrote:
Ne, da fehlt:
rcpt to: <postmaster>
Und nur das MUSS gehen! (Wenn das Teil "rcpt to" akzeptiert.)
rcpt to: <postmaster@[84.129.81.208]>
sollte auch gehen.
Alles andere ist "Nice to have".
Bernd Hohmann
>>rcpt to:<postm...@usenet.kicks-ass.org>
>>550 "Syntactically invalid argument! world"
>>rcpt to:<postm...@kicks-ass.org>
>>550 We do not relay
>>quit
>
> Ne, da fehlt:
>
> rcpt to: <postmaster>
>
> Und nur das MUSS gehen! (Wenn das Teil "rcpt to" akzeptiert.)
Hm... Das ist aber etwas weltfremd. Wenn ich in meinem MUA "postmaster"
einhacke, dann geht das an den Postmaster des eingestellten SMTP (wobei
ich gerade sehe, dass ich das in meinem MTA mal wieder
kaputtprogrammiert habe).
Wie schicke ich aber eine Mail an den Postmaster eines fremden Systems?
RFC822:
6.3. RESERVED ADDRESS
It often is necessary to send mail to a site, without knowing any of its
valid addresses. [...] This standard specifies a single, reserved
mailbox address (local-part) which is to be valid at each site. Mail
sent to that address is to be routed to a person responsible for the
site's mail system or to a person with responsibility for general
site operation. The name of the reserved local-part address is:
"Postmaster" so that "Postmaster@domain" is
required to be valid.
Bernd
Bernd Hohmann
>> 220 debian.dyndns.org ESMTP Sun, 15 Aug 2004 03:34:37 +0200
>> helo world
>
> Was DU im HELO angibst, muss nicht aufloesen, aber es muss zum Beispiel
> einen Punkt enthalten.
>
>> 250 debian.dyndns.org Hello p548151d0.dip.t-dialin.net [84.129.81.208]
Wenn das Argument des HELO einen Punkt enthalten muss, warum antwortet
er mir mit "250 OK" und kommt erst nach dem RCPT TO mit einer Fehlermeldung?
Bernd
Ralf Döblitz
[...]
> rcpt to: <postmaster>
>
> Und nur das MUSS gehen! (Wenn das Teil "rcpt to" akzeptiert.)
IBTD. postmaster@domain muß für jede Domain, für die das System Mail
akzeptiert, funktionieren. D.h. praktisch, wenn die Kiste ein MX für
example.com ist, dann muß sie sowohl <postmaster> als auch
<postm...@example.com> akzeptieren.
> rcpt to: <postmaster@[84.129.81.208]>
>
> sollte auch gehen.
Das dagegen muß genau *nicht* gehen, zumindest nach RFC2821. Denn die
RHS soll ein FQDN sein, Domain Literals werden nur im HELO/EHLO erlaubt
(RFC2821, Abschnitt 3.6), obiges ist also laut RFC2821 keine gültige
Adresse.
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.
Bernd Hohmann
> IBTD. postmaster@domain muß für jede Domain, für die das System Mail
> akzeptiert, funktionieren. D.h. praktisch, wenn die Kiste ein MX für
> example.com ist, dann muß sie sowohl <postmaster> als auch
> <postm...@example.com> akzeptieren.
Dito "postm...@subdomain.domain.tld"
Sobald da "postmaster" vorne steht muss das akzeptiert werden - egal wie.
Bernd
Bernd Hohmann
> Dito "postm...@subdomain.domain.tld"
>
> Sobald da "postmaster" vorne steht muss das akzeptiert werden - egal wie.
Jetzt rede ich schon mit mir selber...
Was sollte eigentlich passieren, wenn eine Mail reinkommt an
"postm...@unbekannte-domain.tld"?
Annehmen und an den Postmaster weiterleiten oder ablehnen, weil die
Domain nicht lokal ist?
Bernd
Rainer Zocholl
>Rainer Zocholl wrote:
>>>rcpt to:<postm...@usenet.kicks-ass.org>
>>>550 "Syntactically invalid argument! world"
>>>rcpt to:<postm...@kicks-ass.org>
>>>550 We do not relay
>>>quit
>>
>> Ne, da fehlt:
>>
>> rcpt to: <postmaster>
>>
>> Und nur das MUSS gehen! (Wenn das Teil "rcpt to" akzeptiert.)
>Hm... Das ist aber etwas weltfremd.
Wieso?
>Wenn ich in meinem MUA "postmaster" einhacke, dann geht das
>an den Postmaster des eingestellten SMTP
Ja.
>(wobei ich gerade sehe,
>dass ich das in meinem MTA mal wieder kaputtprogrammiert habe).
Das "gelingt" nicht nur Dir ;-)
>Wie schicke ich aber eine Mail an den Postmaster
>eines fremden Systems?
Das wird der besagte <postmaster> schon einrichten,
wenn sein Postfach vollläuft...
>RFC822:
>6.3. RESERVED ADDRESS
~~~~~~~~
>It often is necessary to send mail to a site, without knowing any of
>its valid addresses. [...] This standard specifies a single, reserved
>mailbox address (local-part) which is to be valid at each site. Mail
>sent to that address is to be routed to a person responsible for the
> site's mail system or to a person with responsibility for general
>site operation. The name of the reserved local-part address is:
>"Postmaster" so that "Postmaster@domain" is
>required to be valid.
Ist aber nicht mal ein "SHOULD"...
Ist auch nicht der RfC den ich meine.
Bernd Hohmann
>>RFC822:
>
>>6.3. RESERVED ADDRESS
> ~~~~~~~~
[...]
> Ist aber nicht mal ein "SHOULD"...
"which is to be valid at each site."
Bernd
Rainer Zocholl
>Rainer Zocholl <UseNet-Posting...@zocki.toppoint.de> wrote:
>[...]
>> rcpt to: <postmaster@[84.129.81.208]>
>>
>> sollte auch gehen.
>Das dagegen muß genau *nicht* gehen, zumindest nach RFC2821. Denn die
>RHS soll ein FQDN sein, Domain Literals werden nur im HELO/EHLO
>erlaubt (RFC2821, Abschnitt 3.6), obiges ist also laut RFC2821 keine
>gültige Adresse.
Das macht aber nix...denn manche Blacklist betreiber versenden
ihre Listungswarnung an diese Adresse.
Es stehen einmal natürlich frei solche emails abzulehenen,
auch wenn vorne "postmaster" stht und abzuwarten bis man
gelistet wird.
Dsa Problem bei "open relays" ist ja z.B. das u.U. die
"zuständige" FQDN garnicht einfach zu bestimmen ist.
Undi ein einsames "<postmaster>" werden die wenigsten MUA richtig zustellen.
Bei <postmaster@[84.129.81.208]> wird das eher klappen,
allerdings wird er MUA dann u.U. "vergessen" das "@[84.129.81.208]"
zu entfernen.
Da es für den MTA kein aufwand bedeutet, warum sollte er
diese Adresse -bei postmaster- nicht akzeptieren?
Bernd Hohmann
> Undi ein einsames "<postmaster>" werden die wenigsten MUA richtig zustellen.
> Bei <postmaster@[84.129.81.208]> wird das eher klappen,
> allerdings wird er MUA dann u.U. "vergessen" das "@[84.129.81.208]"
> zu entfernen.
> Da es für den MTA kein aufwand bedeutet, warum sollte er
> diese Adresse -bei postmaster- nicht akzeptieren?
Weil Du oben geschrieben hast "rcpt to: <postmaster@[84.129.81.208]>" -
und dann ist es doch Sache des MTA ;-)
Bernd
Bernd Hohmann
>>>> 250 debian.dyndns.org Hello p548151d0.dip.t-dialin.net [84.129.81.208]
>> Wenn das Argument des HELO einen Punkt enthalten muss, warum antwortet
>> er mir mit "250 OK" und kommt erst nach dem RCPT TO mit einer Fehlermeldung?
>
> Weil das da oben das SMTP Banner ist und nicht das Helo, welches DU
> uebergeben hast:
[...]
> Bist Du sicher, dass Du weisst, wovon Du sprichst?
220 debian.dyndns.org ESMTP Mon, 16 Aug 2004 01:09:51 +0200
helo world
250 debian.dyndns.org Hello pd9e9f814.dip.t-dialin.net [217.233.248.20]
mail from:<>
250 OK
rcpt to:<postm...@debian.dyndns.org>
550 "Syntactically invalid argument! world"
Ich verstehe immer noch nicht, was Dein System da macht.
Und wenn ich mir Deine arrogant-planlosen Antworten hier durchlese: es
interessiert mich auch nicht mehr.
-r
Ralph Angenendt
> helo world
> Ich verstehe immer noch nicht, was Dein System da macht.
>
> Und wenn ich mir Deine arrogant-planlosen Antworten hier durchlese: es
> interessiert mich auch nicht mehr.
Es lehnt HELOs ab, die syntaktisch nicht korrekt sind. Warum es das erst
nach dem RCPT TO macht, weiß ich allerdings auch nicht.
Bernd Hohmann
> Weil ich das in der entsprechenden ACL mache, die erst nach dem RCTP TO
> greift. Das hat den Sinn, dass ich unabhaengig vom HELO bestimmte Mails
> anhand MAIL FROM und/oder RCPT TO trotz defektem HELO durchlassen kann.
Jeder Admin liebt es neben den Pseudo-X400 Bounces von MS-Exchange
Systemen noch aus den Logfiles herauszufinden warum das "rcpt to" bei
Dir noch Auswirkungen vom Helo herumschleppt.
Bringe Deiner Alchemistenküche auf Urlaubsreise bitte aussagekräftige
Fehlermeldungen bei.
Bernd
Uwe Schröder
> Es lehnt HELOs ab, die syntaktisch nicht korrekt sind.
Syntaktisch korrekt ist es; "world" ist ein gültiger Domainname. Nur
eben nicht "fully qualified".
> Warum es das erst
> nach dem RCPT TO macht, weiß ich allerdings auch nicht.
Möglicherweise weil RFC 1123 es ausdrücklich verbietet, den Hostnamen
als Ablehnungsgrund zu nehmen. IMHO bleibt es aber auch dann ein
RFC-Verstoß, wenn die Ablehnung erst drei Zeilen später passiert.
| However, the receiver MUST NOT refuse to accept a message, even if the
| sender's HELO command fails verification.
Da steht "MUST NOT refuse to accept a message", das ist nicht auf die
unmittelbare Antwort auf das HELO beschränkt.
usch
Uwe Schröder
> Was an "Das Helo muss mindestens einen Punkt enthalten" hast DU nicht
> verstanden?
Was an RFC 1123
| the receiver MUST NOT refuse to accept a message, even if the
| sender's HELO command fails verification.
hast DU nicht verstanden?
usch
Bernd Hohmann
>> Warum es das erst
>> nach dem RCPT TO macht, weiß ich allerdings auch nicht.
>
> Möglicherweise weil RFC 1123 es ausdrücklich verbietet, den Hostnamen
> als Ablehnungsgrund zu nehmen. IMHO bleibt es aber auch dann ein
> RFC-Verstoß, wenn die Ablehnung erst drei Zeilen später passiert.
>
> | However, the receiver MUST NOT refuse to accept a message, even if the
> | sender's HELO command fails verification.
>
> Da steht "MUST NOT refuse to accept a message", das ist nicht auf die
> unmittelbare Antwort auf das HELO beschränkt.
Da steht aber auch
"Note also that the HELO argument is still required to have valid
<domain> syntax, since it will appear in a Received: line; otherwise, a
501 error is to be sent."
Was ich in der Summe interpretiere: im Helo muss was stehen, was nach
<domain> aussieht. Ist es nicht <domain>, mache einen 501. Ist es aber
<domain> und der Lookup schlägt fehl, nimm die Mail trotzdem an.
Denn sie wissen nicht, was sie tun ;-)
Egal - es macht trotzdem wenig Sinn, Fehlerort und Fehlermeldung in
einem Dialogprotokoll wie SMTP auseinanderzureissen.
Bernd
Uwe Schröder
>>Syntaktisch korrekt ist es; "world" ist ein gültiger Domainname. Nur
>>eben nicht "fully qualified".
>
> Nein, syntaktisch korrekt waere, wenn er einen Punkt enthaelt.
Nein. Ich zitiere RFC 821:
HELO <SP> <domain> <CRLF>
<domain> ::= <element> | <element> "." <domain>
Beachte, daß <element> auch ausdrücklich alleine stehen darf, ohne einen
Punkt.
<element> ::= <name> | "#" <number> | "[" <dotnum> "]"
<name> ::= <a> <ldh-str> <let-dig>
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <a> | <d> | "-"
<let-dig> ::= <a> | <d>
<a> ::= any one of the 52 alphabetic characters A through Z
in upper case and a through z in lower case
<d> ::= any one of the ten digits 0 through 9
Und <element> selber kann ausdrücklich keinen Punkt enthalten.
Das ist die Syntax. Ein syntaktisch falsches HELO lehnst du ja auch
korrekterweise unmittelbar mit einem 501 ab.
"HELO world" nimmst du aber erst einmal an, also akzeptierst du es
durchaus als _syntaktisch_ korrekt.
> Aber gelesen hast Du sicher auch:
>
> ,----[ RFC 1123 ]
> | Note also that the HELO argument is still required to have valid <domain>
> | syntax, since it will appear in a Received: line; otherwise, a 501 error
> | is to be sent.
> `----
Eben, da steht nichts von "FQDN", da steht nur "valid <domain> syntax",
und <domain> kann laut der BNF-Definition in RFC 821 auch ein partieller
Domainname sein.
usch
Uwe Schröder
> | Note also that the HELO argument is still required to have valid
> | <domain> syntax,
Antwort in <41208C41...@office-1.ohrbelag.de>.
usch
Uwe Schröder
> "Note also that the HELO argument is still required to have valid
> <domain> syntax,
Siehe <41208C41...@office-1.ohrbelag.de>.
usch
Uwe Schröder
> | Note also that the HELO argument is still required to have valid
> | <domain> syntax,
Antwort in <41208C41...@office-1.ohrbelag.de>.
> Das was mit "verification" gemeint ist, ist eine Namensaufloesung. Die
> findet hier nicht statt.
Also noch schlimmer. Du lehnst ein syntaktisch korrektes HELO ohne jede
nähere Überprüfung ab :)
usch
Florian Weimer
> Wenn das Argument des HELO einen Punkt enthalten muss, warum antwortet
> er mir mit "250 OK" und kommt erst nach dem RCPT TO mit einer
> Fehlermeldung?
Viele meisten MTAs beginnen, sich seltsam zu verhalten, wenn sie beim
HELO abgewiesen werden.
Bernd Hohmann
Ach herrje... Na, mir ist es eh Wurst weil bei mir ein eingehendes HELO
immer mit 2xx OK beantwortet wird.
Bernd
Uwe Schröder
> Eine Domain ausserhalb meiner Domain kann ohne einen Punkt nicht korrekt
> sein.
Das ist falsch. "localhost" ist beispielsweise ein völlig korrekter
_fully_ qualified domain name, denn "localhost" ist eine gültige TLD
gemäß RFC 2606.
> Korrekt waere das, wenn ein System innerhalb meiner Domain sich
> nur mit dem Element ohne ".domain" meldet.
Das wiederum wäre zwar syntaktisch korrekt, aber trotzdem ein
RFC-Verstoß auf Seiten des Absenders, denn im HELO sind nur FQDNs
zugelassen.
> Ja, kann. Wenn es innerhalb meiner Domain ist, kann ich alles ausser dem
> Element weglassen.
Wie gesagt: Generell schon, im HELO aber ausdrücklich nicht. Auch nicht
bei Mails, die du selber innerhalb deiner eigenen Domain versendest.
>>"HELO world" nimmst du aber erst einmal an, also akzeptierst du es
>>durchaus als _syntaktisch_ korrekt.
>
> Nope.
Doch. Wenn es _syntaktisch_ falsch wäre, hättest du umgehend mit 501
antworten müssen.
> Ich entscheide allerdings erst nach dem RCPT TO ob ich wirklich ablehne.
Das ist wie gesagt ein Verstoß gegen RFC 1123. Du kannst an dich
adressierte Mails natürlich aufgrund eines dir nicht genehmen HELO oder
beliebiger anderer Kriterien ungelesen verwerfen, aber im SMTP-Dialog
_ablehnen_ darfst du sie aufgrund des HELO nicht.
> Na dann gib in deinem Browser mal "http://www/" ein und schaue, ob DU
> damit auf Heise kommst.
Abgesehen davon, daß das Beispiel Unsinn ist, reden wir hier von SMTP
und nicht von HTTP.
> Um dir zu erklaeren, warum ich HELO erst nach dem RCPT TO per ACL
> pruefe: Ich habe eine Whitelist, in der Absenderadressen stehen, und
> eine Spamsenke, die alles fressen soll und noch ein paar andere
> Kleinigkeiten, die trotz "HELO world" annehmen sollen.
Das ist mir schon klar. RFC-konform ist es genau genommen trotzdem nicht.
usch
Uwe Schröder
> Ach herrje... Na, mir ist es eh Wurst weil bei mir ein eingehendes HELO
> immer mit 2xx OK beantwortet wird.
Das ist aber auch nicht richtig. Ein "HELO /(%§/&/&)()" solltest du
schon mit 501 beantworten. Spätestens wenn du eine solche Mail an
Spamcop weiterleitest und im Header steht "Received from /(%§/&/&)()",
gibt es Senge.
usch
Bernd Hohmann
>> Doch. Wenn es _syntaktisch_ falsch wäre, hättest du umgehend mit 501
>> antworten müssen.
>
> Wo steht denn, wann ich antworten muss?
Ergibt sich aus RFC821 (4.2 SMTP REPLIES, 4.3. SEQUENCING OF COMMANDS
AND REPLIES).
Ok, es ist nirgends explizit erwähnt dass die Antwort im Kontext zum
Kommando stehen muss. Im Prinzip kannst Du also das DATA mit "5xx User
unknown" beantworten.
Bernd
Ralf Döblitz
> * Bernd Hohmann <hoh...@harddiskcafe.de> wrote:
>> Guido Hennecke wrote:
>>> Weil ich das in der entsprechenden ACL mache, die erst nach dem RCTP TO
>>> greift. Das hat den Sinn, dass ich unabhaengig vom HELO bestimmte Mails
>>> anhand MAIL FROM und/oder RCPT TO trotz defektem HELO durchlassen kann.
>> Jeder Admin liebt es neben den Pseudo-X400 Bounces von MS-Exchange
>> Systemen noch aus den Logfiles herauszufinden warum das "rcpt to" bei
>> Dir noch Auswirkungen vom Helo herumschleppt.
>
>
> 550 "Syntactically invalid argument! $DAS_HELO"
>
> Ein Admin der das nicht versteht...
... verzichtet dann auf Kommunikation mit dir.
HELO/EHLO ist entweder zu akzeptieren oder wegen syntaktischer Fehler zu
bemängeln. Letzteres aber als Antwort auf eben diesen Befehl und zwar
mit dem vorgeschriebenen Return Code 501.
Wenn du kein (E)SMTP sprechen willst, dann laß es. Und zwar am besten
grundsätzlich. Mach den Port einfach zu.
Ralf
--
Ralf Döblitz * Schapenstraße 6 * 38104 Braunschweig * Germany
Phone: +49-531-2361223 Fax: +49-531-2361224 mailto:doeb...@doeblitz.net
Homepage: http://www.escape.de/users/selene/
Mit UTF-8 kann man gleichzeitig äöüßÄÖÜæœłø¼½¾¤¹²³¢€£¥¶§¬÷×±©®™¡¿ verwenden.
Ralf Döblitz
[...]
> Aber gelesen hast Du sicher auch:
>
> ,----[ RFC 1123 ]
> | is to be sent.
^^^^^^^^^^^^^
> `----
>
> Ich pruefe nur, ob der HELO syntaktisch korrekt ist, ein "HELO ,.-"
> waere das auch nicht und wird auch abgelehnt. Ich pruefe _NICHT_, ob der
> im HELO angegebene FQDN ueberhaupt zu irgendwas aufloest.
Und was an dem oben unterstrichenen Satz hast du nicht verstanden?
Ralf Döblitz
[...]
> Dito "postm...@subdomain.domain.tld"
>
> Sobald da "postmaster" vorne steht muss das akzeptiert werden - egal wie.
Nö. Nur für Domains, die am Mailverkehr teilnehmen und für die man MX
ist. Alles andere kann man problemlos rejecten.
Bernd Hohmann
>> Ach herrje... Na, mir ist es eh Wurst weil bei mir ein eingehendes HELO
>> immer mit 2xx OK beantwortet wird.
>
> Darueber lohnt es sich, nachzudenken.
>
> Viele Mailwuermer melden sich mit dem Windows Rechnernamen (OEMCOMPUTER,
> PC1, HORST und dergleichen) oder mit der Zieldomain als HELO.
>
> Darauf zu filtern schafft ne Menge Dreck ganz billig weg.
Ich habe eben mal quer durch den Spamfolder geschaut: die HELOs waren
alle harmlos.
Wobei von den ca. 15.000 Zustellversuchen in den letzten 20 Stunden nur
ca. 900 überhaupt ein "2xx Hi there" statt "5xx Connection refused" mit
.flush() & .close() gesehen haben.
Den Rest erledigt ein grober Bayes der wieder die systemeigene Blacklist
füttert auf die der SMTP sowie auch der Bayes zugreift (um auch
Fetchmail zu filtern).
Ist wesentlich einfacher zu konfigurieren weil alles am Bayes
festgemacht wird und vorallem auch POP3-Fetchmail mit erschlägt (was ich
brauche, um die unzähligen alt-accounts meiner Klientel zu konsolidieren).
Bernd
Bernd Hohmann
>> Sobald da "postmaster" vorne steht muss das akzeptiert werden - egal wie.
>
> Nö. Nur für Domains, die am Mailverkehr teilnehmen und für die man MX
> ist. Alles andere kann man problemlos rejecten.
Ok, ich baue es nochmal um.
Bernd
Bernd Hohmann
> Genauer gesagt nennt man Systeme, die alle Mails, in denen postmaster
> vorne dran steht, annehmen und dann ggf. relayen auch "halboffene
> Relays" und solche landen schnell auf diversen Blacklists.
Irgendwie habe ich den Verdacht, dass Du etwas zu selektiv liest.
Meine Idee war "ganz streng genommen müsste man alles, was vorne
Postmaster, heisst annehmen".
Aber da stand NIE was von "das muss ich auch weiter relayen".
Bernd
Bernd Hohmann
> | test
> | .
> | 250 OK DATA Mail received
> | quit
> | 221 OK donald.harddiskcafe.de says goodbye
> | Connection closed by foreign host.
> `----
>
> Oh Gott, oh Gott, oh Gott! Ja, bitte bau das schnell um!
>
> Bisher wurde das zwar nicht zu mir relayt, aber warum nimmst Du das
> ueberhaupt an? Was macht Dein System nun mit der Mail, die nicht fuer
> dich bestimmt war? Wegschmeissen? Bouncen? Relayen?
Es gibt noch eine vierte Alternative: Sie wurde ordnungsgemäss dem
Postmaster des Systems donald.harddiskcafe.de zugestellt.
Bernd
Bernd Hohmann
> Und irgendwie finde ich es ueberhaupt befremdlich, dass Du Mails
> annimmst, die an eine Domain gerichtet sind, fuer die Du nicht MX bist.
Ich befürchte, dass Dir der Node "reserved account 'postmaster'" etwas
abhanden gekommen ist.
Bernd
Bernd Hohmann
>> Es gibt noch eine vierte Alternative: Sie wurde ordnungsgemäss dem
>> Postmaster des Systems donald.harddiskcafe.de zugestellt.
>
> Mit "ordnungsgemäss" hat das nichts zu tun, denn fuer den war sie nicht
> bestimmt.
>
> Ist das schon Datenunterdrueckung?
Wieso? Die Mail wurde an den reservierten Account "postmaster" gerichtet
und erstmal dem Postmaster meines Systems reingekübelt.
Der hat sich den Header angeschaut und festgestellt, dass das hier nix
zu suchen hat und daher den Absender angeschrieben diesen Irrläufer mal
zu prüfen. Der Absender hat mir in der zwischenzeit geschrieben, dass es
den Absender aber eigentlich nicht gibt :->
Wenn ich Laune habe (bzw. mein Weib keine Laune hat ;-)) gehe ich
nachher nochmal durch den Source und sorge dafür, dass auch nochmal der
Domainpart geprüft wird.
Da ich aber bei den letzten 3-4mio Mails noch nie diese Situation hatte,
ist es nicht so eilig dass ich heute nacht den MTA neu starten muss für
ein Update.
Bernd
Bernd Hohmann
> Aeh, Du hast immer noch nicht verstanden, dass es nicht fein ist, Mails
> fuer fremde Domains anzunehmen? Ja, das gilt auch fuer postmaster,
> abuse, hostmaster und so weiter.
Nun - wenn der MTA des Absenders der Meinung ist, dass er mir das
unbedingt reindrücken muss: die Fehlkonfiguration liegt jedenfalls nicht
bei mir.
Abuse, Hostmaster sind meines Wissens keine reservierten Namen sondern
nur "die sollten da sein".
Bernd