• Bewerte uns auf OMR Reviews: Klick

  • NSP Forum als App inkl. Push Nachrichten (iOS): Klick

  • Wichtige Information für alle, die noch nicht auf v14.0.5.39 sind:

    Cyren Antimalware kann nicht mehr verwendet werden. Unsere Lizenz ist endgültig deaktiviert, so dass der Dienst nicht mehr nutzbar ist.
    Bitte stellt sicher, dass ihr schnellstmöglich auf die aktuelle Version aktualisiert. Bis es so weit ist, empfehlen wir die Cyren Antimalware Aktion zu deaktivieren und mindestens den lokalen Virenscanner zu aktivieren. Sollte kein anderer Scanner als Cyren aktiv sein, kommt es unweigerlich zur Abweisung von E-Mails.

    Zusätzlich raten wir dazu, die Cyren Filter zu deaktivieren, hier ist der Einfluss zwar geringer, solange alle anderen Filter korrekt durchlaufen, aber im Problemfall kommt es ebenfalls zur Abweisung.

     

    Unser Blogbeitrag wird in Kürze ebenfalls aktualisiert.

    Beste Grüße
    Euer NoSpamProxy Team

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagatracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

NSP stellt eMail an Ersatzadresse zu, obwohl Zieladresse funktional

ZZB

Member
hallo allerseits,

ich habe hier ein seltsames verhalten im nospamproxy 13.2:

teilweise werden emails, die von einem empfangskonnektor via pop3 reingeholt werden, an die konfigurierte ersatzadresse im internen exchangeserver weitergeleitet, anstatt an den ursprünglichen empfänger (ebenfalls im internen exchange).

in der nachrichtenverfolgung wird dann bei den betroffenen emails die im empfangskonnektor hinterlegte ersatzadresse als empfänger genannt. der originale empfänger einer solchermaßen
behandelten email taucht im nospamproxy nirgendwo auf und ist nur noch an der nennung des agierenden empfangskonnektors erkennbar. okay, und natürlich dann in den headern der bei der ersatzadresse aufgelaufenen email.

ein bestimmtes muster, nachdem NSP mal die vorbestimmte, mal die konfigurierte ersatzadresse benutzt, ist für mich nicht erkennbar, außer, daß bei allen diese emails folgender header enthalten ist:
X-NoSpamProxy-Rating: ***

gibt es - außer dem offensichtlichen grund einer nichtzustellbarkeit - bei dieser funktion noch andere mitbestimmende gründe für die auswahl der ersatzadresse zur mailzustellung?

die konfigurierte ersatzadresse ist bei allen unseren angelegten empfangskonnektoren identisch. theoretisch ist diese hinterlegung einer ersatzadresse relativ sinnlos, zumal jeder angelegte empfangskonnektor genau nur ein konkretes postfach bei einem deutschen full-service-provider abruft - und die emailadresse eines solchen postfaches entspricht genau der emailadresse des empfängers im internen exchange (domainname = AD name). der fall, daß ein bestimmter empfangskonnektor eine email abruft, die kein korrespondierendes postfach im weiterleitungsziel exchange findet, kann nur dann eintreten, wenn entweder das postfach auf dem exchange gelöscht oder umbenannt wurde. kommt kaum vor -> aber es kam schon vor.

von daher würde ich gerne die funktion, daß der empfangskonnektor etwas nach intern UNzustellbares an eine interne ersatzadresse umroutet, beibehalten, habe jetzt aber als workaround erstmal in allen empfangskonnektoren (38 stück) die option gesetzt, daß alle emails der ersatzadresse zugestellt werden, wobei ich als ersatzadresse jeweils die eigentliche emailadresse im exchange angegeben habe. ich hätte auch die ersatzadresse einfach nur aus ihrem feld zu löschen brauchen - aber dann wüsste ich nicht, ob NSP weiterhin scheinbar wahllos emailzustellungen nach intern exchange als nicht möglich ansieht und die email dann nicht mal mehr an der ersatzadresse ankommt.

ich bin sehr auf alle antworten gespannt und bedanke mich schonmal im voraus für die aufgewandte zeit zum lesen meines problemes!
angenehme tage und einen guten rutsch!
 
Hallo,
wenn NoSpamProxy beim POP3-Abruf die Empfänger-Adresse nicht findet, scheint sie zumindest nicht in einem der Header-Einträge enthalten gewesen zu sein, die wir auswerten. Mit V14 haben wir die unterstützten Header noch erweitert, möglicherweise ist das schon die Lösung des Problems. :)
Gruß Stefan
 
Zurück
Oben