🚀 go-pugleaf

Peter Gruendler wrote:

> 
> Nun verwendet inode im rahmen seiner anti-spam-policy externe
> blacklists. Auf einer von diesen Listen scheint seit l�ngerem
> ndmail4.name-serve.de auf, der von netdiscounter verwendet wird. Das
> f�hrt dazu, dass ich von meinem mailservice- und hostingprovider aus
> keine mails an meinen Zugangsprovider (und schlimmer: an dessen
> Kunden) schicken kann. L�stig und weil das einer der gr��eren
> Zugangsprovider in AT ist, auch ung�nstig f�r mein Gesch�ft.
> 

dieses blacklistfeature kann man im mailadmin-webinterface f�r jeden 
account deaktivieren, was dein problem sehr einfach l�sen k�nnte ;)
Das Codewort heisst "RBL aktivieren" 


peter


-- 
peter pilsl
pilsl_@goldfisch.at
http://www.goldfisch.at

Peter Gruendler wrote:

> Kann mir jemand einen Rat geben, wie ich sinnvoll und mit m�glichst
> wenig Aufwand vorgehen soll/kann? Eigentlich war ich mit beiden
> Dienstanbietern bisher im Gro�en und Ganzen zufrieden.

wir hatten mal ein sehr �hnliches problem. wir haben mit einem server
eine ip bekommen, die vorher ein spammer benutzt hat. daher waren wir
auch bei spews.org eingetragen. ich bin auch inode kunde - so ists mir
ebenfalls als erster aufgefallen.

geholfen hat ein posting in news.admin.net-abuse.email
die leute dort sind durchaus hilfsbereit, wenn es um die kl�rung der
genauen ursache geht. zudem verkehren in dieser gruppe auch leute von
spews und osirusoft. innerhalb von ein paar tagen waren wir dann
draussen.

-- 
best regards,
michael roedhamer
"geplante zukunft - solider background"

Hej!

>Nun verwendet inode im rahmen seiner anti-spam-policy externe
>blacklists. Auf einer von diesen Listen scheint seit l�ngerem

Ich setze genau aus diesem Grund keine Blacklisten zum Blocken ein. 
Ich bin mir auch mit Kollegen einig, dass, wenn wir so ein Service 
installieren, dieses nur auf individuellen ausdruecklichen Wunsch 
(kundgetan via Webmaske) nach Hinweis auf die Nebenwirkungen 
geschehen soll - in der Zwischenzeit wird nur eine Header-Zeile
eingefuegt.

>| Server m�glich. Dies ist eine Schutzma�nahme, die nicht nur Inode Mailserver
>| sondern auch andere Provider haben. Aus diesem Grund bitte ich Sie, Ihren 

Und darueber, ob das gescheit ist, oder nicht, kann man sich ewig die
Schaedel einhauen. YMMV sozusagen.

>| Zu diesen Organisationen (abuse.net und wie sie alle heissen) kann ich nur

Das ist ein Griff tief ins Klo. Abuse.net betreibt keine RBL, sondern
eine Datenbank, um domain -> abuse-Adresse zu mappen. Ein ausgesprochen
nuetzliches Service, das aber mit Blacklists rein gar nichts zu tun hat.

Ein umfassendes Verzeichnis von RBLs gibt es unter:

http://www.declude.com/JunkMail/Support/ip4r.htm

>| wiederholt sagen: Wir k�nnen nicht verhindern, dass wir durch wen auch immer
>| das eine oder andere Mal dort gelistet sind - in aller Regel sind wir dann

Tatsache ist, dass man in groesseren Netzen schneller geblacklistet 
wird, als auf den ersten Blick anzunehmen ist. Es reicht ein User, der
ein ungeschuetztes formmail.cgi auf seinen Webspace wirft, oder einer, 
der auf seinem prinzipiell relayberechtigten Rechner mal gschwind ein
offenes Wingate installiert...

>| nicht an jemanden schicken kann, weil der eine Blacklist einsetzt, auf der
>| einer unserer Mailserver gelistet ist, dann soll er den doch einfach fragen,
>| mit welchem Recht er denn das macht und damit verhindert, dass er seine

Das Recht ist aus der Sicht des Absenders leicht zu klaeren: Es ist 
niemand gezwungen, Mail von irgendjemandem anzunehmen. Wenn ich auf 
meinem Mailserver konfiguriere, dass ich von Hosts, deren IP-Adresse
durch 3 Teilbar ist oder die in ihrem Namen nicht mindestens drei 
"at" drin haben, keine Mail entgegennehme, dann ist das mein Bier.

