🚀 go-pugleaf

"Robin S. Socha" <robin-dated-1000311936.35f0c7@socha.net> writes:

> > Wieso M�he?  qmail-pop3d l�uft ja Out of the Box.  Ich sehe also
> > nicht, wieso das eine M�he sein soll.
> 
> Matthias schmollt gerade, weil Dan im auf der qmail Liste die Falten aus
> dem Sack geb�gelt hat. Possierliches Spielchen, sowas...

Um mal auf Deinem Sprachniveau zu bleiben: Du hast den Arsch auf.

Ich lege das Problem dar, damit jeder ganz klar sieht, was passieren
kann, wenn man ohne genauere Reflektion "irgendeine" Mail in qmail jagt,
ob per qmail-queue oder qmail-qmqpd - ob qmail-inject auf problematisch
ist, hab' ich nicht untersucht.

Was das Problem ist: qmail kann �ber verschiedene Interfaces, unter
anderem qmail-qmqpd, das auf Port 628 eingerichtet wird, Mail annehmen,
die Dan als "extended format" bezeichnet, die per SMTP nicht verschickt
werden kann (zum Beispiel fehlendes CRLF nach letzter Zeile).

Das kann in letzter Instanz dazu f�hren, da� die Mail - unter lautem
Gezeter im Log - von qmail-send weggeworfen wird.

Szenario:

1. qmail nimmt die Mail im "extended format" an. 

2. qmail-send gibt sie an qmail-remote. Das stellt fest "die Mail geht
nicht durch SMTP" und baut den Bounce. QSBMF, das "tolle" Bounceformat,
ist zwar maschinenlesbar, aber enth�lt die Originalmail als 1:1-Kopie.
Format.

3. Das hei�t, der Bounce geht wieder nicht durch qmail-remote (diesmal
h�tte der Absender die Mail kriegen sollen). qmail-send baut nach
denselben Regeln den Double-Bounce an den Postmaster.

4. Da der nicht lokal ist, bounct auch der doublebounce, qmail-send
wirft die Mail und die beiden Bounces weg, heult sich im Log aus und das
war's.

Und ja, Postmaster ist per SMTP in jedem Fall erreichbar, und QMQP
unterliegt passenden ACLS (und ist nicht der einzige Weg, Mail zu
verlieren), insofern liegt kein Konfigurationsfehler vor, wie viele,
unter anderem Dave Sill, mir unterstellt haben.



Die triviale Abhilfe w�re, zumindest den doublebounce so
zurechtzustutzen, da� er in jedem Fall durch SMTP pa�t. Man kann dazu
einfach der Body der urspr�nglichen Mail wegwerfen, dann sind nur noch
QSBMF-Records und Mailheader �ber, und der RFC-822-Header pa�t immer
durch SMTP.

Sinnvoll w�re das auch deswegen, weil den doublebounceuser der INHALT
der Mail nichts angeht, insofern w�rde ein zugestellter doublebounce die
Privatsph�re des Absenders verletzen.

Die ordentliche Abhilfe w�re, einen RFC-1894-konformen Bounce zu l�ten,
der pa�t IMMER durch SMTP, das geht mit Dans Ego und bewu�ter
Desinformation nicht. Auch hier d�rfte der doublebounceuser (postmaster
per Default) den Body nicht zu Gesicht bekommen.

Fakt ist, da� praktisch alle relevante Clientsoftware, sei es nun
Listenmanager oder MUA, RFC-1894 versteht. Nur ein Beispiel: mutt
1.3.x.y kann die gebouncte Mail aus dem Bounce extrahieren und im Editor
anbieten.

Dan Schwadron J. Bernstein vergi�t leider �ber seinem Rant gegen
RFC-1894, da� andere, verbreitet MTAs, zum Bleistift Sendm�ll und
Postfix, es verwenden und daher Clients RFC-1894 lesen k�nnen
m�ssen. DJB erwartet nun aber, da� sich alle um den Einfall eines
kleinen Professors in Illinois scheren, dessen Hobby das Erfinden
�berfl�ssiger Protokolle und Datenformate ist, und extra noch einen
Parser f�r das normwidrige QSBMF l�ten.

Auf den Vorschlag hin, im doublebounce den Body zu strippen, hab' ich
bisher positives Feedback bekommen.

Und nun troll Dich weg.

-- 
Matthias Andree
Outlook (Express) users: press Ctrl+F3 for the full source code of this post.
begin  dont_click_this_virus.exe
end