Message contains invalid header Meldung bei ganz bestimmter Mail von Avaya

german
postfix

#1

Hi,

haben ein seltsames Problem mit einem Univention Postfix, der bestimmte Mails nicht weitergibt, da angeblich der “header invalid” sei.
Beispielsweise bei web.de und an unseren eigenen Server gehen die entsprechenden mails aber sauber ein.

Der header der Mail sieht folgendermaßen aus:

Return-Path: <pldsnotify@avaya.com>
Delivered-To: zucca@systemschmiede.com
Received: from localhost (localhost.localdomain [127.0.0.1])
	by ohoco-host.ohoco.de (Postfix) with ESMTP id 722CC1C0E78
	for <zucca@systemschmiede.com>; Mon,  6 Nov 2017 10:22:13 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mail.ohoco.de
Received: from ohoco-host.ohoco.de ([127.0.0.1])
	by localhost (ohoco-host.ohoco.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id sKV6v4HXspZU for <zucca@systemschmiede.com>;
	Mon,  6 Nov 2017 10:22:11 +0100 (CET)
Received-SPF: none (avaya.com: No applicable sender policy available) receiver=mail.ohoco.de; identity=mailfrom; envelope-from="pldsnotify@avaya.com"; helo=de307622-de-outbound.net.avaya.com; client-ip=198.152.71.100
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100])
	by ohoco-host.ohoco.de (Postfix) with ESMTPS id 511591C0D84
	for <zucca@systemschmiede.com>; Mon,  6 Nov 2017 10:22:08 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2F6AAAQKQBa/yYyC4dbGQEBAQEBAQEBA?=
 =?us-ascii?q?QEBBwEBAQEBgkRCLmQxPSeOHHSOJYR3gVOReBCBPkMHFhKBXIM6I4Q7PxgBAQE?=
 =?us-ascii?q?BAQEBAQEDaCiCakchBTIBAQEBAQEBAQEBAQEBAQEBAQEXAgg2EgEyGzkREBorJ?=
 =?us-ascii?q?HyHaIE0ZRCfeIk2EYNKIQIDimABAQgBAQEBAQETFIEdggyBECVSgzyGTAgUgRY?=
 =?us-ascii?q?hBAIiCg0CBweCdQSCSwWKE4dLUUKPCxKEQoMkg2eLRF+FJIN3DYcWAoxhimkFD?=
 =?us-ascii?q?xA5gWx6gzIBAQ4JCoJECheCBVkBiVEsghYBAgM?=
X-IPAS-Result: =?us-ascii?q?A2F6AAAQKQBa/yYyC4dbGQEBAQEBAQEBAQEBBwEBAQEBgkR?=
 =?us-ascii?q?CLmQxPSeOHHSOJYR3gVOReBCBPkMHFhKBXIM6I4Q7PxgBAQEBAQEBAQEDaCiCa?=
 =?us-ascii?q?kchBTIBAQEBAQEBAQEBAQEBAQEBAQEXAgg2EgEyGzkREBorJHyHaIE0ZRCfeIk?=
 =?us-ascii?q?2EYNKIQIDimABAQgBAQEBAQETFIEdggyBECVSgzyGTAgUgRYhBAIiCg0CBweCd?=
 =?us-ascii?q?QSCSwWKE4dLUUKPCxKEQoMkg2eLRF+FJIN3DYcWAoxhimkFDxA5gWx6gzIBAQ4?=
 =?us-ascii?q?JCoJECheCBVkBiVEsghYBAgM?=
X-IronPort-AV: E=Sophos;i="5.44,351,1505793600"; 
   d="xml'217?scan'217,208,217";a="222996476"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38])
  by de307622-de-outbound.net.avaya.com with ESMTP; 06 Nov 2017 04:22:06 -0500
X-OutboundMail_SMTP: 1
Received: from pwpldvmap03.avaya.com (HELO PWPLDVMAP03) ([135.11.113.160])
  by p-us1-erheast-out.us1.avaya.com with SMTP; 06 Nov 2017 04:22:06 -0500
Message-ID: 
Date: Mon, 6 Nov 2017 04:22:06 -0500 (EST)
From: pldsnotify@avaya.com
To: zucca@systemschmiede.com
Subject: AVAYA PLDS - Activation Notification
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="227011748.1509960126405.JavaMail.svcpoeticapp@PWPLDVMAP03"

