Check whether a message is an auto reply based on configuration

[larhip]

With the new method it is possible to detect auto replies or auto generated mail by their header (see also rfc3834)

This would be pretty useful in order to prevent sending automatic mails in reply to such messages (loop prevention).
See also corresponding PR in itop-standard-email-synchro.

[bastischubert]

So will auto replies still show up in itop and we can filter on the notification/triggers to prevent mail ping-pongs? Or will these E-Mails never show up in iTop (be suppressed) ?

[larhip]

In detail this PR will just add a new method which will allow to detect auto generated / replied mails.
This new method will be used in PR#5 in itop-standard-email-synchro.
PR#5 on itop-standard-email-synchro is using the method to prevent sending an automatic rejection message in case of unknown caller (so for this special case will not be suppressed but there is no rejection reply).
But basically this method could be used for other features in the future as well (maybe to prevent the creation of a new caller in case of an auto mail, ...)
Currently this logic is not that smart that you can use it to filter actions/trigger.

[Molkobain]

Hello Lars, I'll check this PR on friday, would you update/rebase you branch on master in the meantime? Thanks

[jbostoen]

Might also be worth checking out the open issue on my fork: jbostoen/itop-jb-mail-to-ticket-automation-v2#21

[Molkobain]

Will be reviewed this afternoon

[Molkobain]

Suggested change

	IssueLog::Info("Header \"$sHeader\" exists with the value: \"" . $this->aHeaders[strtolower($sHeader)] . "\"");
	IssueLog::Debug("Header \"$sHeader\" exists with the value: \"" . $this->aHeaders[strtolower($sHeader)] . "\"");

[Molkobain]

Suggested change

	IssueLog::Info("Given mail is an autoreply!");
	IssueLog::Debug("Given mail is an autoreply!");

[Molkobain]

Hello Lars,

We reviewed this PR today, seems like the RFC was updated. We wonder the header value, you only check for "auto-replied", how about "auto-generated"; wasn't it relevant in your use cases?

[larhip]

Hi Guillaume,

the idea of this PR(s) was to prevent email "ping pong" between iTop and a mail server. "Ping pong" means: iTop is sending a mail (i.e. "Hey you are an unknown caller"), Mail server ist sending an auto-reply (i.e. "Hey this is an auto-reply to your message"), iTop is sending again ("Hey your are an unknown caller"), and so on and so on.

From my point of view this "endless loop" should happen with auto-replies but not auto generated mails, since they are generated not in a reply to a mail from iTop. (correct me if I am wrong).

There might be a good reason to handle some auto generated mails in iTop, or at least handle them different then auto replies.

You could follow my explanation?

[Molkobain]

Thanks for the feedback, it is kind of how we understood it as well but as we didn't collect much experience on that matter yet, we didn't know if some mail servers would flag an out of office response as "auto-generated" for example. So we wanted to know what you encountered in your experience.

So it's all good for us (technically), the PRs will be functionally reviewed next week. :)

[Molkobain]

Accepted during functional once the following modification has been made: Empty the default auto_reply_header_patterns parameter value so the default behavior does not change.

We don't have enough experience yet on the headers and their values when it comes to the different mail servers out there (Exchange, GMail, ...).

Anyhhow, the feature will be documented and people will be able to activate it.
Once we collected enough feedbacks from the users, we will add a default value that should match most people expectations.

[Hipska]

I would suggest to only empty it in the code, but keep in the module. That way it will not change behaviour for existing users, but it will get enabled for new users..

[Hipska]

Suggested change

	$aAutoReplyHeaderPatterns = array(
	'auto-submitted' => '/^auto-replied.*$/i',
	);
	$aAutoReplyHeaderPatterns = [];