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.
Michael Störzbach commented
Obviously, fast informing if outbound email is forwarded/can be forwarded is generally important. However, it is also an advantage in case of a server issue or a prolonged period of non-working days (Easter, Christmas etc) that the _received_ emails may still be delivered once servers are up again (or the competent people are working again, the link is up again), or the messages are at least still available: Deleting such emails appears to be somehow inequal compared with dubious mail which are retained in quarantine whereas valuable messages are discards after only 3 days.
Hence, for received emails, I would appreciate if in a situation where emails cannot be forwarded, they are not deleted, but kept available on the same level as quarantine. Regarding the retry time, it may be split in a time to inform the sender, and a time after which the email is deemed not deliverable (yet retained in "quarantine"). Deleting valuable, not easily retrievable data like received emails appears to be a quite harsh, strong means - of course, IMHO.
Possibilty to configure Mail Retry time after Targetserver is not reachable.
Currenttly there is a fixes timeout of about 3-4 Days - which ought to be configurable for special cases (maybe seperated in the mail profiles?)
Der Wiederholungszähler ist auf zu lange Wartezeit eingestellt. Der Anwender erwartet heute innerhalb weniger Minuten bzw. maximal 1 Tag die Rückmeldung wenn Mail nicht zustellbar war.
So oder so, jedes Unternehmen muss die Möglichkeit haben selber darüber zu entscheiden welches Zeitfenster tragbar ist.
David Kaiser commented
We need it too!!! A more timely "delayed delivery" report to the sender and/or a configurable timeout would be terrific.
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?