systemli / mail-tls-helper Goto Github PK

Apparantently a no-TLS whitelist is needed, e.g. when the mailserver uses onion-MX.

Ideas are:

• Add an option for autmatically ignoring hosts from the onion-MX host map
• Always ignore connections to hosts with a .onion address

I think having alerts = False would be a more sensible default.

It would be great if we could somehow use their list also. Although it's quite short at the moment.

Maybe we could fetch and parse it with starttls-policy. Then merge with our list.

@sumpfralle I think one of your commits introduced the wrong calculation

Summary mail by mail-tls-helper on mail

Total count of sent messages:             6208
Total count of messages sent with TLS:    6179
Total count of messages sent with Tor:    0
Total count of messages sent unencrypted: 29
Percentage of messages sent unencrypted:  0.00%

should be 0,46

Summary mail by mail-tls-helper on mail

Total count of sent messages:             5189
Total count of messages sent with TLS:    5163
Total count of messages sent with Tor:    0
Total count of messages sent unencrypted: 26
Percentage of messages sent unencrypted:  0.01%

should be 0,5

To be removed:

• shell
• bash

To be added:

• python

mail-tls-helper should allow for aggregation of statistics in database to support separated runs for log processing and for sending summary mails.

Rationale: At the moment, the summary mail is sent out immediately. This works well when mail-tls-helper is run weekly by logrotate. But for daily log rotation, this becomes annoying quickly.

We should support aggregation of the stats in the database and delayed sending of the summary mail via commandline options.

Postfix doesn't do it in the logs

Hello,

I intend to add a munin plugin for the visualization of the numbers of mail submitted by transport security ("plain", "onion" and "tls"). Maybe we can exchange some thoughts about that (before I head into the wrong/unwanted direction.

• The munin plugin would be called every five minutes - thus it would probably use the live mail log.
  • No additional complications like handling a state would arise. Just outputting the currently gathered mail counts would be sufficient.
• I think, we should keep the single-file structure of the code.
• maybe we should re-organice the argument handling:
  • allow separate actions (e.g. "update postmap", "send mail hints", "output statistics") - maybe even executed in a single run via nargs in argparse
  • otherwise we would probably need to a add a magic "--print-statistics-and-exit" switch, that would complicate the processing code

Or do you have other ideas how to approach this?