Do you recognize a good idea when you see one? We want to hear from you!
Header Image

I suggest you ...

Mail Protection: Configurable SMTP Retry Timeout

A feature to allow administrators to reduce the SMTP relay Retry Timeout Limit would be excellent. Very useful for freight business who rely on email to get CON notes out quickly.

113 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Simon HughesSimon Hughes shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    ThomasThomas shared a merged idea: Mail Security: Configurable Parameters for Retries  ·   · 

    12 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Rachel HewittRachel Hewitt commented  ·   ·  Flag as inappropriate

        For a law firm, time is of the essence. Not knowing about a problem email for 48 hours has caused a deadline to be missed. Luckily it did not cause damage to our client. Please add this feature now.

      • Markus MeierMarkus Meier commented  ·   ·  Flag as inappropriate

        same here, either a more timely "delayed delivery" report to the sender and/or a configurable timeout would be terrific.

      • Anonymous commented  ·   ·  Flag as inappropriate

        +1
        one of my customers didn't realize that e-mails could not be sent for two days and they missed a deadline.

      • ThomasThomas commented  ·   ·  Flag as inappropriate

        Sad but true. Probably noone reads this - at least noone who understands how critical this can be.

      • ThomasThomas commented  ·   ·  Flag as inappropriate

        Just to mention: Problem No.2 (as this wasn't enough...) also happens with traffic TO the internal mailserver :-)

        We saw that accidentally: an IPS rule triggered (false positive) and dropped (answer-) packets from our mailserver to the astaro, while the ASG tried to forward an email to the internal mailserver.

        Result:
        this incoming email that could not be forwarded to our internal mailserver made the ASG "think": This Mailserver is unreachable - will try in 15 minutes.
        All other mails to our internal server stay down in the queue as mentioned in the OP (marked as: mailserver unreachable - won't try delivering all the other mails).
        15 minutes later, starting with the same "first" email in the queue again just to realize - surprise - it can't be delivered. Keeping the rest of the mails in the spool for days - if nobody cares for the IPS logs.

        Still not-a-bug, I guess :-(

      • ThomasThomas commented  ·   ·  Flag as inappropriate

        Any news here? This bug is known for more than one year now. *Bug* - not feature request - due it leads to a 3-days DOS...?!

      • ThomasThomas commented  ·   ·  Flag as inappropriate

        I still can't understand why this is not considered as a bug. They'd better disable this "unreachable hosts cache" than living with that "not-a-bug". I am sure if they had faced such a situation themselves they would think different about it.

      • BrucekConvergentBrucekConvergent commented  ·   ·  Flag as inappropriate

        I've reported this to Astaro as well; currently the workaround I use (that works) is twofold; I limit email size to under 10MB at the customer's Exchange Server and / or in the ASG, and I also add a QoS rule that limits the bandwidth to yahoo's email servers to a 100Kb/s or so.

      • Jose HidalgoJose Hidalgo commented  ·   ·  Flag as inappropriate

        That problem is just what I have right now with outgoing mails to Yahoo. For some reason the connection fails, so the Astaro resends all day long creating about 10 GB traffic a day, only by mails send to Yahoo, so the bandwidth get saturated 24 hour a day. I think this is a weakness that can be easly exploited to cause a DOS. Astaro must resolve this problem.

      • Bob AlfsonBob Alfson commented  ·   ·  Flag as inappropriate

        Rather than "kill" the too-large message in contradiction to standards, why not continue to attempt other emails even to the same server?

      Feedback and Knowledge Base