Hej!
Dennis Böge hat geschrieben:Naja es liegt doch somit an einer Fehlkonfiguration der Server, die die Mail zurück schicken oder?
Kommt drauf an, was mit "dem Server" gemeint ist, und welche Massstaebe man ansetzt.
Man koennte dem sendmail -t vorwerfen, dass es nicht intelligent genug ist, die List-Syntax zu verstehen. Das ist aber dann auch keine Konfigurationssache, sondern eher ein Feature-Request (den ich, nicht daß das was bedeuten würde, unterstützen würde) an die sendmail-Leute und möglicherweise andere MTA-Schreiberlinge. Ich habe im google jedenfalls keinen Kommentar finden können, daß die sendmail-Leute das nicht machen würden oder warum.
Das grundlegende Problem ist m.E., dass @mail nicht zwischen Envelope Recipient und Recipient Headern unterscheiden kann. Empfänger und das was im Header steht, müssen ja nicht identisch sein.
Reallife-Analogie: Wenn ich vom Finanzamt einen Schrieb bekomme, dann stecke ich ihn in ein Couvert, schreibe die Adresse von meinem Steuerberater drauf und werfe es (mit Briefmarke) in den Briefkasten. Daran ist nichts Unnatürliches - dennoch: Am Umschlag steht als Empfänger mein Scheuerberater, im Brief am Briefkopf stehe als Empfänger immer noch ich.
Dasselbe hier: Empfangen soll's der Benachrichtigte, im Briefkopf soll aber "Undisclosed-recipients:;" stehen.
Mit Bcc: kann man sich ein wenig helfen. Aber auch das hilft nicht mehr sobald
a) der Undisclosed-Recipients:;-Unfall passiert, der sich durch mehr Funktionalität in sendmail beheben ließe oder
b) Empfänger, die in To: oder Cc: stehen, die Nachricht *nicht* bekommen sollen - bei jeder Art von Weiterleitung also (wie in meinem Finanzamtsbeispiel).
Es ist die @mail-Funktion schlichtweg zu einfach gestrickt, als dass sie der beinharten Realität gerecht werden könnte.
Letzteres ist ein fundamentaleres Problem, das sich durch keine Features in sendmail oder dessen Konfiguration beheben läßt.
Also sollte man, wenn man den Fehler gemeldet bekommt, den Absender-Hoster/Provider drauf aufmerksam machen oder?
Ich würde den Forenbetreiber aufmerksam machen, daß es dieses Problem gibt und er in der derzeitig real existierenden Welt und in diesem Fall besser SMTP verwendet.
Der Mailserver-Admin, der, aus guten oder schlechten Gründen, nicht von sendmail zu $toleranterer_mta_falls_es_sowas_gibt wechseln möchte, kann nur üble Hacks anwenden.
Ein unverfrorener Admin könnte folgerndermaßen workarounden:
Im File /etc/mail/submit.cf mache...
...aus:
Code: Alles auswählen
--8----------------------------------------------------------------------------------------------
SParse0
R<@> $@ <@> special case error msgs
R$* : $* ; <@> $#error $@ 5.1.3 $: "553 List:; syntax illegal for recipient addresses"
--8----------------------------------------------------------------------------------------------
mache:
Code: Alles auswählen
--8----------------------------------------------------------------------------------------------
SParse0
R<@> $@ <@> special case error msgs
#R$* : $* ; <@> $#error $@ 5.1.3 $: "553 List:; syntax illegal for recipient addresses"
R$* : $* ; <@> $@ bogous@discard.
# Parse0 will eine gueltig aussehende Adresse haben, sonst gibts kein check_compat
--8----------------------------------------------------------------------------------------------
weiters bei check_compat:
Code: Alles auswählen
--8----------------------------------------------------------------------------------------------
Scheck_compat
R$* $| $*:$*; $: $1 $| $2:$3; $(syslog "Discarding bogous: " $2:$3; $)
R$* $| $*:$*; $#discard $: discard
--8----------------------------------------------------------------------------------------------
und, falls nicht eh schon geschehen, irgendwo bei den Maps:
Code: Alles auswählen
--8----------------------------------------------------------------------------------------------
Ksyslog syslog
--8----------------------------------------------------------------------------------------------
oder oben auf die Syslog-Zeile verzichten.
Wichtig zu wissen:
* Zwischen pattern und replacement muß ein oder mehrere Tabulatoren stehen - Blanks gehen nicht
* nachdem der Eingriff ziemlich tief in der Logik von submit.cf sitzt, geht das so nicht über submit.mc - mit der Folge, daß bei jedem Upgrade der Patch neu nachzuhupfen ist
Und all das nur, weil beim Design von @mail eine wichtige Feinheit nicht berücksichtigt wurde...
Eine Frage kommt mir da gerade in den Sinn: Was ist denn die Envelope-Senderadresse? Doch hoffentlich nicht $webserver-userid@$domain? Ich sehe in @mail jedenfalls nichts, womit ich die Absenderadresse setzen könnte, will das aber nicht vertiefen.
Ciao
Alexander, bekennender sendmail-fuzzi und php-ignorant