Mail loop for sympa-request address

[StianAndreassen79]

Hi Sympa Team,

Thanks for a great product! We have used it for years here at James Cook University. We have recently upgraded from 6.1.4 to 6.2.56, and we're seeing an issue that others have reported with this version. It's pertaining to how messages to sympa-request appear to be delivered to the sympa queue, but rejected as there's no such list, and they never should have been routed there in the first place.

Other bug reports have been logged regarding this;
#995
#957

We saw the same issue on our Sympa once we opened the new production server to mail in and out, it never happened in our test environment that was run for a while before we cut over to the production server. The issue manifested itself in extremely verbose log files, overworked spools and eventually RAM issues leading to paging and RAM initialization issues for the main Sympa threads. The delivery attempt occurred several times pr minute, the worst case I found was 143 times pr minute, all day and all night.

We implemented a workaround of adding a regexp to our virtual.regexp file, which is a virtual_maps regex defined in main.cf, as we don't use sendmail aliases, we use only regexp in our postfix configuration. This line effectively forwards these messages to /dev/null and the issue disappears;
/^sympa-request\@<list-domain>\.<dc>\.<dc>\.<dc>$/ devnull@localhost
We then have an entry in /etc/aliases that handles this;
devnull: /dev/null
as indicated in the other issues logged about this.

The reason why I'm submitting this issue, is that it would appear that the other issues logged seem to point to the root cause of this issue is a postfix misconfiguration where there are emails being routed IN to the Sympa host, sent to "[email protected]", evidenced by Sympa's log entries. But how can it be a postfix issue, if the
"FROM" address entries in both Sympa and postfix's log files show that;

1. maillog has NO value for "from"
2. sympa.log has "recipients=[email protected]; sender=[email protected]"

This leads me to believe that the emails appearing to be sent to [email protected] are actually being sent by Sympa itself, or may be a result of only using regexp configuration for postfix? Our sympa_aliases file is identical to what's in the documentation, but obviously having the list and mail domains modified. What are the chances you could look at this issue again?

[ikedas]

Hi @StianAndreassen79 ,
Could you please show a concrete example of log lines in which there is 'NO value for "from"'? I cannot understand what you mean.

[ikedas]

Could you please show the log of Sympa in the same period? log_level may be 0 (higher log levels are not useful). You may omit log lines for task_manager and/or wwsympa.

[StianAndreassen79]

Could you please show the log of Sympa in the same period? log_level may be 0 (higher log levels are not useful). You may omit log lines for task_manager and/or wwsympa.

I was already in the process of doing this when you posted the above, my apologies for not omitting those lines.. The file is attached.

Thanks for looking at this!

[ikedas]

@StianAndreassen79 , I still have more requests:

• Please tell me the versions of Postfix and Sympa.
• If possible, please show the result of running a command postconf -n . Secret information may be masked.

Thank you.

[ikedas]

@StianAndreassen79 , I found the solution.

You defined transports in master.cf such as (these are examples):

sympa   unix    -       n       n       -       -       pipe
  flags=hqRu user=sympa argv=$LIBEXECDIR/queue ${nexthop}
sympabounce unix -      n       n       -       -       pipe
  flags=hqRu user=sympa argv=$LIBEXECDIR/bouncequeue ${nexthop}

To solve the problem, add empty null_sender option as below:

sympa   unix    -       n       n       -       -       pipe
  flags=hqRu null_sender= user=sympa argv=$LIBEXECDIR/queue ${nexthop}
sympabounce unix -      n       n       -       -       pipe
  flags=hqRu null_sender= user=sympa argv=$LIBEXECDIR/bouncequeue ${nexthop}

This option was required for Sympa as of Postfix 2.3.

[StianAndreassen79]

Thanks @ikedas, but we're running postfix 2.10.1 as indicated above?

[ikedas]

Thanks @ikedas, but we're running postfix 2.10.1 as indicated above?

Yes, I confirmed with my CentOS 7. null_sender option was added as of Postfix 2.3.

[ikedas]

@StianAndreassen79 , thank you for detailed information. However, since they do not necessarily have to be disclosed anymore, I hid these comments. Thank you for reporting bug!

[StianAndreassen79]

No problem. I can confirm that adding null_sender= to master.cf as indicated fixes the issue without having to do patch Sympa.

…

On Fri, 16 Oct 2020 at 14:46, IKEDA Soji ***@***.***> wrote: @StianAndreassen79 <https://github.com/StianAndreassen79> , thank you for detailed information. However, since they do not necessarily have to be disclosed anymore, I hid these comments. Thank you for reporting bug! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1018 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALX3EYIGEM54I6S5FT4NBXTSK7FZZANCNFSM4SN57ADA> .