Die Frage ist, ob "meine" oder in dem Fall Inodes User damit 
einverstanden sind. Nachdem, soweit ich das verstehe, diese freiwillig
die Blacklisterei nutzen, ist es deren - wenn auch mittelbare - 
Willenserklaerung, von Dir keine Mail zu empfangen.

>| �ber diesen Mailserver verschickt hat bzw. diesen Povider auffordern,
>| derartige Zensuren zuk�nftig zu unterlassen. Genauso gut kann ich auch

Da hat jemand keine Ahnung, was Zensur heisst, mal abgesehen davon, 
dass diese Filterfunktion offenbar bei Inode frei waehlbar ist.

>Ich komme mir hier richtig zwischen die Fronten geraten vor, da ich
>beides nicht direkt beeinflussen kann, einerseits ich au�er von inode

Das ist das ausdrueckliche Konzept vieler Blacklistbefuerworter: Die 
Kunden geblacklisteter Provider sollen sich a) beschweren und b)
Provider wechseln, damit auf diese Weise Druck auf die verantwortlichen
Admins ausgeuebt wird. Wenn legitime Mail deshalb nicht ankommt, ist das 
Kollateralschaden - vulgo Pech gehabt. 

Es funktioniert aber nichtmal diese Brachialmethode so wirklich
generalpraeventiv. Ein merkbarer Erfolg fuer den individuellen
Spam-Nichtempfaenger ist aber absolut gegeben.

>Kann mir jemand einen Rat geben, wie ich sinnvoll und mit m�glichst
>wenig Aufwand vorgehen soll/kann? Eigentlich war ich mit beiden

http://relays.osirusoft.com/faq.html#_Toc533558155

Ich weiss nicht, ob wirklich osirusoft die verwendet Blackliste ist
und warum die Austragung nicht funktioniert hat. Nach dem Schnitzer
von abuse.net nehme ich fast an, netdiscounter hat doch nicht so 
sehr den vollen Durchblick. Mir sind jedenfalls osirusoft bisher
nicht als Produzenten von massenhaft fehlerhaft positiv markiertem
Spam aufgefallen, was bei notorisch nichtfunktionierendem Austragen
geschlossener Relays aber der Fall sein muesste.

Ciao

  Alexander, der RBLs sehr skeptisch gegenuebersteht.

Dazu, was Peter Gruendler meinte, muss ich auch meinen Senf geben:

>ich hoste einige domains auch bei anderen providern

und was spricht dagegen, den smtp-Server vom anderen Provider zu
verwenden? Wenn ich mit einem Provider seinem SMTP-Server ein Problem
habe, benutze ich halt einen anderen und wenn ich mehrere zur Auswahl
habe, um so besser. Eine E-Mail Adresse sollte nichts mit dem
verwendeten SMTP Server zu tun haben.

Claus

Claus Lenke <noreply@peek.de> schrieb:

>Peter Gruendler meinte:
>>ich hoste einige domains auch bei anderen providern
>
>und was spricht dagegen, den smtp-Server vom anderen Provider zu
>verwenden? Wenn ich mit einem Provider seinem SMTP-Server ein Problem
>habe, benutze ich halt einen anderen und wenn ich mehrere zur Auswahl
>habe, um so besser. Eine E-Mail Adresse sollte nichts mit dem
>verwendeten SMTP Server zu tun haben.

Erstens: kann man als Serverbetreiber wohl so konfigurieren, dass die
Adresse im from: aus dem eigenen Namensraum sein muss.

Und dann: es geht der Gro�teil unseres Mailtraffics �ber die bei
netdiscounter gehostete domain. Warum sollte ich das anderen
Betreibern zumuten? W�rde ich unfair finden.


Gru�,
daPeda

Hej!

Claus Lenke <noreply@peek.de> wrote:

>und was spricht dagegen, den smtp-Server vom anderen Provider zu
>verwenden? Wenn ich mit einem Provider seinem SMTP-Server ein Problem

(Mal angenommen, es gibt hier kein Problem mit offenen Relays)

Darunter leiden Postmaster und Zuverlaessigkeit des Mediums eMail. Das
geht so:

From: bumsti@hotmail.com
To: wopsi@hotmail.com
Subject: Warum Frauen die schlechteren Autofahrer sind

