filter-dkimsign: ed25519 support
Hello misc@,
I'm currently working on adding ed25519 support to filter-dkimsign, but
I'm getting some mixed results with the different validators.
gmail: permfail => claims the key is missing
outlook: fail (signature syntax error)
protonmail: 2 headers
1st: permerror (0-bit key)
2nd: pass
yahoo: permfail
dkimvalidator.com: ed25519 not supported
rspamd: pass
I'm having some mixed feelings on how to interpret these results.
On the one hand I'm getting passes, so it appears to work in general.
But when I read RFC6373 section 3.3.4 it states:
Other algorithms MAY be defined in the future. Verifiers MUST ignore
any signatures using algorithms that they do not implement.
So I wouldn't expect these fails.
Does anyone on this list know which validators are known to verify
ed25519 correctly, or which explicitly are known to fail? If someone
wants to help me test my current work, work in progress diff below. This
is to be applied on top of http://imperialat.at/dev/filter-dkimsign/
Requires openssl 1.1.1 from ports.
martijn@
Index: Makefile
===
--- Makefile(revision 60)
+++ Makefile(working copy)
@@ -6,6 +6,10 @@
SRCS+= main.c mheader.c
+CRYPT_CFLAGS!=pkg-config --cflags libecrypto11
+CRYPT_LDFLAGS!=pkg-config --libs-only-L libecrypto11
+CRYPT_LDADD!=pkg-config --libs-only-l libecrypto11
+
CFLAGS+=-I${LOCALBASE}/include
CFLAGS+=-Wall -I${.CURDIR}
CFLAGS+=-Wstrict-prototypes -Wmissing-prototypes
@@ -12,8 +16,10 @@
CFLAGS+=-Wmissing-declarations
CFLAGS+=-Wshadow -Wpointer-arith -Wcast-qual
CFLAGS+=-Wsign-compare
+CFLAGS+=${CRYPT_CFLAGS}
LDFLAGS+=-L${LOCALBASE}/lib
-LDADD+=-lcrypto -lopensmtpd
+LDFLAGS+=${CRYPT_LDFLAGS}
+LDADD+=${CRYPT_LDADD} -lopensmtpd
DPADD= ${LIBCRYPTO}
bindir:
Index: main.c
===
--- main.c (revision 60)
+++ main.c (working copy)
@@ -45,8 +45,7 @@
int has_body;
struct dkim_signature signature;
int err;
- EVP_MD_CTX *b;
- EVP_MD_CTX *bh;
+ EVP_MD_CTX *dctx;
};
/* RFC 6376 section 5.4.1 */
@@ -92,6 +91,8 @@
static EVP_PKEY *pkey;
static const EVP_MD *hash_md;
+static int keyid = EVP_PKEY_RSA;
+static int sephash = 0;
#define DKIM_SIGNATURE_LINELEN 78
@@ -124,9 +125,18 @@
while ((ch = getopt(argc, argv, "a:c:d:h:k:s:tx:z")) != -1) {
switch (ch) {
case 'a':
- if (strncmp(optarg, "rsa-", 4) != 0)
- osmtpd_err(1, "invalid algorithm");
- hashalg = optarg + 4;
+ if (strncmp(optarg, "rsa-", 4) == 0) {
+ hashalg = optarg + 4;
+ cryptalg = "rsa";
+ keyid = EVP_PKEY_RSA;
+ sephash = 0;
+ } else if (strncmp(optarg, "ed25519-", 8) == 0) {
+ hashalg = optarg + 8;
+ cryptalg = "ed25519";
+ keyid = EVP_PKEY_ED25519;
+ sephash = 1;
+ } else
+ osmtpd_errx(1, "invalid algorithm");
break;
case 'c':
if (strncmp(optarg, "simple", 6) == 0) {
@@ -166,8 +176,6 @@
pkey = PEM_read_PrivateKey(keyfile, NULL, NULL, NULL);
if (pkey == NULL)
osmtpd_errx(1, "Can't read key file");
- if (EVP_PKEY_get0_RSA(pkey) == NULL)
- osmtpd_err(1, "Key is not of type rsa");
fclose(keyfile);
break;
case 's':
@@ -190,15 +198,19 @@
}
OpenSSL_add_all_digests();
- if ((hash_md = EVP_get_digestbyname(hashalg)) == NULL)
- osmtpd_errx(1, "Can't find hash: %s", hashalg);
if (pledge("tmppath stdio", NULL) == -1)
osmtpd_err(1, "pledge");
+ if ((hash_md = EVP_get_digestbyname(hashalg)) == NULL)
+ osmtpd_errx(1, "Can't find hash: %s", hashalg);
+
if (domain == NULL || selector == NULL || pkey == NULL)
usage();
+ if (EVP_PKEY_id(pkey) != keyid)
+ osmtpd_errx(1, "Key is not of type %s", cryptalg);
+
osmtpd_register_filter_dataline(dkim_dataline);
osmtpd_register_filter_commit(dkim_commit);
osmtpd_local_message(dkim_message_new, dkim_message_free);
@@ -293,13 +305,11 @@
if (addheaders > 0 && !dkim_signature_printf(message, "z="))
return NULL;
- if ((message->b = EVP_MD_CTX_new()) == NULL ||
- (message->bh = EVP_MD_CTX_new()) == NULL) {
+ if ((message->dctx = EVP_MD_CTX_new()) == NULL) {
dkim_errx(me
Re: Old clients fail to establish SSL Connection to 6.9
Eric Faurot wrote: > On Fri, May 07, 2021 at 01:42:52AM +0200, Markus Julen wrote: > > Hi all! > > > > Having just moved a small "outgoing only" mailserver to 6.9, I started to > > receive error messages: > > > > > 80008bb60b9428ed smtp connected address=X.X.X.X host=z.z.z > > > 80008bb60b9428ed smtp disconnected reason="io-error: handshake failed: > > > error:1402610B:SSL routines:ACCEPT_SR_CLNT_HELLO:wrong version number" > > > > No filters, nothing, just plain smtpd. 6.8 worked flawlessly. > > > > Has anyone managed to tweak the "cipher" option to the "listen" directive? > > Any other options to try? > > > > Telling everyone to upgrade their mail client is probably no option as of > > now... > > Hello. > > Have a look at the tls_config_set_protocols(3) manpage for the protocols and > ciphers > options. You can try with something like: > > listen on ... tls protocols "legacy" ciphers "compat" > > Eric. i got a similar error: > May 11 21:00:57 mail smtpd[54101]: 1dce957aa81938f4 smtp connected > address=65.55.52.250 host=co1gmehub09.msn.com > May 11 21:00:58 mail smtpd[62909]: dnsbl: 1dce957aa81938f4 not listed > May 11 21:00:58 mail smtpd[54101]: 1dce957aa81938f4 smtp disconnected > reason="io-error: handshake failed: error:140260C1:SSL > routines:ACCEPT_SR_CLNT_HELLO:no shared cipher" the "fix" from eric worked, i received the email, thanks! this is kind of funny, the email was from microsoft, i had to send them an email that they remove me from a block list cause apparently my neighbors aren't behaving peacefully and have sent some spam, so microsoft decided to block the whole network, which prevented me of sending emails to @hotmail.com addresses this is the third time i had to send them an email (first time was half a year ago, second time about 3 months ago, i am seeing a pattern here... enough with the anectodes) it seems like they are sending emails using some legacy ciphers?! before 6.9 i received these emails without any change in my smtpd.conf
Relay based on either auth or cert?
I was pondering a message Gille Chehade commented on (https://narkive.com/2puCGKoq.4) a very long time ago. He said: > The cert verification happens at the transport level, not the SMTP level > and an invalid certificate will cause TLS to abort and close connection. > > You can use this for example to have your local CA issue certificates to > a set of internal machines and have the mail gateway accept relaying for > these machines without authentication. > > You can also use this to ensure that users have a two-factor auth, their > credentials no longer are enough to relay, they would also have to use a > valid certificate issued by your CA. if their credentials are stolen, it > will not allow people to use the server as a spamming center. > > Or you could decide to authenticate users using certificates and not the > traditional user/password mechanism. A client will then have to show you > a valid certificate otherwise connection will drop at TLS negotiation. What I’m wondering is if there is a way to do both on the submission port (one of two factors, either being sufficient for relaying). In other words, accept mail on the submission port from either an authenticated user using a password, or verify they are using a certificate. I don’t want to require users using a password to use a cert, and I don’t want users using a cert be required to authenticate with a password. Is this possible? Sean
smtpctl spf walk -6 ?
Hi folks, I am a big fan of IPv6, so I wonder why smtpctl spf walk omits all the IPv6 addresses? # echo spf.protection.outlook.com | smtpctl spf walk 40.92.0.0/15 40.107.0.0/16 52.100.0.0/14 104.47.0.0/17 51.4.72.0/24 51.5.72.0/24 51.5.80.0/27 20.47.149.138/32 51.4.80.0/27 # dig spf.protection.outlook.com TXT +short | tr \ \\n "v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/48 include:spfd.protection.outlook.com -all" # echo spf.protection.outlook.com | smtpctl spf walk -6 invalid command Regards Harri
Re: smtpctl spf walk -6 ?
Harald Dunkel wrote: > Hi folks, > > I am a big fan of IPv6, so I wonder why smtpctl spf walk omits > all the IPv6 addresses? > > # echo spf.protection.outlook.com | smtpctl spf walk > 40.92.0.0/15 > 40.107.0.0/16 > 52.100.0.0/14 > 104.47.0.0/17 > 51.4.72.0/24 > 51.5.72.0/24 > 51.5.80.0/27 > 20.47.149.138/32 > 51.4.80.0/27 > > # dig spf.protection.outlook.com TXT +short | tr \ \\n > "v=spf1 > ip4:40.92.0.0/15 > ip4:40.107.0.0/16 > ip4:52.100.0.0/14 > ip4:104.47.0.0/17 > ip6:2a01:111:f400::/48 > ip6:2a01:111:f403::/48 > include:spfd.protection.outlook.com > -all" > > # echo spf.protection.outlook.com | smtpctl spf walk -6 > invalid command > > > Regards > Harri this is what i get on my machine: ~ echo spf.protection.outlook.com | smtpctl spf walk 40.92.0.0/15 40.107.0.0/16 52.100.0.0/14 104.47.0.0/17 2a01:111:f400::/48 2a01:111:f403::/48 51.4.72.0/24 51.5.72.0/24 51.5.80.0/27 20.47.149.138/32 51.4.80.0/27 2a01:4180:4051:0800::/64 2a01:4180:4050:0800::/64 2a01:4180:4051:0400::/64 2a01:4180:4050:0400::/64 no idea why you don't see the ipv6 addresses
