🚀 go-pugleaf

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