Halo Wopsi, des must da gebn, a waunsinn!

Attachment: 12MB Powerpoint

Das wird abgeliefert bei mail.andererprovid.er. Dieser schickts an 
Hotmail - hotmail sagt: "Quota exceeded und ueberhaupt, so lange mail
nehmen wir eh prinzipiell nicht". Na gut, geht der Bounce an den 
Absender. Der ist auch bei hotmail, also schicken wir ihn an hotmail. 
Dieser sagt nun ebenfalls. "Quota exceeded und ueberhaupt". Die Mail 
landet mangels anderer Alternativen als Doublebounce beim Postmaster 
von andererprovid.er.

Das ist aber nicht genug. Weil wopsi per sms meldet, dass die mail nicht
angekommen ist, schickt bumsti sie noch einmal, zweimal, ...

Wopsi bekommt nie eine Fehlermeldung, weil er eine Mail verschickt hat,
die er ueber den "richtigen" provider nie haetter verschicken koennen.
Bei email kann man sich aber, von so gearteten Ungustigkeiten, darauf
verlassen, dass mail entweder ankommt, oder eine Fehlermeldung 
zurueckgeschickt wird. Die zweite Kategorie von solchen Mailvernichtern
sind die, die keine Mail mit leerem Reverse Path entgegennehmen 
("<> buildaddr no host - bogus address refused to combat the spam
problem" ... ein deutlicher Hinweis auf die totale Inkompetenz des
Postmasters und gleichzeitig die Einladung zur Nominierung bei 
http://www.rfc-ignorant.org/) - weil so schauen ausser bei hinnicher
Software genau die Fehlermeldungen aus.

Und dann befinden bumsti und wopsi noch, dass der mailserver von 
andererprovid.er nicht gut funktioniert, weil ja die mail nicht 
durchgeht, wenn sie ueber andererprovid.er geroutet wird.

Es spricht also schon einiges dafuer, wenn jeder bei "seinem" Server
Mail verschickt. 

Ciao

  Alexander

On 30 Jun 2002 09:01:59 GMT, Alexander Talos wrote:
> Claus Lenke <noreply@peek.de> wrote:
>>und was spricht dagegen, den smtp-Server vom anderen Provider zu
>>verwenden? Wenn ich mit einem Provider seinem SMTP-Server ein Problem
> Darunter leiden Postmaster und Zuverlaessigkeit des Mediums eMail. Das
> geht so:
[...]
> Attachment: 12MB Powerpoint
> 
> Das wird abgeliefert bei mail.andererprovid.er. Dieser schickts an 
> Hotmail - hotmail sagt: "Quota exceeded und ueberhaupt, so lange mail
> nehmen wir eh prinzipiell nicht". Na gut, geht der Bounce an den 
> Absender. Der ist auch bei hotmail, also schicken wir ihn an hotmail.

Aber ist hier nicht das eigentliche Problem, dass die ganzen 12 MB gebounced
werden? Sollten solche Bounces nicht sowieso auf einige kB beschraenkt
werden, damit solche Probleme nicht auftreten koennen?


bye, Christof

-- 
http://cmeerw.org                                 JID: cmeerw@jabber.at
mailto cmeerw at web.de

...and what have you contributed to the Net?

Hej!

Christof Meerwald <NOSPAM-seeMySig+ub8l@cmeerw.org> wrote:

>Aber ist hier nicht das eigentliche Problem, dass die ganzen 12 MB gebounced
>werden? 

Das halte ich fuer eine interessante Frage. 

* Mit einfachem Abschneiden nach n KB ists auf jeden Fall nicht getan, 
weil damit die MIME-Struktur (so vorhanden) kaputtgeht. 

* Wenn ich per Post einen Computer verschicke, mich aber bei der Adresse 
verschreibe, dann erwarte ich auch den ganzen Computer zurueckzubekommen
und nicht bloss das Floppy Drive. Bekanntlich ist nicht alles, was hinkt,
ein Vergleich und manchmal stimmt schon nichtmal das Gegenteil, aber die
Analogie wurde traditionell gemacht: Wenn's nicht ankommt, bekomme ich
es zurueck. 

Die diversen "freundlichen" Fehlermeldungen "Ihre Mail an JHKJHK/EXC 
konnte nicht zugestellt werden, weil der interne Konnektor ein illegales 
Ergebnis lieferte." - ohne Subject, ohne Header, ohne Message-ID, ohne 
Hinweis, wer der Empfaenger haette sein sollen - sind das andere Extrem.

Einen sinnvollen Mittelweg zu finden, wird fuer den allgemeinen Fall 
nicht so einfach sein. Spaetestens dann, wenn ich ein Base64-Monster
daherbekomme, ist der fachgerechte Schnitt schwer hinzubekommen und
setzt sehr viel Wissen ueber alle moeglichen Spielarten von Mail voraus.

* Der MTA (Mail Transfer Agent) hat den Inhalt der Mail nicht anzuschauen,
zu bearbeiten oder sonstwas. Waer ja zu bloed, wenn der Bounce nicht 
ankommt, bloss weil der Bounce-Beschnipsler bei einem nicht 
vorhergesehenen zEnc-Attachment in UTF-9 auf die Nase geflogen ist und 
core gedumpt hat.

* Was eigentlich soll weggeworfen werden bzw. nach welchen Kriterien?
Der von mir geschilderte Fall von einem multipart 
1. text/plain "Schau Dir das an" 
2. text/html "<HEAD><TITLE>Eine Nachricht fur Dich</TITLE>
 <META bli><CREATOR Mickeysoft WonderMailer></HEAD><BODY [weitere
 20kB HTML-Schrott snipped]<FONT COLOR=blue>Schau </FONT><FONT 
 COLOR="#323232" BORDER=greenblinkend>Dir das an</FONT>[nochmal 
 20KB HTML-Schrott]" 
3. application/x-hippes-multimediales-bloedelformat "[Gaanz luuustiges
 Zeugs]"
