I was testing quota functionality and when I sent a message to a user that was over quota it properly sent the over quota warning to that user, and held the message in mail.box where it was retrying delivery.
So I attempted to use Message Recall to get the message back, and it could not recall the message from mail.box. A message on the server console appears several minutes later: “Message 77046798 for Wayne Gretzky/DAOS failed to be recalled by Mark Lepisto/DAOS”.
Seems like message recall should have seen that message in the mail.box and recalled it from there also.
Both the message and the recall request stayed in mail.box until I raised the quota - then the message was delivered and immediately recalled.
Subject: That’s expected behavior
When we developed this feature (8.0), we wanted to minimize any differences between the normal sequence (delivery before recall) and other sequences (e.g. your quota delay, or even the recall request getting to the server before the message being recalled due to different routing paths). This ensures we wouldn’t run into differences in logging, or if there were any agents or 3rd party products (message retention, etc.) that would normally expect to process all delivered messages during delivery under the two scenarios.
So the implementation has the recall request queued up in the router if the target message hasn’t been delivered yet, and executed immediately after delivery. It does mean that the message hits the recipient’s mail file for an instant before being recalled, but that’s exactly the behavior you would have experienced if the mail file didn’t happen to be over quota.
Mike