Is it a good idea to reduce the give-up time for e-mail delivery?

Why shouldn't you give up delivering email after one day? One good reason is weekends.

Email is not now, and never was, particularly reliable. In the early days of the Internet, the 1980s, it was entirely possible for email to take a couple of days just to reach its destination, what with some network links not being 24x7, over expensive long distance dialup calls (back then it cost per minute to call two towns away, nevermind the cost of a call from Sydney to Los Angeles), or even over amateur radio. As a result, it could take a while to deliver email, and the protocols had to cope with unreliable and part-time connections. They do this very well, but even then, mail could get delayed or lost.

Certainly today, email has an illusion of reliability, if only because the underlying transports are more reliable, and many uninformed people (like most of our users) have an expectation that it is reliable, but that expectation does not match reality. Without a significant change to email delivery protocols, which will probably never happen, email, like anything built by humans, will always be less than 100% perfect.

Sometimes, we sysadmins take advantage of that.

For instance, in an office where everyone is only there Monday-Friday, I can have an email outage lasting all weekend if necessary. Of course, it virtually never is necessary to be out that long, but I have had to have email down for over 24 hours in rare cases.

In such a case, if you give up after 24 hours, email sent Friday afternoon may not reach its recipient. The sender won't find out until Monday morning, but if you had kept trying, the recipient would have had it by Monday morning.

Further, it's very important to set user expectations appropriately. The fact that Internet email is not and never will be 100% reliable needs to be clearly understood, even as we like to think that it is.

The RFC says you should keep trying, precisely because things go wrong, and it's intended that the mail be delivered eventually, if possible, but at some point you do have to give up. It might be OK to reduce this to three days. I've always thought five days was too long to wait for delivery for most messages on a 24x7 Internet.

As for your given mail server:

Postfix can notify senders when an email message has been delayed, but this feature is turned off by default. This warning should be sufficient to let your users know that something might have gone wrong, such as a mistyped email address, and will arrive much sooner than the 24 hours your boss has proposed.

To enable it, set delay_warning_time to the desired value in main.cf.

delay_warning_time=4h

Beginning with version 3.0, Postfix can also notify those same senders when delayed messages are finally delivered. This is also off by default, as it can result in a lot of notifications. But if you want this, enable confirm_delay_cleared in main.cf.

confirm_delay_cleared=yes

I'm going to take the other side of this than most of the answers here.

The ISP I work for serves about 3000 customers, and uses Qmail as our MTA for those customer's mailboxes.

We have run our system with a 2 day queue lifetime for nearly 2 years, and have not received any complaints, nor had an issues with delivering mail. It has lowered the queue size, which has made it much easier to spot compromised accounts (rare, but they do occur) and clean them up.

Queue lifetimes over a day is just Cargo Cult system administration, and a holdover from when the internet was much less "always on". Good sysadmins follow "best practices", but even better ones understand why it was best practice, and change the "best practice" to a better practice when the situation differs from the one the previous "best practice" was developed in.