Ist ja noch einfach, aber schwer zu verallgemeinern. Manche Mailer, deren
Name hier mal nicht genannt sei, bringen ja schon einmal keine richtigen
MIME-Parts zusammen. Wenn aber mehrstufige Hierarchien bestehend aus 
vielen Einzelteilen (z.B. eine HTML-Mail mit vielen Bildern, Sound, 
Flash, die auch gleich in der selben Entity eingebettet sind) auftauchen,
wird's schon schwerer.

Ich bin unschluessig, ob man das wirklich probieren sollte, Bounces Light
zu versenden. Simpel ist es jedenfalls sicher nicht, sich da was solides
einfallen zu lassen - und gerade die Fehlerbehandlung sollte doch simpel
und sehr robust sein.

Was diverse Virenscanner, die ja hinsichtlich der Verstaendigung der 
Absender in eine aehnliche Kategorie fallen, so produzieren, klingt 
jedenfalls nicht feierlich:

* Mail to: Mailer-Daemon (jedes Vacation weiss, dass man an 
Mailer-Daemon, owner-* etc nicht antwortet)

* Antwort (DSN) auf die From:-Adresse statt auf Reverse-Path ist eine
Idee, auf die nur blutige Anfaenger kommen duerften

* Autogenerierte Mail in Reaktion auf eine Mail mit leerem Reverse-Path

* Keine sinnvollen Angaben, welche Mail einen Virus enthalten hat
("Your message to xxx" - oft ohne Subject, kaum je mit Headern)

* Ungueltige Absenderadresse (z.B. "From: Antigen" - fully qualified
Address - was ist das?) 

* Ausserdem ist es ohnehin eine Schnapsidee, ausser bei ausgewaehlten 
Viren wie dem SirCam, dem angeblichen Absender eine Verstaendigung zu 
schicken: grad bei den aktuellen Klez und Yaha steht da ja alles 
moegliche drin, nur sicher nicht die Adresse von dem, dessen Computer 
befallen ist.

Nachdem diese hm... Artefakte von Software der juengeren Generation 
stammen, dreht sich mir bei jedem Gedanken, irgendwelche dynamischen
kreativen Quetschen einen Lightweight-Bouncer schreiben zu lassen, der
Magen um.

Ceterum censeo dass Mail ohnehin nicht mit grossen Attachments 
verschickt werden sollte, sondern dass der Fehler war, das File nicht 
auf eine Webseite zu setzen und nur den Pointer zu mailen. Ich orte 
hier eigentlich schon mal den kapitalen Fehler. 

Ciao

  Alexander, der wenigstens schon laenger kein MS-TNEF mehr gesehen
             hat.

Christof Meerwald <NOSPAM-seeMySig+ub8l@cmeerw.org> scripsit/wrote:

> Aber ist hier nicht das eigentliche Problem, dass die ganzen 12 MB gebounced
> werden?

Ja.