--227011748.1509960126405.JavaMail.svcpoeticapp@PWPLDVMAP03

die Fehlermeldung im Log lautet

Nov  6 10:31:54 ucs postfix/smtpd[12404]: connect from co300216-co-outbound.net.avaya.com[198.152.13.100]
Nov  6 10:31:56 ucs postgrey[1143]: action=pass, reason=client whitelist, client_name=co300216-co-outbound.net.avaya.com, client_address=198.152.13.100, sender=pldsnotify@avaya.com, recipient=info@dipo.de
Nov  6 10:31:56 ucs postfix/smtpd[12404]: 2F827627059: client=co300216-co-outbound.net.avaya.com[198.152.13.100]
Nov  6 10:31:56 ucs postfix/cleanup[13086]: 2F827627059: message-id=
Nov  6 10:31:57 ucs postfix/qmgr[12403]: 2F827627059: from=<pldsnotify@avaya.com>, size=28801, nrcpt=1 (queue active)
Nov  6 10:31:59 ucs postfix/smtpd[13100]: connect from localhost[127.0.0.1]
Nov  6 10:31:59 ucs postfix/smtpd[13100]: 3041162705F: client=localhost[127.0.0.1], orig_queue_id=2F827627059, orig_client=co300216-co-outbound.net.avaya.com[198.152.13.100]
Nov  6 10:31:59 ucs postfix/cleanup[13086]: 3041162705F: message-id=
Nov  6 10:31:59 ucs postfix/smtpd[13100]: disconnect from localhost[127.0.0.1]
Nov  6 10:31:59 ucs postfix/qmgr[12403]: 3041162705F: from=<pldsnotify@avaya.com>, size=29524, nrcpt=1 (queue active)
Nov  6 10:31:59 ucs amavis[7221]: (07221-09) Passed CLEAN {RelayedInbound}, [198.152.13.100]:26192 [135.11.113.160] <pldsnotify@avaya.com> -> <info@dipo.de>, Queue-ID: 2F827627059, mail_id: qww3OD1hZNCb, Hits: -6.177, size: 28800, queued
_as: 3041162705F, 1908 ms
Nov  6 10:31:59 ucs cyrus/master[13102]: about to exec /usr/lib/cyrus/bin/lmtpd
Nov  6 10:31:59 ucs postfix/smtp[13097]: 2F827627059: to=<info@dipo.de>, relay=127.0.0.1[127.0.0.1]:10024, delay=3.3, delays=1.4/0.02/0/1.9, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 3041
162705F)
Nov  6 10:31:59 ucs postfix/qmgr[12403]: 2F827627059: removed
Nov  6 10:31:59 ucs cyrus/lmtp[13102]: executed
Nov  6 10:31:59 ucs cyrus/lmtp[13102]: accepted connection
Nov  6 10:31:59 ucs cyrus/lmtp[13102]: connection from localhost [127.0.0.1] preauth'd as postman
Nov  6 10:31:59 ucs postfix/lmtp[13101]: 3041162705F: to=<info@dipo.de>, relay=127.0.0.1[127.0.0.1]:2003, delay=0.05, delays=0.03/0.01/0.02/0, dsn=5.6.0, status=bounced (host 127.0.0.1[127.0.0.1] said: 554 5.6.0 Message contains invalid
header (in reply to end of DATA command))
Nov  6 10:31:59 ucs postfix/cleanup[13086]: 38A1C627060: message-id=<20171106093159.38A1C627060@ucs.dipo.intranet>
Nov  6 10:31:59 ucs postfix/bounce[13103]: 3041162705F: sender non-delivery notification: 38A1C627060
Nov  6 10:31:59 ucs postfix/qmgr[12403]: 38A1C627060: from=<>, size=31490, nrcpt=1 (queue active)

Wie kriegen wir es hin, dass die Mails von pldsnotify@avaya.com sauber zugestellt werden?

Danke
Sascha


#2

Hi,

wirklich niemand?
Ich hätte gedacht, dass schon mal jemand so ein Problem gehabt hätte, oder?
Würden uns sehr freuen.

Danke
Sascha


#3

Das Problem ist nicht Postfix, der die Mail ablehnt. Das Problem tritt vielmehr auf, wenn Postfix versucht, die Mail an Cyrus zuzustellen, und Cyrus ist derjenige, der die Fehlermeldung erzeugt. Konkret:

