masa23 / arcmilter

A milter that performs DKIM and ARC signatures.
MIT License
3 stars 0 forks source link

Enhancement Suggestions #11

Open amaclach opened 1 month ago

amaclach commented 1 month ago

おはようございます

Can you please consider the following options?

1) An option to use a lookup table like used by opendkim instead of explicitly defining each destination domain's certificate e.g

# Signing domain, selector, and key (required). For example, perform signing
# for domain "example.com" with selector "2020" (2020._domainkey.example.com),
# using the private key stored in /etc/dkimkeys/example.private. More granular
# setup options can be found in /usr/share/doc/opendkim/README.opendkim.
#Domain         example.com
#Selector       2020
#KeyFile        /etc/dkimkeys/example.private

# Map domains in From addresses to keys used to sign messages
KeyTable        refile:/etc/opendkim/key.table
SigningTable        refile:/etc/opendkim/signing.table

2) An option to sign/seal all messages using a single key/selector as is done by the likes of Microsoft

3) An option to validate the ARC chain when used on the destination server - e.g. again on opendkim

# Common signing and verification parameters. In Debian, the "From" header is
# oversigned, because it is often the identity key used by reputation systems
# and thus somewhat security sensitive.
Canonicalization    relaxed/simple
Mode            sv
SubDomains      no
OversignHeaders From

4) log to syslog / journal rather than a logfile

masa23 commented 1 month ago
  1. An option to use a lookup table like used by opendkim instead of explicitly defining each destination domain's certificate

Is it your intention to have this one signed only for specific email addresses? Would it be inconvenient to specify a signature key and selector for each domain? We would be grateful if you could let us know.

  1. An option to sign/seal all messages using a single key/selector as is done by the likes of Microsoft

We do not have the function to sign all emails, but would consider it.

  1. An option to validate the ARC chain when used on the destination server - e.g. again on opendkim

We'll consider it.

  1. log to syslog / journal rather than a logfile
LogFile:
  Path: ""

If the Path is left empty, the logs will be output to standard error. I suggest removing the configuration and allowing systemd's journal to capture the logs instead.

amaclach commented 1 month ago

Thanks. Will update the software to the latest version and try as per below. The lookup table would be great because I process mail for a lot of domains.

Andrew MacLachlan General Manager CyberWarden +971 58 5224238 @.***

From: masa23 @.> Reply-To: masa23/arcmilter @.> Date: Wednesday, 18 September 2024 at 7:48 PM To: masa23/arcmilter @.> Cc: Andrew MacLachlan @.>, Author @.***> Subject: Re: [masa23/arcmilter] Enhancement Suggestions (Issue #11)

  1. An option to use a lookup table like used by opendkim instead of explicitly defining each destination domain's certificate

Is it your intention to have this one signed only for specific email addresses? Would it be inconvenient to specify a signature key and selector for each domain? We would be grateful if you could let us know.

  1. An option to sign/seal all messages using a single key/selector as is done by the likes of Microsoft

We do not have the function to sign all emails, but would consider it.

  1. An option to validate the ARC chain when used on the destination server - e.g. again on opendkim

We'll consider it.

  1. log to syslog / journal rather than a logfile

LogFile:

Path: ""

If the Path is left empty, the logs will be output to standard error. I suggest removing the configuration and allowing systemd's journal to capture the logs instead.

— Reply to this email directly, view it on GitHubhttps://github.com/masa23/arcmilter/issues/11#issuecomment-2358832254, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BLJXASRUNTRIRVVTCX5UQLLZXGOCNAVCNFSM6AAAAABOIUZRVSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJYHAZTEMRVGQ. You are receiving this because you authored the thread.Message ID: @.***>