Basics of the new loop cutter

[John Haugeland]

The new loop cutter uses a different mechanism based entirely on the sender's address to determine how to handle incoming mail, and offers new options on handling said mail. The default configuration is identical in behavior to the prior flood control mechanism; if you are happy with how it behaved, you don't need to change anything, and the newer version will still catch several new kinds of loop for you.

The loop cutter, by default, simply prevents automatic responses to mails sent in clusters, hoping to prevent the remote side from sending a new mail. By default, the loop cutter will prevent an automatic response to any second or further mail sent by a user in a ten minute period. This is a shifting window; if a user sends a mail every five minutes, they won't receive a response to any after the first mail. If you would like to, you may choose also to prevent those repeat mails from being filed as tickets at all (this is off by default.)

Finally, you may write several rules of the form "X mails in Y seconds means no response for Z seconds" - any count of such rules you'd like. This new flexibility won't be needed by everyone, but it is needed by some.

Basically, it's a stronger loop cutter, and you don't have to change anything if you don't want to.

[Salaria]

Well done John, Its really a great feature implementation.

[John Haugeland]

Thanks.

[atDev]

There is a problem with this... if the user wants to say submit 3 tickets with different subjects they don't get the responses.

I think the loop cutter should check email + subject don't you think?

[John Haugeland]

No: some loops change the subject (for example by stuffing "re:" onto the front).

You could up the tolerance to loops if you wanted to, by giving people the ability to send in some larger number before the autoresponders if you wanted to. However, this is actually identical behavior to the old loop cutter code; that you didn't notice in the past probably indicates that this isn't an actual long term problem.

[ajgyomber]

I am performing some testing an noticed the following error when submitting multiple tickets in sequence in a relatively short period of time:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:

pipe to |/home/techscom/public_html/support/cli/index.php
generated by support@domaincom
local delivery failed

The mail parser log shows:

Result: Created ticket #RVR-397780 (Autoresponder not sent due to loop control)

Why would it yield the error?

[John Haugeland]

ajgyomber: This defect was repaired in 3.30.01. I apologize for not noticing this question until now. (We do prefer support contacts by support ticket, since that way they're certain to be handled.)

The problem was that certain MTAs, notably Exim and Postfix, believed that any data sent back along the pipe indicated failure. As such, when the autoresponder message was emitted to pipe, the MTAs were misunderstanding that to indicate failure, and reacting as would be appropriate. Said message has since been suppressed.

[paysite-cash]

hello

on our side we got all success mail parsing with this comment : Autoresponder not sent due to loop control)

I don't think it is normal... it is possible to desactivate ?

[John Haugeland]

That's normal, and the only thing that's changed is that this loop cutter mentions it in the log, whereas the old one didn't. Your old desk version was cutting those same loops, but it was doing so silently. All that message means is that the desk got two messages from the same person inside ten minutes, and didn't send the autoresponder the second time, because the desk was worried that there was a loop. Nothing's wrong.

You can disable it, yes, but you really probably shouldn't. Nothing is broken here, and that system exists for a good reason: to prevent mail loops from getting out fo control and consuming serious resources on your server.