Knorkator 12 Geschrieben 7. Februar 2014 Melden Teilen Geschrieben 7. Februar 2014 Hallo, wir haben 2 Domains bei denen es immer mal wieder Probleme gibt, wenn eine Mail in Abwesenheit durch den Autoresponder beantwortet werden soll. Als Fehlermeldung liefert eine Gegenstelle die Meldung "550 Administrative Prohibition". Vorhin wurde das ganze von einem anderen Server mit der Fehlermeldung "550 Empty envelope senders not allowed" abgelehnt -> damit kann man ja schon eher etwas anfangen. Lt. SMTP Traffic Log meldet sich unser Server so: SMTP command: Mail from:<> Die meisten Domains scheinen kein Problem damit zu haben, daher viel es erst jetzt auf (Der Server läuft seit 8 Monaten). Woran liegt es, dass das Phänomen nur auftrit, wenn der Autoresponder aktiv wird? Danke im voraus! Zitieren Link zu diesem Kommentar
Daniel -MSFT- 129 Geschrieben 7. Februar 2014 Melden Teilen Geschrieben 7. Februar 2014 Die Mail wird mit dem Null-Sender verschickt, damit es nicht zu Mailschleifen kommt. Stell Dir vor, die Gegenseite würde auch eine automatische Antwort schicken... Das Verhalten von Exchange ist regelkonform. Das Problem liegt an den ablehnenden Mailservern. Zitieren Link zu diesem Kommentar
Knorkator 12 Geschrieben 7. Februar 2014 Autor Melden Teilen Geschrieben 7. Februar 2014 Hallo Daniel! Das leuchtet ein! Danke für die prompte Antwort!! Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 7. Februar 2014 Melden Teilen Geschrieben 7. Februar 2014 Korrekt, siehe auch hier Zitieren Link zu diesem Kommentar
Knorkator 12 Geschrieben 7. Februar 2014 Autor Melden Teilen Geschrieben 7. Februar 2014 Und dabei hab ich so nach einer Erklärung dafür gesucht ... manchmal findet man die Lösung nicht von alleine... :/ Vielen Dank für Euren Support! :) Zitieren Link zu diesem Kommentar
Knorkator 12 Geschrieben 24. Februar 2014 Autor Melden Teilen Geschrieben 24. Februar 2014 (bearbeitet) Hallo noch einmal, jetzt habe ich das Problem, dass sich eine Gegenstelle ziert, die Konfiguration zu ändern. Zitat: "Das Problem liegt an einer Fehlkonfiguration an Ihrem Server!" Ist es möglich, das Verhalten des Exchange Servers zu verändern? Ggf. nur für diese eine Gegenstelle? Alternativ informiere ich unsere Mitarbeiter, dass Abwesenheitsnachrichten an Firma XY nicht zugestellt werden und sie bitte deren Ansprechpartner zu informieren haben. Nochmals Danke! bearbeitet 25. Februar 2014 von Knorkator Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 24. Februar 2014 Melden Teilen Geschrieben 24. Februar 2014 Moin, nein, es gibt keine Möglichkeit, das Verhalten zu ändern. Warum auch, es ist so RFC-Konform. Zitieren Link zu diesem Kommentar
Knorkator 12 Geschrieben 24. Februar 2014 Autor Melden Teilen Geschrieben 24. Februar 2014 Ok, Danke! Zitieren Link zu diesem Kommentar
Knorkator 12 Geschrieben 24. Februar 2014 Autor Melden Teilen Geschrieben 24. Februar 2014 Hallo nochmal, habe eben doch noch einen SMTP Mitschnitt laufen lassen. Nur um sicherzugehen, dass es nicht doch noch etwas anderes sein kann. Zur Info: Unser Exchange sendet die Mails an ein Mailgateway von Gdata welches die Kommunikation zu den anderen Mailservern herstellt. Der Exchange stellt also nicht direkt zu.. Die eingehende Mail: [1664] *** SMTP-Thread: Mail #8613 Read incoming mail(s) 123.123.123.123 ... [1664] mail [3588] <- #8613: Sending: 220 mail.domain.com AVKSMTP Server [1664] mail [3588] <- #8613: SMTP command: EHLO fw.Domainextern.com [1664] mail [3588] <- #8613: Sending: 250-mail.domain.com Hello fw.Domainextern.com [1664] 250 HELP [1664] mail [3588] <- #8613: SMTP command: MAIL FROM:<prvs=01326c09be=Userextern@Domainextern.com> [1664] mail [3588] <- #8613: Sending: 250 <prvs=01326c09be=Userextern@Domainextern.com> ... Sender Okay [1664] mail [3588] <- #8613: SMTP command: RCPT TO:<user@domain.com> [1664] mail [3588] <- #8613: Sending: 250 <user@domain.com> ... Recipient Okay [1664] mail [3588] <- #8613: SMTP command: DATA [1664] mail [3588] <- #8613: Sending: 354 Start mail input; end with <CRLF>.<CRLF> [1664] mail [3588] <- #8613: Sending: 250 Mail accepted [1664] *** SMTP-Thread: Mail #8613 Read Mail complete (first) --- Sender: <prvs=01326c09be=Userextern@Domainextern.com> [1664] mail [3588] <- #8613: CheckWithMimeSniffer: in140224125600_21A5.msg [1664] mail [3588] <- #8613: Scan message bodies... [1664] mail [3588] <- #8613: Scan File... C:\Program Files (x86)\G DATA\G DATA MailSecurity\incoming mail\in140224125600_21A5_1_image001.jpg [1664] mail [3588] <- #8613: Scan File... C:\Program Files (x86)\G DATA\G DATA MailSecurity\incoming mail\in140224125600_21A5_2_image002.jpg [1664] mail [3588] <- #8613: Scan File... C:\Program Files (x86)\G DATA\G DATA MailSecurity\incoming mail\in140224125600_21A5_3_att.txt [1664] mail [3588] <- #8613: Scan File... C:\Program Files (x86)\G DATA\G DATA MailSecurity\incoming mail\in140224125600_21A5_4_att.html [1664] mail [3588] <- #8613: Filter message bodies... [1664] mail [3588] <- #8613: Check Return-Receipt-Filter... [1664] mail [3588] <- #8613: Check Attachment-Filter... [1664] mail [3588] <- #8613: Check Attachment-Filter... [1664] mail [3588] <- #8613: Scan URLs... [1664] mail [3588] <- #8613: Scan URLs: 3 scanned, 0,00 sec. elapsed [1664] mail [3588] <- #8613: Scan URLs... [1664] mail [3588] <- #8613: Scan URLs: 7 scanned, 0,00 sec. elapsed [1664] mail [3588] <- #8613: Check HTML-Filter... [1664] mail [3588] <- #8613: Commtouch spam detection... [1664] mail [3588] <- #8613: Commtouch IP: 123.123.123.0 [1664] mail [3588] <- #8613: Commtouch sender: <prvs=01326c09be=Userextern@Domainextern.com> [1664] mail [3588] <- #8613: Commtouch recipients: <user@domain.com>; [1664] mail [3588] <- #8613: Commtouch response: ThreatLevel=0 SpamLevel=1 [1664] mail [3588] <- #8613: CheckWithMimeSniffer done! [1664] *** SMTP-Thread: Mail #8613 add to queue... <prvs=01326c09be=Userextern@Domainextern.com> [1664] *** SendMailThread: Mail #8613 Send the mail ... <prvs=01326c09be=Userextern@Domainextern.com> [1664] mail [3588] <- #8613: SMTP command: QUIT [1664] mail [2964] <- #8613: SendMail (no dns) 192.168.100.211 ... [1664] mail [3588] <- #8613: Sending: 221 mail.domain.com closing connection [1664] mail [2964] <- #8613: SendMailToServer 192.168.100.211 ... [1664] *** SendMailThread: Mail #8613 Sending complete! <prvs=01326c09be=Userextern@Domainextern.com> [1664] *** SendMailThread: Mail #8613 for storing queued [1664] *** SMTP-Thread: 3 active thread(s) Die Abwesenheitsbenachrichtigung: [1664] *** SMTP-Thread: Mail #8614 Read outgoing mail(s) 192.168.100.211 ... [1664] mail [3708] -> #8614: Sending: 220 mail.domain.com AVKSMTP Server [1664] mail [3708] -> #8614: SMTP command: EHLO mail.domain.com [1664] mail [3708] -> #8614: Sending: 250-mail.domain.com Hello mail.domain.com [1664] 250 HELP [1664] mail [3708] -> #8614: SMTP command: MAIL FROM:<> [1664] mail [3708] -> #8614: Sending: 250 <> ... Sender Okay [1664] mail [3708] -> #8614: SMTP command: RCPT TO:<Userextern@Domainextern.com> [1664] mail [3708] -> #8614: Sending: 250 <Userextern@Domainextern.com> ... Recipient Okay [1664] mail [3708] -> #8614: SMTP command: DATA [1664] mail [3708] -> #8614: Sending: 354 Start mail input; end with <CRLF>.<CRLF> [1664] mail [3708] -> #8614: Sending: 250 Mail accepted [1664] *** SMTP-Thread: Mail #8614 Read Mail complete (first) --- Sender: <> [1664] mail [3708] -> #8614: CheckWithMimeSniffer: out140224125603_21A6.msg [1664] mail [3708] -> #8614: Scan message bodies... [1664] mail [3708] -> #8614: Scan File... C:\Program Files (x86)\G DATA\G DATA MailSecurity\outgoing mail\out140224125603_21A6_1_att.txt [1664] mail [3708] -> #8614: Scan File... C:\Program Files (x86)\G DATA\G DATA MailSecurity\outgoing mail\out140224125603_21A6_2_att.html [1664] mail [3708] -> #8614: Filter message bodies... [1664] mail [3708] -> #8614: Check Return-Receipt-Filter... [1664] mail [3708] -> #8614: Scan URLs... [1664] mail [3708] -> #8614: Scan URLs: 0 scanned, 0,00 sec. elapsed [1664] mail [3708] -> #8614: Scan URLs... [1664] mail [3708] -> #8614: Scan URLs: 2 scanned, 0,00 sec. elapsed [1664] mail [3708] -> #8614: Check HTML-Filter... [1664] mail [3708] -> #8614: CheckWithMimeSniffer done! [1664] mail [3708] -> #8614: Commtouch virus detection... [1664] mail [3708] -> #8614: Commtouch IP: 192.168.100.211 [1664] mail [3708] -> #8614: Commtouch sender: <> [1664] mail [3708] -> #8614: Commtouch recipients: <Userextern@Domainextern.com>; [1664] mail [3708] -> #8614: Commtouch response: ThreatLevel=0 SpamLevel=1 [1664] *** SMTP-Thread: Mail #8614 add to queue... <> [1664] mail [3708] -> #8614: SMTP command: QUIT [1664] mail [3708] -> #8614: Sending: 221 mail.domain.com closing connection [1664] *** SendMailThread: Mail #8614 Send the mail ... <> [1664] mail [7F4] -> #8614: SendMail (use dns) ... [1664] mail [7F4] -> #8614: DNS-Query ... [1664] mail [7F4] -> #8614: MX-Entry: fw.Domainextern.com [1664] mail [7F4] -> #8614: Mail-Exchanger fw.Domainextern.com... [1664] mail [7F4] -> #8614: Mail-Exchanger IP: 123.123.123.0 [1664] mail [7F4] -> #8614: SendMailToServer fw.Domainextern.com ... [1664] *** SendMailThread: Mail #8614 SendUndeliverableOrWarningMail ... <> [1664] *** SendMailThread: Mail #8614 Sending failed! <> Das Log der Gegenstelle 2014:02:24-13:00:50 fw-1 exim-out[27650]: 2014-02-24 13:00:50 1WHuDK-0007Bv-FZ => userextern@domainextern.com P=<userextern@web.de> R=static_route_hostlist T=static_smtp H=192.168.1.43 [192.168.1.43]:25 X=TLSv1:RC4-MD5:128 C="250 2.6.0 <trinity-130d3449-2e60-4ce4-8ffb-b367ca7ed87c-1393243239288@3capp-webde-bs11> Queued mail " 2014:02:24-13:00:50 fw-1 exim-out[27650]: 2014-02-24 13:00:50 1WHuDK-0007Bv-FZ Completed 2014:02:24-13:01:00 fw-2 exim-out[32593]: 2014-02-24 13:01:00 Start queue run: pid=32593 2014:02:24-13:01:00 fw-2 exim-out[32593]: 2014-02-24 13:01:00 End queue run: pid=32593 2014:02:24-13:01:00 fw-1 exim-out[27702]: 2014-02-24 13:01:00 Start queue run: pid=27702 2014:02:24-13:01:00 fw-1 exim-out[27702]: 2014-02-24 13:01:00 End queue run: pid=27702 2014:02:24-13:01:12 fw-1 exim-in[8795]: 2014-02-24 13:01:12 SMTP connection from [192.168.1.43]:15926 (TCP/IP connection count = 1) 2014:02:24-13:01:12 fw-1 exim-in[27774]: 2014-02-24 13:01:12 [192.168.1.43] F=<userextern@domainextern.com> R=<user@Domain.com> Accepted: from relay 2014:02:24-13:01:14 fw-1 exim-in[27774]: 2014-02-24 13:01:14 1WHuDh-0007Dy-0A ctasd reports 'Unknown' RefID:str=0001.0A0C0201.530B348A.0033,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 2014:02:24-13:01:14 fw-1 exim-in[27774]: 2014-02-24 13:01:14 1WHuDh-0007Dy-0A <= userextern@domainextern.com H=server3.domainextern.local [192.168.1.43]:15926 P=esmtps X=TLSv1:RC4-SHA:128 S=66011 id=F9E4576A5EDDE649BC23715594D19FB901D3B7C422CB@server3.domainextern.local 2014:02:24-13:01:14 fw-1 exim-in[27774]: 2014-02-24 13:01:14 SMTP connection from server3.domainextern.local [192.168.1.43]:15926 closed by QUIT 2014:02:24-13:01:15 fw-1 smtpd[8757]: QMGR[8757]: 1WHuDh-0007Dy-0A moved to work queue 2014:02:24-13:01:16 fw-1 smtpd[27647]: SCANNER[27647]: 1WHuDk-0007Bv-3S <= userextern@domainextern.com R=1WHuDh-0007Dy-0A P=INPUT S=64538 2014:02:24-13:01:16 fw-1 smtpd[27647]: SCANNER[27647]: id="1000" severity="info" sys="SecureMail" sub="smtp" name="email passed" srcip="192.168.1.43" from="userextern@domainextern.com" to="user@Domain.com" subject="AW: Komplikationen E-Mail Versand" queueid="1WHuDk-0007Bv-3S" size="64538" 2014:02:24-13:01:16 fw-1 smtpd[27647]: SCANNER[27647]: 1WHuDh-0007Dy-0A => work R=SCANNER T=SCANNER 2014:02:24-13:01:16 fw-1 smtpd[27647]: SCANNER[27647]: 1WHuDh-0007Dy-0A Completed 2014:02:24-13:01:18 fw-1 exim-out[27795]: 2014-02-24 13:01:18 1WHuDk-0007Bv-3S => user@Domain.com P=<prvs=01326c09be=userextern@domainextern.com> R=dnslookup T=remote_smtp H=mail.Domain.com [123.123.123.123]:25 C="250 Mail accepted" 2014:02:24-13:01:18 fw-1 exim-out[27795]: 2014-02-24 13:01:18 1WHuDk-0007Bv-3S Completed 2014:02:24-13:01:23 fw-1 exim-in[8795]: 2014-02-24 13:01:23 SMTP connection from [123.123.123.123]:23727 (TCP/IP connection count = 1) 2014:02:24-13:01:24 fw-1 exim-in[27846]: 2014-02-24 13:01:24 H=mail.Domain.com [123.123.123.123]:23727 Warning: F=<> R=<userextern@domainextern.com> Missing BATV signature 2014:02:24-13:01:24 fw-1 exim-in[27846]: 2014-02-24 13:01:24 [123.123.123.123] F=<> R=<userextern@domainextern.com> Verifying recipient address with callout 2014:02:24-13:01:24 fw-1 exim-in[27846]: 2014-02-24 13:01:24 [123.123.123.123] F=<> R=<userextern@domainextern.com> Accepted: is a bounce 2014:02:24-13:01:24 fw-1 exim-in[27846]: 2014-02-24 13:01:24 id="1003" severity="info" sys="SecureMail" sub="smtp" name="email rejected" srcip="123.123.123.123" from="" to="userextern@domainextern.com" subject="" queueid="" size="-1" reason="batv" extra="" 2014:02:24-13:01:24 fw-1 exim-in[27846]: 2014-02-24 13:01:24 H=mail.Domain.com [123.123.123.123]:23727 rejected DATA 2014:02:24-13:01:24 fw-1 exim-in[27846]: 2014-02-24 13:01:24 SMTP connection from mail.Domain.com [123.123.123.123]:23727 closed by DROP in ACL 2014:02:24-13:01:46 fw-1 smtpd[27647]: SCANNER[27647]: Nothing to do, exiting. Im Protokoll der Gegenstelle ist die Rede davon, dass die BATV (Bounce Address Tag Validation) Signature fehlt Haben wir es damit quasi "Schwarz auf Weiß", dass die Konfiguration Gegenstelle das Problem ist? Vielen Dank für Eure Unterstützung! Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 24. Februar 2014 Melden Teilen Geschrieben 24. Februar 2014 (bearbeitet) Im Protokoll der Gegenstelle ist die Rede davon, dass die BATV (Bounce Address Tag Validation) Signature fehlt Haben wir es damit quasi "Schwarz auf Weiß", dass die Konfiguration Gegenstelle das Problem ist? Nein, da in Deiner Aufzeichnung eine Lücke ist: G DATA -> Exchange. Ein Auszug aus dem SMTP-Protokoll des Exchange wäre noch interessant. Aber grundsätzlich kannst dem Empfänger an diesem Beispiel nur die Probleme von BATV aufzeigen, die dadurch entstehen, dass es sich bei BATV nicht um einen Standard handelt ("Entwurfs-Stadium") und daher nicht damit gerechnet werden, dass die gegenüberliegenden Seite sich wirklich daran hält. Er wird aber vermutlich nicht an seiner Meinung ändern, dass das Problem bei Exchange ist. Nachtrag: Eigentlich braucht es das Exchange SMTP-Protokoll nicht mehr, weil die wichtigen Infos hier eh nicht drin stehen. Die würden im Header der Mail stehen, auf den die OOF erfolgt (den könntest Du nochmal posten) Nach dem ich mich durch ein paar RFC gelesen habe, ist ziemlich klar: BATV funktioniert für normale DSN laut RFC 3461 prinzipbedingt, weil diese als Envelop-To den String aus MAIL FROM einsetzen müssen, dieser an der Stelle bekannt ist und damit die BATV-Signatur tragen. BATV funktioniert prinzipbedingt nicht für MDN laut RFC 3798, weil diese als Envelop-To keinen alten MAIL FROM mehr kennen und ihn daher auch nicht einsetzen können. MDN können immer nur an Disposition-Notification-To Header gehen oder an "From", falls der nicht gesetzt ist. Wer BATV nutzt, wird also grundsätzlich keine Standard-konformen OOF erhalten und er wird auch keine anderen MDN bekommen, z.B. Lesebestätigungen. Ich wüsste nicht, was Du daran sinnvoll ändern kannst, das ist eine der Schwachstellen von BATV. Schick das dem anderen Admin, eventuell ändert er was. Ich denke das aber eher nicht. bearbeitet 24. Februar 2014 von RobertWi Zitieren Link zu diesem Kommentar
NorbertFe 1.981 Geschrieben 24. Februar 2014 Melden Teilen Geschrieben 24. Februar 2014 Ich hab BATV bei uns deswegen übrigens wieder abgeschaltet. Ich brauch ab und an mal die Übermittlungsbestätigungen. ;) Bye Norbert Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 24. Februar 2014 Melden Teilen Geschrieben 24. Februar 2014 Ja, kann ich nachvollziehen. Ich habe das bisher auch sehr selten irgendwo im Einsatz gesehen, daher muss ich mich immer wieder erst in die Besonderheiten von DSN und MDN einlesen. Zitieren Link zu diesem Kommentar
Knorkator 12 Geschrieben 24. Februar 2014 Autor Melden Teilen Geschrieben 24. Februar 2014 Nachtrag: Eigentlich braucht es das Exchange SMTP-Protokoll nicht mehr, weil die wichtigen Infos hier eh nicht drin stehen. Die würden im Header der Mail stehen, auf den die OOF erfolgt (den könntest Du nochmal posten) Im Log würde ja auch nur stehen, dass der Exchange die Mail an der Mailsecurity abgeliefert hat. Nach dem ich mich durch ein paar RFC gelesen habe, ist ziemlich klar: BATV funktioniert für normale DSN laut RFC 3461 prinzipbedingt, weil diese als Envelop-To den String aus MAIL FROM einsetzen müssen, dieser an der Stelle bekannt ist und damit die BATV-Signatur tragen. BATV funktioniert prinzipbedingt nicht für MDN laut RFC 3798, weil diese als Envelop-To keinen alten MAIL FROM mehr kennen und ihn daher auch nicht einsetzen können. MDN können immer nur an Disposition-Notification-To Header gehen oder an "From", falls der nicht gesetzt ist. Wer BATV nutzt, wird also grundsätzlich keine Standard-konformen OOF erhalten und er wird auch keine anderen MDN bekommen, z.B. Lesebestätigungen. Ich wüsste nicht, was Du daran sinnvoll ändern kannst, das ist eine der Schwachstellen von BATV. Schick das dem anderen Admin, eventuell ändert er was. Ich denke das aber eher nicht. Der andere Admin prüft nun seine Einstellungen. Ich melde mich noch und gebe einen "Abschlussreport" Entweder es wird geändert oder ich muss meine Mitarbeiter entsprechend informieren. Vielen vielen Dank für Eure Bemühungen! Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 24. Februar 2014 Melden Teilen Geschrieben 24. Februar 2014 Im Log würde ja auch nur stehen, dass der Exchange die Mail an der Mailsecurity abgeliefert hat. Ja, aber es würde da auch stehen, mit welchem MAIL FROM er das getan hat. Mein Verdacht war, dass hier die BATV Signatur verloren geht. Beim Nachlesen habe ich aber bemerkt, dass das bei OOF egal ist. Diese gehen als MDN nicht an den MAIL FROM zurück, da dieser an der Stelle des Erzeugens gar nicht mehr bekannt sein muss. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.