> Sollten solche Bounces nicht sowieso auf einige kB beschraenkt
> werden, damit solche Probleme nicht auftreten koennen?

Ja.

-thh

PS: In de.comm.provider._webspace_ ist das v�llig offtopic. Ich leite
mal in eine passende Gruppe um.
-- 
"Geil, Lutz gibt den Gandalf, Babel ist Sauron und Rolf buckelt als
Gollum durch die Lande, auf der Spur des Keys, den es einmal besass und
nach dem es immer noch verlangt ..." - Stefanie Teufel, de.alt.arnooo

at@atat.at (Alexander Talos) scripsit/wrote:

>> Aber ist hier nicht das eigentliche Problem, dass die ganzen 12 MB gebounced
>> werden? 
>
> Das halte ich fuer eine interessante Frage. 
>
> * Mit einfachem Abschneiden nach n KB ists auf jeden Fall nicht getan, 
> weil damit die MIME-Struktur (so vorhanden) kaputtgeht. 

Dann eben nur die Header. - Aber selbst wenn die MIME-Struktur
kaputtgeht, wo ist das Problem? Der Bounce soll die Mail ja
_identifizierbar_ machen, sie aber nicht zur�ckschicken.
 
> * Wenn ich per Post einen Computer verschicke, mich aber bei der Adresse 
> verschreibe, dann erwarte ich auch den ganzen Computer zurueckzubekommen
> und nicht bloss das Floppy Drive.

Da geht es um Ware, hier um Daten (Information). Wenn Du Dich
"verfaxt", bekommst Du ggf. noch nicht einmal eine Fehlermeldung; wenn
Du Dich beim Telefonieren verw�hlst, bekommst Du das, was Du (evtl.
automatisiert) dahin geplappert hast, auch nicht zur�ck. :-)

> Die diversen "freundlichen" Fehlermeldungen "Ihre Mail an JHKJHK/EXC 
> konnte nicht zugestellt werden, weil der interne Konnektor ein illegales 
> Ergebnis lieferte." - ohne Subject, ohne Header, ohne Message-ID, ohne 
> Hinweis, wer der Empfaenger haette sein sollen - sind das andere Extrem.

Der Header ist das Minimum - eine nicht zustellbar etliche MB (oder
GB!) gro�e Mail dann nochmal �bers Netz zu schaufeln, ist aber
offensichtlich idiotisch. Insbesondere dann, wenn man die Mail
bounced, weil sie zu gro� f�r den Empf�nger ist: die Chance ist ja nun
mehr als hoch, da� das dann auch f�r den Bounce gilt.
 
> Einen sinnvollen Mittelweg zu finden, wird fuer den allgemeinen Fall 
> nicht so einfach sein. Spaetestens dann, wenn ich ein Base64-Monster
> daherbekomme, ist der fachgerechte Schnitt schwer hinzubekommen und
> setzt sehr viel Wissen ueber alle moeglichen Spielarten von Mail voraus.

Header reicht. Ggf. die ersten x Zeilen Body als /text/plain - das
schadet jedenfalls nicht und ist ggf. sogar hilfreich.
 
> Ceterum censeo dass Mail ohnehin nicht mit grossen Attachments 
> verschickt werden sollte, sondern dass der Fehler war, das File nicht 
> auf eine Webseite zu setzen und nur den Pointer zu mailen. Ich orte 
> hier eigentlich schon mal den kapitalen Fehler. 

Sicher. Aber eine Mail kokmplett zu bouncen, weil sie zu gro� ist,
d.h. eine dann noch gr��ere Mail selbst zu verschicken, ist schon
etwas sehr eigenwillig.

-thh

PS: In die passende Gruppe umgebogen; ggf. m�ge man
at.internet.provider noch mitnehmen, aber nach
de.comm.provider.webspace geh�rt das sicher nicht.
-- 
"Es gibt vier Millionen Analphabeten in Deutschland. Also nach Definition Leute,
die entweder gar nicht schreiben und lesen k�nnen oder nur so schlecht, dass
zumutbarer Schriftverkehr mit ihnen nicht m�glich ist. Nur - was wollen die alle
im Usenet, im mittleren Management und im Webdesign?" --- J. E. Guenther,d.a.s.r

Christof Meerwald:

> Aber ist hier nicht das eigentliche Problem, dass die ganzen 12 MB gebounced
> werden? Sollten solche Bounces nicht sowieso auf einige kB beschraenkt
> werden, damit solche Probleme nicht auftreten koennen?

