When running an email command against Sympa, a command report is generated. For commands that trigger an email themselves (i.e. subscribe, backed by an 'auth' scenario), this report is redundant.
Version
Sympa 6.2.62 on FreeBSD 13.0
Installation method
Locally built packages from FreeBSD ports.
Expected behavior
When running an email command (i.e. subscribe), there should either be a command-specific email (i.e. an auth-request) or -- if that command does not imply a notification by itself -- a command report.
Actual behavior
When running an email command (i.e. subscribe), users get both a command-specific email (i.e. an auth-request) and a command report. While this is not actually a technical problem, users do get confused.
Additional information
Here is an example log snippet of sympa_msg that shows the behaviour. The list uses the subscribe.auth_owner scenario from the Sympa distribution.
Sep 21 09:05:23 sympa3 sympa_msg[56408]: notice Sympa::Spindle::ProcessIncoming::_twist() Processing Sympa::Message <mylist-request.1632207906.10564>; envelope_sender=someaddress@example.com; message_id=0e40b8b4-4dd8-ddbf-ff04-325bff02b116@example.com; sender=someaddress@example.com
Sep 21 09:05:23 sympa3 sympa_msg[56408]: notice Sympa::Spindle::ProcessMessage::_twist() Processing Sympa::Request <action=subscribe;context=mylist@lists.example.com;email=someaddress@example.com>
Sep 21 09:05:23 sympa3 sympa_msg[56408]: notice Sympa::Spool::store() Sympa::Request <action=subscribe;context=mylist@lists.example.com;email=someaddress@example.com> is stored into Sympa::Spool::Auth as <1632207906,mylist@lists.example.com_17e4cb56e77dae03,someaddress@example.com,subscribe>
Sep 21 09:05:23 sympa3 sympa_msg[56408]: notice Sympa::Spindle::ProcessTemplate::_twist() Processing Sympa::Message::Template <mylist@lists.example.com.1632207923.56408,1095>; envelope_sender=mylist-owner@lists.example.com; message_id=sympa.1632207923.56408.872@lists.example.com; recipients=someaddress@example.com; sender=sympa@lists.example.com; template=request_auth; type=subscribe
Sep 21 09:05:23 sympa3 sympa_msg[56408]: notice Sympa::Spool::Outgoing::store() Message Sympa::Message::Template <mylist@lists.example.com.1632207923.56408,1095> is stored into bulk spool as <5.5.1632207923.1632207923.642893.mylist@lists.example.com_s,56408,6473>
Sep 21 09:05:23 sympa3 sympa_msg[56408]: info Sympa::Spindle::ToAuth::_twist() SUBSCRIBE for Sympa::List <mylist@lists.example.com> from someaddress@example.com, auth requested (0.05 seconds)
Sep 21 09:05:23 sympa3 sympa_msg[56408]: notice Sympa::Spindle::ProcessTemplate::_twist() Processing Sympa::Message::Template <sympa@lists.example.com.1632207924.56408,1859>; envelope_sender=sympa-request@lists.example.com; message_id=sympa.1632207923.56408.433@lists.example.com; recipients=someaddress@example.com; sender=sympa@lists.example.com; template=command_report;
Sep 21 09:05:23 sympa3 sympa_msg[56408]: notice Sympa::Spool::Outgoing::store() Message Sympa::Message::Template <sympa@lists.example.com.1632207924.56408,1859> is stored into bulk spool as <1.5.1632207924.1632207923.727937.sympa@lists.example.com_s,56408,2728>
Unsubscription is definitely affected, too, and I think other commands as well.
Please let me know if you need any other information or if there is a configuration item I have missed.
When running an email command against Sympa, a command report is generated. For commands that trigger an email themselves (i.e. subscribe, backed by an 'auth' scenario), this report is redundant.
Version
Sympa 6.2.62 on FreeBSD 13.0
Installation method
Locally built packages from FreeBSD ports.
Expected behavior
When running an email command (i.e. subscribe), there should either be a command-specific email (i.e. an auth-request) or -- if that command does not imply a notification by itself -- a command report.
Actual behavior
When running an email command (i.e. subscribe), users get both a command-specific email (i.e. an auth-request) and a command report. While this is not actually a technical problem, users do get confused.
Additional information
Here is an example log snippet of sympa_msg that shows the behaviour. The list uses the
subscribe.auth_owner
scenario from the Sympa distribution.Unsubscription is definitely affected, too, and I think other commands as well.
Please let me know if you need any other information or if there is a configuration item I have missed.