mail with attachment not received

Home Forums Messaging Software Exchange 2007 / 2010 / 2013 mail with attachment not received

Viewing 1 post (of 1 total)
  • Author
  • Avatar

    following scenario is “stumping me” (well, I think i know where the issue lies, but i need to be able to conclusively prove it.)


    • Customer. This is our customer.
    • External. This is a remote user who is trying to email attachments to our customer (‘hosted’ email wih crazydomains)
    • Support. This is our support email system (O365, EMEA)
    • 3rdparty. This is a 3rd party email system (0365, APAC)


      • Customer – has an Exchange 2010 server, all fully up to date. It’s running bitdefender security for exchange. There is no attachment filtering configured.
        There is no antispam, ip allow, ip block list configured on the connectors.
        The connectors are configured to allow 20MB files. There’s only one internet-facing connector on port 25. There is no additional antispam engines or services or anythng like that. Email generally works.
      • External – uses CrazyDomains for their email. email sends via the crazydomains smtp server. (Alternately, he sometimes sends via optus or telstra servers)
      • Support – Plain old office365.
      • 3P – plain old office365. no special antivirus, filtering or anything.

      External is trying to send a 6MB PDF file to Customer. Email is not being received. External is getting bounce message after 72 hours:

      A message that you sent could not be delivered to one or more of its
      recipients. This is a permanent error. The following address(es) failed:

      ([email protected])
      retry timeout exceeded

      This is a copy of the message, including all the headers.

      The body of the message is 8639488 characters long; only the first

      106496 or so are included here.

      If the external user sends an emai lwithout an attachment to [email protected] – it is received.
      If the external user sends an email with same attachment to @support – it is received
      If Support forwards the same email on to @customer, it is received.
      If External sends to @customer from optus, it is received
      If external sends to @customer from telstra, it is received.

      in the Tracking logs, I’m not seeing any sign of it ever appearing. So I’ve turned on SMTP logging.
      So far, I haven’t seen anything (he just recently resent the email)

      in theory, if the External server is attempting to connect to the SMTP instance, I should at least see entries in the SMTP log showing the connect was attempted ?

      Regardless of how Bitdefender handles it after that, correct ? (SMTP receives then bitdefender processes higher up the stack, submission layer?)

      I know Simon’s first suggestion will be fully remove bitdefender, but before we go hammer and tongs at that, I want to be firmyl sure there’s nothing else we can do.

      (as an interesting side note, the external user’s email hosting has said “oh, it’s not us, it’s the other end – they need to whitelist your domain.”
      yet they cannot explain why emails without attachments are being received.

      some thoughts:

      – the PDF is copy protected and antivirus can’t scan, so won’t allow it through on the customer side (but then it should reject it from everyone)
      – the pdf is copy protected and antivirus can’t scan so it’s not transmitted from external side (then why do Support receive it?)
      – the receive connector is wrong somehow (so how is it received from one place but not another?)

      I’m fairly confident that for some unknown, assabout, stupid fucking god knows why reason that crazydomains usually have, they are fucking it up. problem is getting past the 1st line gatekeeper who hear”not delivered” and say”not us, sorry, ticket closed”

      what I AM Seeing in the exchange logs so far is Tarpitting – i don’t know if turning this off might help? (in which case, I should create a separate connector scoped to the sending server?)

Viewing 1 post (of 1 total)

You must be logged in to reply to this topic.