Würde ich auch so sehen.
Gibt es hotmail überhaupt?
Ich habe noch nicht eine einzige Mail erhalten,
die tatsächlich von Hotmail aus versendet wurde
(dafür aber reichlich vergetäuschte).

Gruß

Jan

Hej!

Jan Bruns <post@janbruns.de> wrote:

>Ich pers�nlich denke, da� im wesentlichen eine Fehlermeldung
>zur�ckgesendet werden mu�, auf den Body-Part meiner Mails kann 
>ich pers�nlich gut verzeichten, wenn die eh' nicht angekommen sind.

In 90% der Faelle ja. Die anderen sind aber genau die, wo's interessant
wird. Bei den Pathologischen Faellen, und das sind gerade die wichtigen,
braucht man aber doch sehr oft den Body um herauszufinden, durch welche
kranken Forward- und Gatewaymechanismen der Schlamassel ueberhaupt 
zustandegekommen ist. 

>Sollte selbst der Header einmal ungeh�rig lang sein, vielleicht
>lediglich eine Receivedzeile,Suject, From, To, Return-Path
>r�ckschicken.

Ein leicht anonymisiertes Beispiel von heute:

Return-Path: <at@sig.at>
From: <at@sig.at>
To: <hugo.bimpelmayer@concentric.net>
Subject: ERROR: Your mail
Received: from tagelectrichou.houston.tagcompanies.com ([208.189.185.156])
        by mx1.sig.at (8.12.2/8.12.2) with ESMTP id g5U9NkcN089434;
        Sun, 30 Jun 2002 11:23:50 +0200

>Sollte doch reichen.

Bitte erklaere mir, was los ist - ich jedenfalls kenne keinen hugo 
bimpelmayer.

Ciao

  Alexander

Alexander Talos:
> Einen sinnvollen Mittelweg zu finden, wird fuer den allgemeinen Fall 
> nicht so einfach sein. Spaetestens dann, wenn ich ein Base64-Monster
> daherbekomme, ist der fachgerechte Schnitt schwer hinzubekommen und
> setzt sehr viel Wissen ueber alle moeglichen Spielarten von Mail voraus.

Ich persönlich denke, daß im wesentlichen eine Fehlermeldung
zurückgesendet werden muß, auf den Body-Part meiner Mails kann 
ich persönlich gut verzeichten, wenn die eh' nicht angekommen sind.

Warum also nicht lediglich den ursprünglichen Header hinten anhängen,
das Subject mit vorangestelltem "ERROR:" übernehmen.
Sollte selbst der Header einmal ungehörig lang sein, vielleicht
lediglich eine Receivedzeile,Suject, From, To, Return-Path
rückschicken.

Sollte doch reichen.

Gruß

Jan

Alexander Talos:

> Ein leicht anonymisiertes Beispiel von heute:
 
> Return-Path: <at@sig.at>
> From: <at@sig.at>
> To: <hugo.bimpelmayer@concentric.net>
> Subject: ERROR: Your mail
> Received: from tagelectrichou.houston.tagcompanies.com ([208.189.185.156])
>         by mx1.sig.at (8.12.2/8.12.2) with ESMTP id g5U9NkcN089434;
>         Sun, 30 Jun 2002 11:23:50 +0200
 
> >Sollte doch reichen.
 
> Bitte erklaere mir, was los ist - ich jedenfalls kenne keinen hugo 
> bimpelmayer.


Also at@sig.at ist deine Mailadresse, ja?
Und Du hast also versucht,  <hugo.bimpelmayer@concentric.net>
zu mailen? Ja und, warum unterschlägst Du die Fehlermeldung?

Gruß

Jan

F'Up to at.internet.provider gesetzt, obwohl in beiden Gruppen OT.

In at.internet.provider Alexander Talos <at@atat.at> wrote:
> Hej!

> Christof Meerwald <NOSPAM-seeMySig+ub8l@cmeerw.org> wrote:

>>Aber ist hier nicht das eigentliche Problem, dass die ganzen 12 MB gebounced
>>werden? 

> Das halte ich fuer eine interessante Frage. 

> * Mit einfachem Abschneiden nach n KB ists auf jeden Fall nicht getan, 
> weil damit die MIME-Struktur (so vorhanden) kaputtgeht. 

