Add bcc and dontsend capabilities to xarf-login-attack action

[K2IE]

This PR provides the ability to specify an optional bcc for the generated abuse emails. It also provides the ability to provide an array of abuse addresses for which no email should be generated. This solves the problem of published abuse addresses which bounce the mail back to the sender or, as in the case of lacnicnet, say that they cannot assist because the are a regional allocation registry.

The dontsend array is specified in jail.local as:

dontsend = ( '[email protected]' '[email protected]' '[email protected]')

The bcc is specified in jail.local as:

bcc = [email protected]

Then xarf-login-attack is called as usual, with either of the new optional parameters passed as desired:

action = %(action_)s
         xarf-login-attack-local[mailargs=%(mailargs)s,mailcmd=%(mailcmd)s,bcc="%(bcc)s",dontsend="%(dontsend)s"]

I also removed a redundant IFS operation on $ADDRESSES.

Resolves #2919 and #2920 .

[sebres]

Just by the way, please note an amendment to PR description:

-xarf-login-attack-local[mailargs=%(mailargs)s,mailcmd=%(mailcmd)s,bcc=%(bcc)s,dontsend=%(dontsend)s]
+xarf-login-attack-local[mailargs=%(mailargs)s,mailcmd=%(mailcmd)s,bcc="%(bcc)s",dontsend="%(dontsend)s"]

without quotes it would supply wrong (truncated) arguments to the action.

[sebres]

I also removed a redundant IFS operation on $ADDRESSES.

Why it should be redundant (now)? I don't see any code piece that could solve #2372, which could occur again if you would remove this "redundant" operation.

[K2IE]

@sebres thanks for your comment. I have tested extensively without the suggested double-quotes and have no experienced truncation of the arguments, verified by dumping the received arguments to a tempfile for debugging. Can you please point me in the direction what I'm failing to understand?

[K2IE]

I also removed a redundant IFS operation on $ADDRESSES.

Why it should be redundant (now)? I don't see any code piece that could solve #2372, which could occur again if you would remove this "redundant" operation.

I was unaware of #2372. I will re-add that operation.

[sebres]

Can you please point me in the direction what I'm failing to understand?

$ python -c 'from fail2ban.helpers import extractOptions; an, ao = extractOptions("""some-action[a="x, y, z", b=x, y, z]"""); print(ao)'
{'a': 'x, y, z', 'b': 'x'}

as you can see a contains whole string as enclosed in quotes x, y, z, whereas b contains only x. As an option value (without quote) only single "word" is allowed (and it cannot contains comma, space or [] characters).

As for "not experienced truncation", it is a matter of sequence, so how (or rather when exactly) %(dontsend)s gets substituted and I'm pretty sure this gets interpolated before it is supplied as parameter to the action in the jail, so it becomes:

- [..., dontsend=%(dontsend)s]
+ [..., dontsend=( '[email protected]' '[email protected]' '[email protected]')]

But... trying this:

$ python -c 'from fail2ban.helpers import extractOptions; an, ao = extractOptions("""some-action[a=([email protected] [email protected] [email protected])]"""); print(ao)'
{'a': '([email protected] [email protected] [email protected])'}

I see it is indeed correct, so space (alone) is not a separator anymore at least in last version (I changed this extractOptions several times).