Auto-Submitted mail header added

[slater0013]

Auto-Submitted header should be added to every mail sent by an automatic system, such as CRON jobs, etc. Auto-Reply systems should NOT reply when this header is set to 'auto-generated'.

cf. #16538

(First PR of my life here... might have forgot something)

[skjnldsv]

@ChristophWurst do you know about this for mails?

[slater0013]

@ChristophWurst do you know about this for mails?

You can check https://tools.ietf.org/html/rfc3834 and https://tools.ietf.org/html/rfc5436 as mentionned by @kesselb in #16538 (comment)

[ChristophWurst]

You can check https://tools.ietf.org/html/rfc3834

That RFC talks about automatic replies and not email sent from a system. I'm not sure if this is applicable. Do you have a specific section that says otherwise?

[slater0013]

You can check https://tools.ietf.org/html/rfc3834

That RFC talks about automatic replies and not email sent from a system. I'm not sure if this is applicable. Do you have a specific section that says otherwise?

https://datatracker.ietf.org/doc/html/rfc3834#section-2

• Automatic responses SHOULD NOT be issued in response to any
  message which contains an Auto-Submitted header field (see below),
  where that field has any value other than "no".

https://datatracker.ietf.org/doc/html/rfc3834#section-5.2

The auto-generated keyword:

• SHOULD be used on messages generated by automatic (often periodic)
  processes (such as UNIX "cron jobs") which are not direct
  responses to other messages

GS.

[nickvergessen]

The auto-generated keyword:

SHOULD be used on messages generated by automatic (often periodic)
processes (such as UNIX "cron jobs") which are not direct
responses to other messages

but our emails are not (only) "automatic (often periodic)". Activities mails might be. All other emails are not:

• You receive a share
• You receive an invite to talk
• An announcement has been posted

They are all the result of a direct user action and not "automatic".

So maybe we add an option that allows an app setting it, but we shouldn't set it generically.

[slater0013]

An option could be a great option … :)

The main goal (from my POV) is to avoid autoreply emails.

Since emails are sent from a generic adress, getting dozens of « I am away from office … » per week on our cloud@ email address is not very usefull, and setting auto-generated header can fix this.

GS

[kesselb]

So maybe we add an option that allows an app setting it,
An option could be a great option … :)

You are not talking about the same ;) It means that our mailer class has a method to enable this header for certain emails (e.g. sent by the activity app) but not to have a flag in config.php to turn on/off this behavior.

SHOULD be used on messages generated by automatic (often periodic)
processes (such as UNIX "cron jobs") which are not direct
responses to other messages

And the next sentence in the RFC is

MUST NOT be used on manually generated messages,

I guess if one is invited to a talk channel we should not set the auto-subject header (as the email is an result of a user action) but for the daily/weekly/etc activity mail it's okay. Google Calendar does not set the header for invitation emails to calendar events.

Maybe we are not using/setting the reply-to header properly. If bob invites me to a talk channel the email should be sent by cloud@ but the reply-to should be bob@.

[szaimen]

Soo... Do we accept this change or not?

[nickvergessen]

I think we should not hardcode itbut instead add a public api function on the mail which then sets this or not

[slater0013]

I think we should not hardcode itbut instead add a public api function on the mail which then sets this or not

Do you mean adding a config.php parameter ?

[nickvergessen]

No, the app/code sending the mail needs to decide whether it's a custom mail or auto-submitted

[nickvergessen]

Now implemented in a configurable way via #35876