Hello, This is more a question than a bug, so please bear with me.


In /etc/network/if-up.d/postfix, you have:

# start or reload Postfix as needed
if [ ! -x /sbin/resolvconf ]; then
        f=/etc/resolv.conf
        if ! cp $f $(postconf -h queue_directory)$f 2>/dev/null; then
                exit 0
        fi
        if [ -n "$RUNNING" ]; then
                /etc/init.d/postfix reload >/dev/null 2>&1
        fi
fi

# If master is running, force a queue run to unload any mail that is
# hanging around.  Yes, sendmail is a symlink...
if [ -n "$RUNNING" ]; then
        if [ -x /usr/sbin/sendmail ]; then
                /usr/sbin/sendmail -q >/dev/null 2>&1
        fi
fi


When a vpn network is established or terminated, the reload of postfix
gets triggered. This reload operation does not really trigger a flush of
the mail queue.

Where as, manually running "/usr/sbin/sendmail -q" flushes the queue.

Shouldn't, when a vpn type connection is established, postfix try to
flush its queue?


Scenario is: You have a domain based transport defined. When you are
connected over vpn, your transport is accessible. But if you are not
connected, and you send an email, your emails will soft bounce (assuming
you have soft_bounce = yes set). This is fine. Now when the vpn is back,
shouldn't postfix immediately try to flush its mail queue ?

On Wed, 30 May 2012 20:57:46 +0530 Ritesh Raj Sarraf <rrs@debian.org> wrote:
..

There are all possible scenarios of this.  Including some network
interfaces coming up when you do NOT want the email to be sent.

If you know which interface should trigger which action,
/etc/network/if-up.d/ is for you.  Put a small fragment there
which does whatever you want.

Thanks,

/mjt