Hier steht eindeutig host 127.0.0.1[127.0.0.1] said: …, also informiert uns Postfix darüber, dass der Partner, mit dem er gerade kommuniziert, die folgende Meldung ausgibt.

Meine Vermutung ist, dass sich Cyrus an der leeren Message-ID-Zeile stört. Das gab wurde z.B. hier thematisiert. Was man also machen muss, ist Postfix dazu zu bringen, solche Header-Zeilen zu entfernen. Wie das allgemein funktioniert, ist hier gut beschrieben.

Unter Univention sollte man natürlich nicht die main.cf direkt anfassen, weil die aus Templates erzeugt wird und manuelle Änderungen somit verloren gingen. Es gibt leider bisher auch noch keine UCR-Variable, mit der man die header_checks einschalten könnte. Also muss man ein eigenes UCR-Template-Schnippsel erstellen und UCR bekannt machen, dort die header_checks = …-Zeile eintragen und anschließend die main.cf neu erzeugen lassen.

Gruß
mosu


#4

hi,
klingt gut.
um zu testen ob das grundsätzlich ginge, reicht temporär
header_checks = regexp:/etc/postfix/maps/header_checks
in der main.conf
und dann
/^Message-ID:[[:space:]]*$/ IGNORE
in der entsprechenden
/etc/postfix/maps/header_checks?
Danke
Sascha


#5

Hi,

also testweise hat es nun genau so geklappt wie oben beschrieben.
Aber ich gebe offen zu, dass mich die Erstellung eines eigenen template snippets nebst Registrierung gerade ansatzweise überfordert. :slight_smile:
Wäre cool, wenn Ihr mir gerade noch einen Stuppser geben könntet.

Ausgehend vomThread Eigene Template-Files registrieren bin ich bisher folgendermaßen vorgegangen:

  • in die Datei /etc/univention/templates/info/univention-mail-postfix.info folgendes einfügen:
    Type: subfile
    Multifile: etc/postfix/main.cf
    Subfile: etc/postfix/main.cf.d/custom

  • Datei /etc/univention/templates/files/etc/postfix/main.cf.d/custom mit folgendem Inhalt erstellen:
    @!@
    header_checks = regexp:/etc/postfix/header_checks
    @!@

  • Datei /etc/postfix/header_checks erstellen mit folgendem Inhalt:
    /^Message-ID:[[:space:]]*$/ IGNORE

  • und jetzt? Wie registriere ich das alles jetzt?
    in der Anleitung http://docs.software-univention.de/developer-reference.html#ucr:build scheitere ich schon dabei debian/rules zu finden.

Ich stelle mich mit Sicherheit einfach nur blöd an, aber vielleicht hilft mir trotzdem gerade jemand…
Danke
Sascha


#6

niemand?
Ist das so logisch alles und ich bin der einzige, der es nicht kapiert?
eiii…das wäre dann aber auch tragisch…
:slight_smile:
schönes WE Euch allen
Sascha


#7

Ich würde auf jeden Fall nicht die Temaple Registrierungsdatei anpassen, sondern einfach eine eigene erstellen, bspw. univention-mail-postfix-my.info.

So sollte es funktionierten:

echo -e "Type: subfile\nMultifile: etc/postfix/main.cf\nSubfile: etc/postfix/main.cf.d/custom" >/etc/univention/templates/info/univention-mail-postfix-my.info

echo -e 'header_checks = regexp:/etc/postfix/header_checks\n' >/etc/univention/templates/files/etc/postfix/main.cf.d/custom

rm /var/cache/univention-config/cache 

ucr commit /etc/postfix/main.cf

BTW, ich denke https://forge.univention.org/bugzilla/show_bug.cgi?id=44473 ist schon in der QA und sollte das Handling für die main.cf vereinfachen.


#8

sehr cool,
Danke
Sascha


#9

Noch mal nachträglich. Ein paar Wochen nach diesem Thema habe ich einen Blog-Post geschrieben, in dem ich erläutere, wie Template-Dateien funktionieren, wie man eigene hinzufügt etc. Vielleicht ist das für die Zukunft noch mal hilfreich.


#10

Wow!
sehr cool, Danke

lg
Sascha