nullmailer spams relay host if misconfigured

Nullmailer retries unsuccessful deliveries forever. As a result, the queue
directory can become very large over time. Since no delivery status
notification is sent for failures, a user who accidentally misenters an
address will have a tough time figuring out what went wrong. Since the
output of mailq doesn't include the envelope addresses of the queued
messages, this problem becomes particularly troublesome to debug for users
without administrative access.

For temporary failures, some code needs to be added to check the age of the
queue file. If the queue file is older than a week (perhaps configurable in
/etc/nullmailer/queuelifetime), the temporary failure should be treated as
permanent.

For permanent failures, nullmailer should queue a bounce message from the
null envelope sender to the failed message's envelope sender. Once the
bounce has been successfully queued, nullmailer should delete the original
message be deleted from the queue. If queueing of the bounce message fails
for any reason, the original message must not be removed - to do so would
cause mail to be lost silently. As a special case, if the envelope sender of
the failed message is null, nullmailer should give the option to either move
the message from the queue to a special double bounce directory, or to
override the envelope sender of the bounce message to the special address
<#@[]> and the recipient to an administrative address (perhaps configured
using /etc/nullmailer/doublebouncehost and /etc/nullmailer/doublebounceto).
In the case of a grave misconfiguration where delivery of a message with the
special envelope sender <#@[]> fails, nullmailer should log an error and
delete the message from the queue.

--
Brian Ristuccia
<email address hidden>

tags 329192 +upstream
forwarded 329192 <email address hidden>
thanks

Hi Bruce,

yet another IMHO important bugreport (and not the last, I just had not
that much time during the last months to work on the package):

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329192

Maybe you could take a look at it?

                Thanks, Norbert

At least this bug could be made bearable by increasing the default
pausetime. What's the point of re-trying to send a message every
minute?