You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a [email protected] address which has a vacation on to tell users that they should not use this email address.
This used to work in a very old version of PostfixAdmin but does not at least under 3.2 and 3.3 because of the check in vacation.pl in the check_and_clean_from_address subroutine.
I do agree that there should be a check here for the real from address, but the check appears to happen here with the to address for some reason. My vacation.log file shows:
2022/11/07 15:44:33 DEBUG> /var/spool/vacation/vacation.pl:581 main:: - Script argument SMTP recipient is : 'noreply#[email protected]' and smtp_sender : '[email protected]'
2022/11/07 15:44:33 DEBUG> /var/spool/vacation/vacation.pl:614 main:: - Converted autoreply mailbox back to normal style - from noreply#[email protected] to [email protected]
2022/11/07 15:44:33 DEBUG> /var/spool/vacation/vacation.pl:624 main:: - Email headers have to: '[email protected]' and From: 'Test User <[email protected]>'
2022/11/07 15:44:33 DEBUG> /var/spool/vacation/vacation.pl:564 main::check_and_clean_from_address - sender [email protected] contains noreply - will not send vacation message
There may be a complication because we're also processing via amavis, so perhaps that's mangling some from/to addresses here?
Unfortunately, there doesn't appear to be a way to override the list of "bad" addresses because there is a hard-coded list that is ORd with the configuration setting for custom noreply patterns.
The text was updated successfully, but these errors were encountered:
We have a [email protected] address which has a vacation on to tell users that they should not use this email address.
This used to work in a very old version of PostfixAdmin but does not at least under 3.2 and 3.3 because of the check in vacation.pl in the check_and_clean_from_address subroutine.
I do agree that there should be a check here for the real from address, but the check appears to happen here with the to address for some reason. My vacation.log file shows:
There may be a complication because we're also processing via amavis, so perhaps that's mangling some from/to addresses here?
Unfortunately, there doesn't appear to be a way to override the list of "bad" addresses because there is a hard-coded list that is ORd with the configuration setting for custom noreply patterns.
The text was updated successfully, but these errors were encountered: