Probleme mit Email Protection mit der Version 9.603-1 ?

Question

Hallo zusammen,

ich habe am 05.06. die Firmware auf 9.603-1 aktualisiert und seit zwei Wochen bekomme ich als Rückmeldungen, das manchmal E-Mails von Kunden nicht ankommen.

Der Kunde schickt z.B eine E-Mail an drei Empfänger (drei Abteilungen bei uns). Zwei kommen an, die dritte E-Mail fehlt. Laut SMTP Log nur zwei E-Mails empfangen... wo ist die dritte?

Hat jemand auch das Problem mit der neuen Version oder ist das jetzt nur ein zufall und das Problem liegt wo anders?

Kann ich irgendwie die Firmware downgraden?

Vielen Dank!

This thread was automatically locked due to age.

Alexander Busch · Accepted Answer

Toliik said: 
 Danke f&uuml;r deine Antwort. 
 Ich hatte noch keinen Kontakt mit der IT vom Kunden. Werde ich aber wahrscheinlich tun m&uuml;ssen, wenn es wieder vorkommt. 
 
 Wei&szlig;t du zuf&auml;llig was man beim downgrade beachten muss, wenn man zwei Ger&auml;te (aktive-passive) hat? 
 Unter https://www.sophos.com/en-us/support/utm-downloads.aspx kann man nur die aktuelle Firmware oder 9.510 und &auml;lter herunterladen. Also muss ich 9.510 herunterladen und installieren. Und dann auf 9.602-3 updaten? 
 
 Korrekt, wenn Du das passende ISO nicht mehr hast bzw. es f&uuml;r diese Version vielleicht keines gab, mu&szlig;t Du die 9.510 nehmen installieren und dann die Updates bis zur gew&uuml;nschten Zielversion durchf&uuml;hren. 
 Wenn Du einen Cluster hast w&uuml;rde ich diesen aufl&ouml;sen, auf dem inaktiven Node die Version installieren, Updates und Restore des Backups und dann die Umschaltung vornehmen. Bitte beachte, dass Du hierbei sicherlich einen kurzen Ausfall hast. Im Anschluss Node 2 downgraden und Cluster wieder herstellen. 
 Alles also nicht ganz so einfach und die Arbeit m&uuml;sste schon durch einen triftigen Grund gerechtfertigt werden. 
 Vielleicht als Tipp f&uuml;r die Zukunft, man kann beim Upgrade einen Knoten/Node zur&uuml;ckhalten. Dies mache ich selbst immer so, somit kann man zumindest einige Tage das Verhalten beobachten und erst dann den zweiten Knoten updaten. Eine sinnvolle Funktion, da das Downgrade nicht wirklich simpel ist. 
 
 Beste Gr&uuml;&szlig;e 
 Alex

ThorstenSult · Answer

Hast Du Euren MX schon gepr&uuml;ft? M&ouml;glicherweise hast Du einen BackupMX, der in Nirvana zeigt?

BAlfson · Answer

Hallo Toliik, 
 (Sorry, my German-speaking brain isn't creating thoughts at the moment. [:(]) 
 You are correct that greylisting causes a temporary delay and that the resend is automatic. I haven't recommend greylisting for years, but others whom I respect do, so I'm experimenting with it again. I saw a 2018 study where roughly 2/3 of greylisted emails were finally delivered, with 1/3 not retried - one assumes those were from spammers. One of my clients that uses greylisting saw only 56% retried successfully so far in June. 
 I had thought that the SMTP Proxy used only the triad of sending IP, sender and recipient, but I realize now that it also uses the subject. This means that greylisting occurs after DATA, so that's after rejections for RBL, rDNS/HELO, local Blacklists, Recipient verification and SPF. I also see ctasd reports 'unknown' in the line above the greylisted message, so we know that the temporary rejection occurs after the anti-spam tests that would result in rejection have been passed. The advantage is that malware scans, which are expensive, are skipped unless the message is resent and accepted. 
 There are situations where Exceptions for greylisting should be made such as addresses to which orders are sent where there's a cut-off time. Also, mailing services like Constant Contact will use a different IP virtually every time a greylisted email is resent. 
 MfG - Bob (Bitte auf Deutsch weiterhin.)