Hi,
I'm currently using procmail to pipe mail (after spamassassin tests) to
"dbmail-smtp -u username". I've noticed that if the database is located on
another machine and that is inaccessible, then the mail will get delivered
to the local mailbox, rather than being queued.
My thought was to get dbmail-smtp, upon an error of connecting to the
database, to store the message in a directory, which could be then requeued
when the database came back online.
For example, dbmail has a directory "/var/spool/dbmail/deferred" that it
stores the messages in. The file names of the message are composed of the
filename "username-unix_timestamp-random_code.msg" and the file itself
contains the message. The random code is there just in case that particular
username gets more than one message delivered in a second.
What are peoples views on the above? I'd checked out the current dbmail-1
CVS tree (I can't seem to find v2?), and I'm going to try and give the above
ago, because I know I'd use it, so there maybe others out there too...
Matt
I'm currently using procmail to pipe mail (after spamassassin tests) to
"dbmail-smtp -u username". I've noticed that if the database is located on
another machine and that is inaccessible, then the mail will get delivered
to the local mailbox, rather than being queued.
My thought was to get dbmail-smtp, upon an error of connecting to the
database, to store the message in a directory, which could be then requeued
when the database came back online.
For example, dbmail has a directory "/var/spool/dbmail/deferred" that it
stores the messages in. The file names of the message are composed of the
filename "username-unix_timestamp-random_code.msg" and the file itself
contains the message. The random code is there just in case that particular
username gets more than one message delivered in a second.
What are peoples views on the above? I'd checked out the current dbmail-1
CVS tree (I can't seem to find v2?), and I'm going to try and give the above
ago, because I know I'd use it, so there maybe others out there too...
Matt