[postfix-users] Problem mit dynamischer IP im Received.Mailheader
Ein Kunde von uns betreibt einen Exchanger-Server mit einer dynamischen IP. Alle E-Mails werden über unseren Postfix-Mailserver abgewickelt (Empfang und Senden). Beim Zusammenspiel mit einem dritten Mailserver tritt ein Problem auf, und zwar werden die E-Mails geblockt mit dem Hinweis, unser Server würde eine dynamische IP verwenden. Hier der Header-Auszug der E-Mail, die von dem dritten Mailserver beanstandet wurde:
Received: from localhost (localhost [127.0.0.1]) by mx.unser-server.de (Postfix) with ESMTP id 83D66F983B7 for benutzer@dritter-server.de; Wed, 5 Aug 2009 10:13:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx.unser-server.de Received: from mx.unser-server.de ([127.0.0.1]) by localhost (mx.unser-server.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5StlKtp1ZQWf for benutzer@dritter-server.de; Wed, 5 Aug 2009 10:13:33 +0200 (CEST) Received: from sentsrv01.kundendomain.local (hmbg-xxxxxxxx.pool.einsundeins.de [xxx.xxx.xxx.xxx]) by mx.unser-server.de (Postfix) with ESMTPA id 01227F98433 for benutzer@dritter-server.de; Wed, 5 Aug 2009 10:12:34 +0200 (CEST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA15A3.CA4122EA" Subject: Corning Closure for FO cables - our ref. #1 2900/T Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 5 Aug 2009 10:06:35 +0200 Message-ID: 2E74429036B14745BD7F1804CCD7E6E03776C8@sentsrv01.kundendomain.local X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Mail-Betreff thread-index: AcoVBnRZQESwdo/oRAuenww0GMAslQAnSYyQ From: =?iso-8859-1?Q?VornameName?= user@kundendomain.de To: benutzer@dritter-server.de
mx.unser-server.de - Unser Postfix-Mailserver user@kundendomain.de - Sender benutzer@dritter-server.de - Empfänger sentsrv01.kundendomain.local - Der Name des sendenden Mailservers (Exchange)
Meine Frage: Macht unser Mailserver etwas verkehrt (Stichwort: Header)? Ich denke nicht, weil hier der Delivery-Report zu der Mail:
Reporting-MTA: dns; mx.unser-server.de X-Postfix-Queue-ID: 83D66F983B7 X-Postfix-Sender: rfc822; user@kundendomain.de Arrival-Date: Wed, 5 Aug 2009 10:13:34 +0200 (CEST)
Final-Recipient: rfc822; benutzer@dritter-server.de Original-Recipient: rfc822;benutzer@dritter-server.de Action: failed Status: 5.0.0 Remote-MTA: dns; mx.dritter-server.de Diagnostic-Code: smtp; 554 Service unavailable; Client host [mx.unser-server.de] blocked using Barracuda Reputation; http://bbl.barracudacentral.com/q.cgi?ip=xxx.xxx.xxx.xxx
Merkwürdigerweise taucht die dynamische IP des Exchange-Servers als die IP unseres Mailservers auf, was ja so nicht sein kann.
On Behalf Of atze@bitbox.de
Final-Recipient: rfc822; benutzer@dritter-server.de Original-Recipient: rfc822;benutzer@dritter-server.de Action: failed Status: 5.0.0 Remote-MTA: dns; mx.dritter-server.de Diagnostic-Code: smtp; 554 Service unavailable; Client host [mx.unser-server.de] blocked using Barracuda Reputation; http://bbl.barracudacentral.com/q.cgi?ip=xxx.xxx.xxx.xxx
Your Problem iss barracudacentral.com eine der "schönen" Appliance 'n die mehr Probs wie sonst was machen.
Da kannst du nur dem Absender empfehlen sich mit dem Empfänger kurzzuschließen damit dieser ein whitelisting für ihn einfügt.
Wir haben mal versucht herauszufinden aufgrund wessen die da etwas blocken und haben bis heute keine Antwort. Das fällt bei denen und Betriebsgeheimnis.
Was noch sein kann ist das deren headercheck auf deinem Kunden seinen Server matcht und er deshalb geblockt wird.
Merkwürdigerweise taucht die dynamische IP des Exchange-Servers als die IP unseres Mailservers auf, was ja so nicht sein kann.
Mit freundlichen Grüßen
Drießen
Danke schon mal für die Antwort. Aber das Problem für unseren Kunden muss noch gelöst werden. Kann ich unserem Postfix nicht beibringen solche "local" Header zu filtern? Wohlgemerkt nur bei ausgehender Mail, idealerweise nur bei diesem Kunden. Ich habe schon etwas recherchiert und bin auf header_checks gestoßen, aber die Benutzung erschließt sich mir noch nicht. Kann jemand mit einem Beispiel dienen? Ich werde in der Zwischenzeit RTFM. :)
Volker Thiel
Am 12.08.2009 um 12:11 schrieb "Uwe Driessen" driessen@fblan.de:
Your Problem iss barracudacentral.com eine der "schönen" Appliance ' n die mehr Probs wie sonst was machen.
Da kannst du nur dem Absender empfehlen sich mit dem Empfänger kurzz uschließen damit dieser ein whitelisting für ihn einfügt.
Wir haben mal versucht herauszufinden aufgrund wessen die da etwas blocken und haben bis heute keine Antwort. Das fällt bei denen und Betriebsgeheimnis.
Was noch sein kann ist das deren headercheck auf deinem Kunden seinen Server matcht und er deshalb geblockt wird.
Mit freundlichen Grüßen
Drießen
-- Software & Computer Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: +49 06708 / 660045 Fax: +49 06708 / 661397
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Hi,
Danke schon mal für die Antwort. Aber das Problem für unseren Kunden muss noch gelöst werden. Kann ich unserem Postfix nicht beibringen solche "local" Header zu filtern? Wohlgemerkt nur bei ausgehender Mail, idealerweise nur bei diesem Kunden. Ich habe schon etwas recherchiert und bin auf header_checks gestoßen, aber die Benutzung erschließt sich mir noch nicht. Kann jemand mit einem Beispiel dienen? Ich werde in der Zwischenzeit RTFM. :)
Received: from localhost (localhost [127.0.0.1]) by mail.domain.de (Postfix) with ESMTP
/etc/postfix/main.cf header_checks = pcre:/etc/postfix/header_checks
/etc/postfix/header_checks /^Received: from.*(127.0.0.1|localhost)/ IGNORE
Meinst du sowas ?
Ciao, Werner
Hi alle,
barracudas haben einen lokal Administrator, der selbständig bzw. dessen Domainkunden via webinterface mails als spam markieren können. Der barracuda-admin kann unterschiedlichste blocking-regeln erstellen. All diese Daten werden (wenn Funktion vom admin aktiviert wurde) auch mit barracuda abgeglichen, wo wiederum spam & viren pattern erstellt werden und an die barracudas weltweit verteilt werden. Blocking/rbl listen bei barracudacentral werden so auch gepflegt. Bei www.barracudacentral.org kann jeder ein delisting beantragen...
Also wir haben 99.x % aller einkommenden mails als spams geblockt. Ich frage mich halt auch schon, warum man einen Exchange Server mit einer dynamischen IP betreiben muss... Eins ist sicher, auf die rbl bei barracudacentral kommt man nur, wenn viren & spams nachgewiesenerweise über die IP gingen...
Lg Georg Käfer
_________________ backbone - Das Rückgrat Ihrer Kommunikation Mag. Georg Käfer backbone internet service GmbH Dr.Adolf-Altmann-Str.30, 5020 Salzburg, Austria Tel: ++43-662-63 34 34, Fax: ++43-662-63 34 34-14 www.backbone.co.at gkaefer@backbone.co.at
-----Ursprüngliche Nachricht----- Von: postfix-users-bounces+gkaefer=backbone.co.at@de.postfix.org [mailto:postfix-users-bounces+gkaefer=backbone.co.at@de.postfix.org] Im Auftrag von Uwe Driessen Gesendet: Mittwoch, 12. August 2009 12:11 An: 'Mailing-Liste der deutschsprachigen Postfix Gemeinschaft' Betreff: Re: [postfix-users] Problem mit dynamischer IP imReceived.Mailheader
On Behalf Of atze@bitbox.de
Final-Recipient: rfc822; benutzer@dritter-server.de Original-Recipient: rfc822;benutzer@dritter-server.de Action: failed Status: 5.0.0 Remote-MTA: dns; mx.dritter-server.de Diagnostic-Code: smtp; 554 Service unavailable; Client host [mx.unser-server.de] blocked using Barracuda Reputation; http://bbl.barracudacentral.com/q.cgi?ip=xxx.xxx.xxx.xxx
Your Problem iss barracudacentral.com eine der "schönen" Appliance 'n die mehr Probs wie sonst was machen.
Da kannst du nur dem Absender empfehlen sich mit dem Empfänger kurzzuschließen damit dieser ein whitelisting für ihn einfügt.
Wir haben mal versucht herauszufinden aufgrund wessen die da etwas blocken und haben bis heute keine Antwort. Das fällt bei denen und Betriebsgeheimnis.
Was noch sein kann ist das deren headercheck auf deinem Kunden seinen Server matcht und er deshalb geblockt wird.
Merkwürdigerweise taucht die dynamische IP des Exchange-Servers als die IP unseres Mailservers auf, was ja so nicht sein kann.
Mit freundlichen Grüßen
Drießen
On Behalf Of Georg Käfer
Hi alle,
barracudas haben einen lokal Administrator, der selbständig bzw. dessen Domainkunden via webinterface mails als spam markieren können. Der barracuda-admin kann unterschiedlichste blocking-regeln erstellen. All diese Daten werden (wenn Funktion vom admin aktiviert wurde) auch mit barracuda abgeglichen, wo wiederum spam & viren pattern erstellt werden und an die barracudas weltweit verteilt werden. Blocking/rbl listen bei barracudacentral werden so auch gepflegt. Bei www.barracudacentral.org kann jeder ein delisting beantragen...
Tja wichtiger wäre es wenn man genau mitgeteilt bekäme warum auch immer man auf dieser Liste gelandet ist. Diese Antwort steht bis Heute noch aus.
Ein Delisting bzw. das die Mails wieder von diesem Barracuda angenommen wurden dauerte ca. 14 Tage.
Der lokale Admin hatte angegeben das er nur die Blacklist von Barracuda eingeschaltet hatte (öffentliche Verwaltung halt).
Da auch die Mails der eigenen User über Amavis und Clamav laufen kann so was mit sehr großer Wahrscheinlichkeit ausgeschlossen werden (zumindest in dem von mir erlebten Fall) Wo wir wieder beim Nutzen solcher gekapselten Systeme (Mail-Appliancen) in nicht speziell geschulten Händen sind. Das Klicki Bunti suggeriert vielen das man ja nicht viel falsch machen kann und "das kann ja jeder".
Also wir haben 99.x % aller einkommenden mails als spams geblockt. Ich frage mich halt auch schon, warum man einen Exchange Server mit einer dynamischen IP betreiben muss...
Als Relay hinter einem öffentlichen Mailserver why not wenns Spaß macht und richtig aufgesetzt ist dann muß auch so was gehen zumal alle Mails wie angegeben ÜBER den offiziellen Mailserver rein und ausgehend laufen.
Eins ist sicher, auf die rbl bei barracudacentral kommt man nur, wenn viren & spams nachgewiesenerweise über die IP gingen...
Das wage ich mal zu bezweifeln.
Barracuda Reputation Block List (BRBL) - Listing Methodology The Barracuda Reputation Block List (BRBL) is based on the Barracuda Reputation System and operates collaboratively to fight spam. The BRBL provides a list of IP addresses which are sending spam. The Barracuda Reputation system uses automated collection methods to add and delete IP addresses from the BRBL.
The automated spam trap, collection and rating system automatically adds IP addresses to the list when spam is detected. Barracuda Networks does not manually add addresses to this IP list.
Hat dich einer auf dem Kicker wirft er dich dort einfach ein ohne weitere Prüfung seitens der Liste ist so als ob ich meinen User erlaube würde die Blacklist für den kompletten Server zu beeinflussen.
Des einen Spam ist des anderen Ham.
Eine dynamische IP irgendwo im Header darf nicht zum blocken führen denn 99,9% der Mails kommen aus privaten Netzen und von dynamischer Ip auf Ihren Mailserver der diese dann weiter versendet. Einziges Kriterium das hier gilt ist welche Reputation hat der Mailserver von der verwendeten IP.
Kosten Nutzen von freien Systemen zu solchen überteuerten Systemen dürfte weit aus höher liegen. Und die Wartung auf einem freien System mit Postfix, Amavis, Clamav, Spamassasin ist auch nicht höher oder kostenintensiver von den Anschaffungskosten mal ganz abgesehen.
Lg Georg Käfer
Mit freundlichen Grüßen
Drießen
Tja wichtiger wäre es wenn man genau mitgeteilt bekäme warum auch immer man auf dieser Liste gelandet ist. Diese Antwort steht bis Heute noch aus.
Das ist korrekt. Der lokale Admin der Barracuda kann diesen Grund aber zu 100% ablesen und seinem Kunden mitteilen, bzw. Die Schlüsse daraus ziehen und seien Blockingregeln anpassen/korrigieren etc.
Ein Delisting bzw. das die Mails wieder von diesem Barracuda angenommen wurden dauerte ca. 14 Tage.
Das ist natürlich mehr als sch.....!
Der lokale Admin hatte angegeben das er nur die Blacklist von Barracuda eingeschaltet hatte (öffentliche Verwaltung halt).
Nun ja. Da hat sichs diese Person sehr einfach gemacht mit seiner Aussage. Klingt nach abwimmeln bzw. Unwissenheit...
Da auch die Mails der eigenen User über Amavis und Clamav laufen kann so was mit sehr großer Wahrscheinlichkeit ausgeschlossen werden (zumindest in dem von mir erlebten Fall) Wo wir wieder beim Nutzen solcher gekapselten Systeme (Mail-Appliancen) in nicht speziell geschulten Händen sind. Das Klicki Bunti suggeriert vielen das man ja nicht viel falsch machen kann und "das kann ja jeder".
Das sehe ich auch so. aber... Remember: dynamische IP. D.h. der Exchange-Server ist mit grosser Wahrscheinlichkeit zum Handkuss gekommen. Ein anderer Kunde hatte vermutlich die IP früher in Verwendung und hatte keinen sicheren PC/Server in Verwendung und die IP kam so auf die Blockingliste. Fixe ip für einen Mailserver sollte so manches Problem lösen helfen.
Als Relay hinter einem öffentlichen Mailserver why not wenns Spaß macht und richtig aufgesetzt ist dann muß auch so was gehen zumal alle Mails wie angegeben ÜBER den offiziellen Mailserver rein und ausgehend laufen.
Klar. Relay mit fixer IP und Problem ist passe.
Eins ist sicher, auf die rbl bei barracudacentral kommt man nur, wenn viren & spams nachgewiesenerweise über die IP gingen...
Das wage ich mal zu bezweifeln.
Hat dich einer auf dem Kicker wirft er dich dort einfach ein ohne weitere Prüfung seitens der Liste ist so als ob ich meinen User erlaube würde die Blacklist für den kompletten Server zu beeinflussen.
Des einen Spam ist des anderen Ham.
Zur Aussage an sich muss ich zustimmen... aber bei Barracuda kann keiner vernadert werden bzw. händisch gelistet werden, die mails werden maschinell untersucht und entsprechend die RBL gepflegt... die traps sind zum einen die barracudas, ob hier andererseits auch noch andere Formen von dedicated traps im Einsatz sind, keine Ahnung... bez. Listing-Politik: http://www.barracudacentral.org/rbl/listing-methodology
Kosten Nutzen von freien Systemen zu solchen überteuerten Systemen dürfte weit aus höher liegen. Und die Wartung auf einem freien System mit Postfix, Amavis, Clamav, Spamassasin ist auch nicht höher oder kostenintensiver von den Anschaffungskosten mal ganz abgesehen.
Überteuert? 2000€ Anschaffungskosten für ein System, das täglich 1Mio. Spams blockiert, empfinde ich nicht als überteuert.
Beides hat vor/nachteile und ebenfalls seine speziellen Anwendergruppen. Also ich habe beide Welten im Einsatz, die einen Kunden bevorzugen das eine System, andere das andere ;-) wie überall halt...
Lg Georg
On Behalf Of Georg Käfer
Das sehe ich auch so. aber... Remember: dynamische IP. D.h. der Exchange-Server ist mit grosser Wahrscheinlichkeit zum Handkuss gekommen. Ein anderer Kunde hatte vermutlich die IP früher in Verwendung und hatte keinen sicheren PC/Server in Verwendung und die IP kam so auf die Blockingliste. Fixe ip für einen Mailserver sollte so manches Problem lösen helfen.
Als Relay hinter einem öffentlichen Mailserver why not wenns Spaß macht und richtig aufgesetzt ist dann muß auch so was gehen zumal alle Mails wie angegeben ÜBER den offiziellen Mailserver rein und ausgehend laufen.
Klar. Relay mit fixer IP und Problem ist passe.
Tztztz der Exchange ist nicht mehr wie irgendein Client der Mails über seinen Provider verschickt. Wenn wir jetzt anfangen das alle Clients feste IP brauchen dann kommt sicherlich ganz schnell IP V6
Nee Georg das muß auch einfach so gehen. Geht mit tausenden anderen Mailservern auch so also muß da was bei Baracuda im Argen liegen und nicht auf den hunderttausenden anderen Servern die klaglos diese Mails verarbeiten.
Mit freundlichen Grüßen
Drießen
Uwe Driessen schrieb:
On Behalf Of Georg Käfer
Das sehe ich auch so. aber... Remember: dynamische IP. D.h. der Exchange-Server ist mit grosser Wahrscheinlichkeit zum Handkuss gekommen. Ein anderer Kunde hatte vermutlich die IP früher in Verwendung und hatte keinen sicheren PC/Server in Verwendung und die IP kam so auf die Blockingliste. Fixe ip für einen Mailserver sollte so manches Problem lösen helfen.
Als Relay hinter einem öffentlichen Mailserver why not wenns Spaß macht und richtig aufgesetzt ist dann muß auch so was gehen zumal alle Mails wie angegeben ÜBER den offiziellen Mailserver rein und ausgehend laufen.
Klar. Relay mit fixer IP und Problem ist passe.
Tztztz der Exchange ist nicht mehr wie irgendein Client der Mails über seinen Provider verschickt. Wenn wir jetzt anfangen das alle Clients feste IP brauchen dann kommt sicherlich ganz schnell IP V6
Nee Georg das muß auch einfach so gehen. Geht mit tausenden anderen Mailservern auch so also muß da was bei Baracuda im Argen liegen und nicht auf den hunderttausenden anderen Servern die klaglos diese Mails verarbeiten.
Mit freundlichen Grüßen
Drießen
100 % ack, was zaehlt ist der letzte hopp alles andere ist fuer ein smtp ip reject erstmal wurst, wenn man das ueberhaupt bewerten will dann mit spamassassin und markierung etc, aber ein mail abzulehen weil sie irgendwann mal von einer dynamischen ip gekommen ist ( forgewarded relayed whatever ) ist schlicht und ergreifend Schwachsinn
Uwe Driessen schrieb:
On Behalf Of atze@bitbox.de
Final-Recipient: rfc822; benutzer@dritter-server.de Original-Recipient: rfc822;benutzer@dritter-server.de Action: failed Status: 5.0.0 Remote-MTA: dns; mx.dritter-server.de Diagnostic-Code: smtp; 554 Service unavailable; Client host [mx.unser-server.de] blocked using Barracuda Reputation; http://bbl.barracudacentral.com/q.cgi?ip=xxx.xxx.xxx.xxx
Your Problem iss barracudacentral.com eine der "schönen" Appliance 'n die mehr Probs wie sonst was machen.
Da kannst du nur dem Absender empfehlen sich mit dem Empfänger kurzzuschließen damit dieser ein whitelisting für ihn einfügt.
Wir haben mal versucht herauszufinden aufgrund wessen die da etwas blocken und haben bis heute keine Antwort. Das fällt bei denen und Betriebsgeheimnis.
Was noch sein kann ist das deren headercheck auf deinem Kunden seinen Server matcht und er deshalb geblockt wird.
Merkwürdigerweise taucht die dynamische IP des Exchange-Servers als die IP unseres Mailservers auf, was ja so nicht sein kann.
Mit freundlichen Grüßen
Drießen
Hi , ich hab mal erlebt das eine Uni in den USA den ganzen Block der tcom geblockt hatte und zwar egal wo sich so eine ip im header der mail befand, wir haben sie auf ihren Fehler aufmerksam gemacht und sie haben es dann gefixt, du koenntest als workaround die ip des exchange rausnehmen
etwa so header_checks
/^received:.*dei.ne.ip.adr/ IGNORE
Am 12.08.2009 um 17:06 schrieb Robert Schetterer robert@schetterer.org:
Hi , ich hab mal erlebt das eine Uni in den USA den ganzen Block der tcom geblockt hatte und zwar egal wo sich so eine ip im header der mail befand, wir haben sie auf ihren Fehler aufmerksam gemacht und sie haben es dann gefixt, du koenntest als workaround die ip des exchange rausnehmen
etwa so header_checks
/^received:.*dei.ne.ip.adr/ IGNORE
Wird nicht funktionieren da der Exchange Server mit einer dynamischen IP im Netz hängt. Das wird ja auch von der Barracuda FW angemeckert (nur kommt sie eben mit den IPs durcheinander). Filtern kann ich aber den Servernamen, der vom Exchange Server vergeben wird. Ich erichte morgen bzgl. Resultate.
Volker Thiel schrieb:
Am 12.08.2009 um 17:06 schrieb Robert Schetterer robert@schetterer.org:
Hi , ich hab mal erlebt das eine Uni in den USA den ganzen Block der tcom geblockt hatte und zwar egal wo sich so eine ip im header der mail befand, wir haben sie auf ihren Fehler aufmerksam gemacht und sie haben es dann gefixt, du koenntest als workaround die ip des exchange rausnehmen
etwa so header_checks
/^received:.*dei.ne.ip.adr/ IGNORE
Wird nicht funktionieren da der Exchange Server mit einer dynamischen IP im Netz hängt. Das wird ja auch von der Barracuda FW angemeckert (nur kommt sie eben mit den IPs durcheinander). Filtern kann ich aber den Servernamen, der vom Exchange Server vergeben wird. Ich erichte morgen bzgl. Resultate. _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
dann nimm halt alle recieved header zu diesem mailserver bzw zu dieser domain raus/oder ersetze sie, dafuer einen zusaetzlichen transport zb so muesste das gehen
master.cf
bugmail unix - - n - - smtp -o smtp_header_checks=regexp:/etc/postfix/bugmail_header_checks
/etc/postfix/bugmail_header_checks
/^received:.*/ REPLACE X-INFO: ips where deleted here
transport
buggy.domain bugmail:
sicher nicht ganz optimal aber zumindest ein workaround
* Robert Schetterer robert@schetterer.org:
master.cf
bugmail unix - - n - - smtp -o smtp_header_checks=regexp:/etc/postfix/bugmail_header_checks
/etc/postfix/bugmail_header_checks
/^received:.*/ REPLACE X-INFO: ips where deleted here
transport
buggy.domain bugmail:
header_checks(5) werden von cleanup(8) durchgeführt, _bevor_ die Mail gequeued wird.
Ich weiß überhaupt nicht, wo das Problem ist: Über den betreffenden Exchange mal eine Mail an sich selbst schicken, die Zeile mit "Received:" in einen geeigneten regulären Ausdruck zerlegen - der Exchange wird ja wohl wenigstens immer den gleichen Hostnamen im HELO übertragen:
/^Received: +from +exchange.server +((.*))/ REPLACE: X-Submission: by exchange.server ($1)
Den Aufwand kann man jetzt noch beliebig steigern, aber das wäre halt genau eines: Aufwand.
Ciao Stefan
Stefan Förster schrieb:
- Robert Schetterer robert@schetterer.org:
master.cf
bugmail unix - - n - - smtp -o smtp_header_checks=regexp:/etc/postfix/bugmail_header_checks
/etc/postfix/bugmail_header_checks
/^received:.*/ REPLACE X-INFO: ips where deleted here
transport
buggy.domain bugmail:
header_checks(5) werden von cleanup(8) durchgeführt, _bevor_ die Mail gequeued wird.
Ich weiß überhaupt nicht, wo das Problem ist: Über den betreffenden Exchange mal eine Mail an sich selbst schicken, die Zeile mit "Received:" in einen geeigneten regulären Ausdruck zerlegen - der Exchange wird ja wohl wenigstens immer den gleichen Hostnamen im HELO übertragen:
/^Received: +from +exchange.server +((.*))/ REPLACE: X-Submission: by exchange.server ($1)
Den Aufwand kann man jetzt noch beliebig steigern, aber das wäre halt genau eines: Aufwand.
Ciao Stefan
jo jo der Moeglichkeiten sind viele *g
* Stefan Förster cite+de-postfix-users@incertum.net:
- Robert Schetterer robert@schetterer.org:
master.cf
bugmail unix - - n - - smtp -o smtp_header_checks=regexp:/etc/postfix/bugmail_header_checks
/etc/postfix/bugmail_header_checks
/^received:.*/ REPLACE X-INFO: ips where deleted here
transport
buggy.domain bugmail:
header_checks(5) werden von cleanup(8) durchgeführt, _bevor_ die Mail gequeued wird.
I stand corrected. Also nicht mit meiner obigen Aussage, das stimmt im Prinzip schon, aber ich habe oben statt "smtp_header_checks" einfach nur "header_checks" gelesen - und die tun natürlich genau das, was Robert intendiert hatte.
Ciao Stefan
Stefan Förster schrieb:
- Stefan Förster cite+de-postfix-users@incertum.net:
- Robert Schetterer robert@schetterer.org:
master.cf
bugmail unix - - n - - smtp -o smtp_header_checks=regexp:/etc/postfix/bugmail_header_checks
/etc/postfix/bugmail_header_checks
/^received:.*/ REPLACE X-INFO: ips where deleted here
transport
buggy.domain bugmail:
header_checks(5) werden von cleanup(8) durchgeführt, _bevor_ die Mail gequeued wird.
I stand corrected. Also nicht mit meiner obigen Aussage, das stimmt im Prinzip schon, aber ich habe oben statt "smtp_header_checks" einfach nur "header_checks" gelesen - und die tun natürlich genau das, was Robert intendiert hatte.
Ciao Stefan
jo, jo,
smtp_header_checks (default: empty)
Restricted header_checks(5) tables for the Postfix SMTP client. These tables are searched while mail is being delivered. Actions that change the delivery time or destination are not available.
This feature is available in Postfix 2.5 and later.
* atze@bitbox.de:
Received: from sentsrv01.kundendomain.local (hmbg-xxxxxxxx.pool.einsundeins.de [xxx.xxx.xxx.xxx]) by mx.unser-server.de (Postfix) with ESMTPA id 01227F98433 for benutzer@dritter-server.de; Wed, 5 Aug 2009 10:12:34 +0200
[...]
Diagnostic-Code: smtp; 554 Service unavailable; Client host [mx.unser-server.de] blocked using Barracuda Reputation; http://bbl.barracudacentral.com/q.cgi?ip=xxx.xxx.xxx.xxx
Merkwürdigerweise taucht die dynamische IP des Exchange-Servers als die IP unseres Mailservers auf, was ja so nicht sein kann.
Die Appliance ignoriert den ESMTPA-Protokolleintrag. Da scheint sich in den letzten Tagen was bei Barracuda geändert zu haben, in IRC schlagen seit Kurzem immer wieder Leute mit diesem Problem auf.
header_checks(5) sind wohl wirklich Deine einzige Lösung - vielleicht tauscht Du ja einfach "^Received: ..." durch "X-Submission:", auf diese Weise bleiben die Daten bestehen.
Ciao Stefan
participants (7)
-
atze＠bitbox.de -
Georg Käfer -
Robert Schetterer -
Stefan Förster -
Uwe Driessen -
Volker Thiel
-
Werner Detter