Setting auto reply message once creates unwanted system overhead past message end date about postfixadmin HOT 5 CLOSED

@DavidGoodwin thank you again for your code above. I have tested it and it works as a standalone module that I will call via cron. Eventually I think this code should be part of the vacation.pl script so that when the script is triggered for a user that has an expired auto reply interval, the same functions are called to clear everything.

In my testing, I found a small bug in the vacation.pl script with respect to logging. The last line of code at the end of the sub send_vacation_email subroutine that logs a statement when a message is sent should be $logger->info but instead it is a $logger->debug. This will result in no messages being logged to the log when a auto reply is sent. The only time message is logged is if the auto reply interval has elapsed.

Thank you again,
Aria

from postfixadmin.

Hi Aria - Yes you're correct ... currently there isn't anything to do this.

The easiest might be some sort of cron job which looks for active vacation(s) and if they need deactivating it removes them?

Alternatively, I suppose the alias lookup SQL could be changed so it adds in the vacation alias if the time window is correct? I'm not sure if Postfix would be happy receiving two rows from doing some sort of UNION ALL on the vacation table or not though ....

MariaDB [postfixadmin]> select goto from alias WHERE address = '[email protected]' UNION ALL ( Select concat(replace(email, '@', '#'), '@autoreply.mydomain.com')  as goto FROM vacation WHERE email = '[email protected]' AND activ
euntil >= NOW() AND activefrom <= NOW());
+-----------------------------------------+
| goto                                    |
+-----------------------------------------+
| [email protected]                        |
| test#[email protected] |
+-----------------------------------------+
2 rows in set (0.001 sec)

from postfixadmin.

Hi David. Thank you for your prompt reply.

The easiest might be some sort of cron job which looks for active vacation(s) and if they need deactivating it removes them?

Yes, that is what you suggested here #616 but the problem there is that simply setting active to 0 for the vacation table does not have any impact on the fact that the alias still references the autoreply domain, causing postfix to attempt delivery to both the mailbox and the autoreply domain. That's what I am trying to avoid because over time, nearly every user will set an autoreply message and once set, every message addressed to them will trigger the vacation script forever!

Alternatively, I suppose the alias lookup SQL could be changed so it adds in the vacation alias if the time window is correct? I'm not sure if Postfix would be happy receiving two rows from doing some sort of UNION ALL on the vacation table or not though ....

MariaDB [postfixadmin]> select goto from alias WHERE address = '[email protected]' UNION ALL ( Select concat(replace(email, '@', '#'), '@autoreply.mydomain.com')  as goto FROM vacation WHERE email = '[email protected]' AND activ
euntil >= NOW() AND activefrom <= NOW());
+-----------------------------------------+
| goto                                    |
+-----------------------------------------+
| [email protected]                        |
| test#[email protected] |
+-----------------------------------------+
2 rows in set (0.001 sec)

Oddly enough, the above query returns a single row with the two e-mails together for me. Not sure why. Regardless, as you said, I am not sure it postfix cares it it gets one row or two and the problem remains. I also prefer not to hard code the autoreply domain here because that is a configuration option for PFA.

In my case, the user is not allowed to change their alias so all of my alias table address fields match the goto field. Since this is the case, I can combine in one cron the search for vacation settings that have expired, turn them to active=0 and then replace the alias table goto field for that email (where email=address) with the value in the address field. This will remove the autoreply address from the goto field and in my unique case, returns the goto field to the default (matching the address field).

The ideal solution would be to perform the same database operation the GUI performs which is to remove the autoreply address from the set of addresses in the goto field of the alias table but I am not sure how to implement that outside of the GUI php code.

Thank you again.

from postfixadmin.

Hi -

Oh, yeah, I meant that a cron job would have deactivated the alias record too ...

I think it'd be a case of the cron job looking for people with vacation entries that expire soon, and using the VacationHandler class to remove them - e.g.

#!/bin/env php
<?php

/**
 * This script is intended to be run through cron.
 * It should look through the postfixadmin vacation table for vacation entries that should no longer be active. If it
 * finds one that's expired, it should update the alias record to remove the autoreply alias, as well as deactivating the vacation entry.
 * @see https://github.com/postfixadmin/postfixadmin/issues/832
 */
require_once(__DIR__ . '/../../public/common.php'); // change this path so it finds PostfixAdmin's codebase

define('POSTFIXADMIN_CLI', 1);

$table_vacation = table_by_key('vacation');
$vacations_that_need_deactivating = db_query_all("SELECT * FROM $table_vacation WHERE activeuntil <= NOW() AND active = 1 ");

foreach ($vacations_that_need_deactivating as $row) {

    try {
        $vh = new VacationHandler($row['email']);
        error_log(__FILE__ . " - I need to disable the postfixadmin vacation stuff for : {$row['email']} as it should end at {$row['activeuntil']}");
        $vh->remove();

    } catch (\Exception $e) {
        error_log(__FILE__ . " - failed to remove postfixadmin vacation settings for user." . $e->getMessage());
    }
}

from postfixadmin.

Super. Thank you David. I will test this code and let you know if I find any issues. Much appreciated.

from postfixadmin.