Clearly the user can override this behavior through an exception, but I suspect that this is an unintended behavior.
Consider a mailing list, "foo-mail@example.com".
The list software causes a header to be produced: "Sender: foo-mail@example.com".
The match condition, "^FROM_MAILER" is picking up the expression above. Reading through the dense regex, this seems to be errantly matching because the hyphen before mail aborts the greedy consumption of the mailbox. At that point, the "mail" token matches the case-insensitive portion of the ^FROM_MAILER and then the rest of the string is consumed by the portion handling after the "@" token.
Clearly this code has been around for ages.
Hyphens are a permitted RFC token for mailboxes.
Is this a bug where we should expend the effort to refine the regex for this exception?
Meanwhile, I have suggested to the sysadmin in question that our lists not be named in this pattern to avoid procmail around the planet from catching this incorrectly as admin mail.
Clearly the user can override this behavior through an exception, but I suspect that this is an unintended behavior.
Consider a mailing list, "foo-mail@example.com".
The list software causes a header to be produced: "Sender: foo-mail@example.com".
The match condition, "^FROM_MAILER" is picking up the expression above. Reading through the dense regex, this seems to be errantly matching because the hyphen before mail aborts the greedy consumption of the mailbox. At that point, the "mail" token matches the case-insensitive portion of the ^FROM_MAILER and then the rest of the string is consumed by the portion handling after the "@" token.
Clearly this code has been around for ages.
Hyphens are a permitted RFC token for mailboxes.
Is this a bug where we should expend the effort to refine the regex for this exception?
Meanwhile, I have suggested to the sysadmin in question that our lists not be named in this pattern to avoid procmail around the planet from catching this incorrectly as admin mail.