Die MIME-Struktur ist in dem Fall wurscht. Zurueckgeschickt werden
einfach die ersten n kB der Mail. Da sind im Normalfall die Header
enthalten, die die notwendigen Informationen zur Idenfikation der Mail
reichen. Mehr brauche ich nicht, weil...

> * Wenn ich per Post einen Computer verschicke, mich aber bei der Adresse 
> verschreibe, dann erwarte ich auch den ganzen Computer zurueckzubekommen
> und nicht bloss das Floppy Drive. Bekanntlich ist nicht alles, was hinkt,
> ein Vergleich und manchmal stimmt schon nichtmal das Gegenteil, aber die
> Analogie wurde traditionell gemacht: Wenn's nicht ankommt, bekomme ich
> es zurueck. 

... vom weggeschickten Computer habe ich selten eine Kopie im
Sent-Folder, aus dem ich die Mail, egal ob sie angekommen ist, an mich
zurueckgebounced oder als Double-Bounce verschluckt wurde, jederzeit
wieder modifizieren und neu verschicken kann - auf jeden Fall
schmerzfreier, als das Message/RFC822-Attachment aus dem Bounce
rauszupulen. Wenn ich ueberhaupt das Glueck habe, dass die
urspruengliche Elektropost als solches angehaengt und nicht
einfach in den Bounce kopiert wurde.

> * Der MTA (Mail Transfer Agent) hat den Inhalt der Mail nicht anzuschauen,
> zu bearbeiten oder sonstwas. Waer ja zu bloed, wenn der Bounce nicht 
> ankommt, bloss weil der Bounce-Beschnipsler bei einem nicht 
> vorhergesehenen zEnc-Attachment in UTF-9 auf die Nase geflogen ist und 
> core gedumpt hat.

Egal. Der SMTP-Daemon ist entweder nicht 8 bit clean, woraufhin der
sendende MTA konvertiert, oder er kuendigt seine Faehigkeit mit allem
Schrott umzugehen im EHLO an. In der MIME-Struktur bzw. an der Kodierung
herumfudeln braucht er sowieso nicht.

Der "Bounce-Beschnipsler" hat sowieso keine anspruchsvolle Taetigkeit:
Kopiere die 1. 4096 Byte, egal was drinsteht, in den Bounce. IMHO sogar
*noch* robuster und fehleresistenter, als die Fehlermeldung als
Multipart-MIME zu bauen und die alte Post per Message/RFC822
anzuhaengen. Dann gibt's ja wieder die Mailer, die den ganzen Schrott so
wie er ist, an den den text/plain-Bounce anhaengen - damit faengst du
dann erst recht wieder nix an...

> Ceterum censeo dass Mail ohnehin nicht mit grossen Attachments 
> verschickt werden sollte, sondern dass der Fehler war, das File nicht 
> auf eine Webseite zu setzen und nur den Pointer zu mailen. Ich orte 
> hier eigentlich schon mal den kapitalen Fehler. 

http://cr.yp.to/im2000.html? Prinzipiell gebe ich dir recht, es sollte
nur ein DAU-taugliches Interface dafuer geben. Ich erinnere mich zu gut
an das Geweine, das ich in Support-Zeiten ertragen musste (*waeh*, warum
nehmen eure Mailserver keine Mails >20MB?), und das Unverstaendnis, als
ich auf oben genannte Loesung hinwies.

Ausserdem orte *ich* hier Sicherheitsprobleme - Passwortschutz und
automatisierte Loeschung nach Abruf muessten ebenfalls bedacht werden.
Obwohl plain Email fuer vertrauliche Dinge ja auch nicht das Gelbe vom
Ei ist.

lg,he

"Jan Bruns" <post@janbruns.de> wrote in
news:afmuu5$go5$04$1@news.t-online.com: 

> 
f'up2 a.i.p set

> Ich pers�nlich denke, da� im wesentlichen eine Fehlermeldung
> zur�ckgesendet werden mu�, auf den Body-Part meiner Mails kann 
> ich pers�nlich gut verzeichten, wenn die eh' nicht angekommen
> sind. 

Sendmail tut exakt dieses seit 8.10.0, wenn man "nobodyreturn" 
konfiguriert.

mfg, Wolfgang Breyha
-- 
 /     recursive, adj.; see recursive.  -- Unknown      \ 
