2

This is an example:

Remy Blättler (Supertext AG)@pps.reinject <=?UTF-8?Q?Remy_Bl=C3=A4ttler_=28Supertext_AG=29?=@pps.reinject>

We are using Office365 to send out our email, but this is usually when we get emails back from clients. And this is not only for one client. We use Outlook 2016 on the Desktop.

From a Google search I found Proofpoint Protection Server. But that does not really explain much...

Any idea what could be wrong? And on which side?

Remy
  • 117
  • 2
  • 3
  • 12
  • Can you add more details such as 'all clients' or 'some clients' and if you're using 365 in outlook desktop client, outlook web client and/or 3rd party or manually configured SMTP client. – Jacob Evans Dec 01 '20 at 00:47
  • Hasn't happen in a while, but it was for some clients. We use Outlook Desktop mainly – Remy Dec 02 '20 at 14:21
  • 1
    likely an issue on their end, someone reported and resolved. (proofpoint) and likely a DNS issue with resolving your domain's SPF or DKIM records which would then reject your messages to their quarantine system which could also be down and thus returning back to you instead? totally guessing :) – Jacob Evans Dec 02 '20 at 14:30
  • Possible. Hasn't been reported in a while. But if it happens again, I'll look into those points – Remy Dec 03 '20 at 15:38

1 Answers1

1

this is related to so called mailsploit-attack

background: the rfc1342 allow to utf-8 / base64 encode messages in the smtp fields. most MTA (mail-transfer-agents) only analyse the domains after a @-character. so an attacker tries to subvert the security rules on a MTA by spoof that the mail is coming from pps.reinject (the proofpoint email sandbox).

sources: https://www.rfc-editor.org/rfc/rfc1342 mailsploit.com

Community
  • 1
bypass1
  • 21
  • 1
  • 3
    this could use some more explanation - in OP, both encoded and plaintext domains equal, so its not quite clear why how this could result in an attack – anx Oct 11 '19 at 10:42