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.
I would suggest 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.
Timothy John C. Padrigon commented
Hi this is a needed features kindly prioritize this request even if this is not yet your priority.
Rachel Hewitt commented
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 Meier commented
same here, either a more timely "delayed delivery" report to the sender and/or a configurable timeout would be terrific.
one of my customers didn't realize that e-mails could not be sent for two days and they missed a deadline.
we are reading this, but this currently is only the 278th most wanted feature, therefore it is hopefully somehow obvious that it is not top our lists right now.
Sad but true. Probably noone reads this - at least noone who understands how critical this can be.
PWA Wish List Admin commented
This could do with a comment by now from the astaro team..... anyone reading this?
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.
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 :-(
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...?!
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.
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 Hidalgo commented
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 Alfson commented
Rather than "kill" the too-large message in contradiction to standards, why not continue to attempt other emails even to the same server?