( Wolfgang Breyha <wbreyha@gmx.net> - http://mash.nwy.at )
 \   System Engineering UTA/netway - Vienna - Austria   /

"Peter Gruendler" <usenet@hnet.at> schrieb im Newsbeitrag
news:3d1dee6f$0$20648$91cee783@newsreader02.highway.telekom.at...
> Bei uns ist was richtig dumm gelaufen.
>
> Wir haben seit kurzem inode (www.inode.at) als Zugangsprovider und
> schon seit l�ngerem netdiscounter (www.netdiscounter.de) als hosting-
> und mailservicesprovider.
fordere inode.at auf, die ma�nahme r�ckg�ngig zu machen und schick zur not
einen RA mit dem wunsch los verbunden mit schadenersatzforderungen.
rechtlich sind die eingriffe in den emailverkehr schwerlich zu
rechtfertigen - vor allem, wenn der betroffene host kein offenes relay
ist.einstweilige verf�gungen wirken wunder.
herbert

Herbert Grantmeyer wrote:
> fordere inode.at auf, die ma�nahme r�ckg�ngig zu machen und schick
> zur not einen RA mit dem wunsch los verbunden mit
> schadenersatzforderungen. rechtlich sind die eingriffe in den
> emailverkehr schwerlich zu rechtfertigen - vor allem, wenn der
> betroffene host kein offenes relay ist.einstweilige verf�gungen

also das sind schon kanonen auf spatzen, oder? ;-))

ein freundliches email reicht da wohl schon. solange kein grund besteht,
"st�rend" einzugreifen, wird das kein provider machen - schon garnicht, wenn
es kunden gibt, die es anders haben wollen.
--
lg. ;-)
  Roland M. Kreutzer
  www.aufzack.com

Alexander Talos <at@atat.at> wrote:
> Hej!
> 
> Claus Lenke <noreply@peek.de> wrote:
> 
>>und was spricht dagegen, den smtp-Server vom anderen Provider zu
>>verwenden? Wenn ich mit einem Provider seinem SMTP-Server ein Problem
> 
> (Mal angenommen, es gibt hier kein Problem mit offenen Relays)
> 
> Darunter leiden Postmaster und Zuverlaessigkeit des Mediums eMail. Das
> geht so:
> 
> From: bumsti@hotmail.com
> To: wopsi@hotmail.com
> Subject: Warum Frauen die schlechteren Autofahrer sind
> 
> Halo Wopsi, des must da gebn, a waunsinn!
> 
> Attachment: 12MB Powerpoint
> 
> Das wird abgeliefert bei mail.andererprovid.er. Dieser schickts an 
> Hotmail - hotmail sagt: "Quota exceeded und ueberhaupt, so lange mail
> nehmen wir eh prinzipiell nicht". Na gut, geht der Bounce an den 
> Absender. Der ist auch bei hotmail, also schicken wir ihn an hotmail. 
> Dieser sagt nun ebenfalls. "Quota exceeded und ueberhaupt". Die Mail 
> landet mangels anderer Alternativen als Doublebounce beim Postmaster 
> von andererprovid.er.

Deswegen schneiden Mailserver in der Regel die ursprüngliche Nachricht
im Bounce bei Erreichen einer bestimmten Größe ab.

> Es spricht also schon einiges dafuer, wenn jeder bei "seinem" Server
> Mail verschickt. 

Nein, Jeder sollte den Server seines IP-Access-Providers nehmen, dieser
ist netztopologisch gesehen der Nächste.





-- 
Warning:  You are not root
             
	     -- nmap V. 2.54BETA31

>> Es spricht also schon einiges dafuer, wenn jeder bei "seinem" Server
>> Mail verschickt. 
>
>Nein, Jeder sollte den Server seines IP-Access-Providers nehmen, dieser
>ist netztopologisch gesehen der N�chste.

Stimmt, es war mein schwerer Denkfehler. Der Traffic geht ja in jedem
Fall �ber meinen ISP.
Schlimm w�re es nur, wenn mein ISP A ist, mein Mailserviceprovider B
und ich den ganzen outbound traffic �ber C schicke.


Gru�,
daPeda

Dazu, was Peter Gruendler meinte, muss ich auch meinen Senf geben:

>Stimmt, es war mein schwerer Denkfehler. Der Traffic geht ja in jedem
>Fall �ber meinen ISP.
>Schlimm w�re es nur, wenn mein ISP A ist, mein Mailserviceprovider B
>und ich den ganzen outbound traffic �ber C schicke.

Bl�d wird es nur, wenn du von deinem ISP �ber deinem Mailprovider eine
Mail verschickst an jemanden der bei ISP seine Mailbox hat.

Claus