This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[Bug] - wrong handling sending mails - extreme delays

Hi there,

just want to let you know what we and our partner independently found out:
Remember this if you troubleshoot problems concerning sending mails to just a few special domains.

Imagine a mis-configured mailserver on the net - and there are some - that just drop a connection when one of the receiving criteria is not matched. In our cases we saw the following: if a mail is larger than the receiving-smtp limit of e.g. 10MB the receiving server drops the connection - without any smtp response. (bad behavior of the receiving server)

Here is what Astaro does: resend the 10MB Mail for 24 hours (!) a 100 times creating some GB mailtraffic - before it sends a first "message delayed" information to the user. This goes on until day 3 - when the message will be bounced by the Astaro.

As if this wasn't enough of bad mail handling another important thing happens: 
the Astaro is working down the mailqueue from top down - trying to resend the problematic mail first (as we know: unsuccessfully) and caches this mailserver as unreachable - resulting in OTHER (small / receiving-criteria-matched) mails to the same domain in NEVER BEING TRIED TO SEND - the mailqueue grows...

As you can imagine this is disastrous for messaging: users are sending their mails a whole day long and this *one* message causes all other messages not being delivered. So after 24 hours the "bad-mail" sender receives the "message delayed" message - and if no one cares about the mailtransport after this informational mail, there is a delay of three days until the first messages to the *working* receiver-SMTP-Server are getting *started* being delivered.

This could be called a partial DOS - unintentionally and very easy to "exploit" from internal side...

Due to this is not a bug regarding to Astaro support this had to be delivered as a feature request.

In the feature-request forum I suggested to implement a "maximum-transmission-attempts" counter that bounces the mail if sending has *successfully* begun and has been aborted more then ... lets say 10 times. 

Hope you will never stumble upon this,

Best regards,

Thomas


This thread was automatically locked due to age.
Parents
  • Hi, Thomas, I voted for your request.  Rather than "kill" the too-large message in contradiction to standards, why not continue to attempt other emails even to the same server?

    Cheers  - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • Hi, Thomas, I voted for your request.  Rather than "kill" the too-large message in contradiction to standards, why not continue to attempt other emails even to the same server?

    Cheers  - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
No Data