Re: Multiple dkim key with filter-dkimsign

[Martijn van Duren]

On Wed, 2022-10-19 at 00:23 +0400, Archange wrote:
> Le 19/10/2022 à 00:07, Martijn van Duren a écrit :
> > On Wed, 2022-10-19 at 00:02 +0400, Archange wrote:
> > > Hi there,
> > > 
> > > Due to an issue with the rspamd filter running against rspamd 3.3
> > > (https://github.com/poolpOrg/filter-rspamd/issues/41), I’m looking at
> > > migrating my main server to dkimsign. I’m already using it on several
> > > servers, but they all handle only one domain, and I’m now in need to
> > > handle several domains (all incoming on the same interface).
> > > 
> > > Those might have different selectors, different keys… Is there a way to
> > > specify those, or the only option is to have the same key and selector
> > > for all domains?
> > > 
> > > Regards.
> > > 
> > It's as you said, only a single key and selector can be used per
> > dkimsign instance. If I would allow multiple selectors/keys it would
> > require making the config a lot more complex without any additional
> > benefit that I can see at the time.
> 
> Not necessarily much more complex. I would just ditch -s/-k and make -d 
> accept domain:selector:keyfile triplets.

Why not take a step further?
domain:selector:keyfile:algorithm:canonicalization:headers

It opens the door to all kind of weirdness for which no real use case
has been presented yet.
> 
> This is probably not a good practice (e.g. I should likely have 
> different selector and dkim keys per server), but currently some domains 
> are shared with other servers and owners, and so is the dkim key for 
> those domains. I don’t want that key to be valid for other domains.

Bottom line, dkim is nothing more than "this entity" has seen this mail
in it's current form as long as the signature passes. The only reason
for adding support for multiple domains was because of dmarc, which
combines it with the question if the domain in the from-header matches
with the domain in the signature.

Bottom line is that it's not the domain that manages the key, but the
server and the domain only says that it trusts the server by handling
the public component.
> 
> I guess the solution is indeed to switch to different keys per server 
> instead of per domain.

I'm not setting this in stone, but I need a little more then personal
preferences for adding more complexity to this piece of code which I
already consider quite the monster.

If you really want this you could probably redirect the mail back into
itself but on different ports and let every port have their own
dkimsign instance, similar to how the old dkimproxy setups would work:
https://myconan.net/blog/posts/4567/
> 
> Regards.
> 

Re: Multiple dkim key with filter-dkimsign

[Martijn van Duren]

On Wed, 2022-10-19 at 00:02 +0400, Archange wrote:
> Hi there,
> 
> Due to an issue with the rspamd filter running against rspamd 3.3 
> (https://github.com/poolpOrg/filter-rspamd/issues/41), I’m looking at 
> migrating my main server to dkimsign. I’m already using it on several 
> servers, but they all handle only one domain, and I’m now in need to 
> handle several domains (all incoming on the same interface).
> 
> Those might have different selectors, different keys… Is there a way to 
> specify those, or the only option is to have the same key and selector 
> for all domains?
> 
> Regards.
> 
It's as you said, only a single key and selector can be used per
dkimsign instance. If I would allow multiple selectors/keys it would
require making the config a lot more complex without any additional
benefit that I can see at the time.

martijn@

Re: Failure to check FCrDNS with long DNS replies?

[Tassilo Philipp]

On 21. Nov 2020, at 10:44, Tassilo Philipp  wrote:


FYI, I run into the same issue with a different provider:
relay.yourmailgateway.de which also has a large number of A records.

Trying to reproduce and digging deeper now, by adding debug logs etc.


Interesting... thanks for checking and having thought of my report. I 
for myself didn't have any issues anymore, however, I barely ever 
receive any mail from sfr. Also, given the random order of IPs in the 
DNS reply, I simply might have had luck if it's in any case related 
to the IP order. I have no evidence for, but when I was having 
problems, the IP in question was among the last ones in the reply.


I'm curious what you'll find…


FYI, after digging deeper into this, I figured out that this was an issue 
with the DNS forwarders/resolver I was using (unfortunately not under 
my control) on this particular mail server: The forwarder is not able 
to resolve relay.yourmailgateway.de 

at all, likely due to the large number of A records 52 A + 13  records.

I believe there is a limit in BIND suite (32) and OpenBSD libc (35) 
and others, which restricts older gethostbyname() calls with struct 
hostent results down to that 30-something number. Likely the used 
resolver was using these old/obsolete libc functions…


But OpenSMTPD and filter FCrDNS and OpenBSD ASR all doing fine here, 
because using getaddrinfo() alike under the hood with dynamic struct 
addrinfo result allocation, which does not expose any such limits and 
resolves all 65 A and  records just fine.


Thanks for the feedback, that sounds like a fitting analysis. So if I 
follow your thought, the resolver basically truncates the list and what 
opensmtpd gets to see at the hand sometimes misses the entry it tries to 
verify? Sounds like the culprit indeed.


I personally did not observe this issue anymore, unsure why, some update 
might have fixed it on some upstream resolver or dunno...
How are you dealing with this, given you don't control the resolver? I 
guess you just switched it?


Thanks again for digging into this more

Re: Failure to check FCrDNS with long DNS replies?

[Joerg Jung]

> On 21. Nov 2020, at 10:44, Tassilo Philipp  
> wrote:
> 
>> FYI, I run into the same issue with a different provider:
>> relay.yourmailgateway.de which also has a large number of A records.
>> 
>> Trying to reproduce and digging deeper now, by adding debug logs etc.
> 
> Interesting... thanks for checking and having thought of my report. I for 
> myself didn't have any issues anymore, however, I barely ever receive any 
> mail from sfr. Also, given the random order of IPs in the DNS reply, I simply 
> might have had luck if it's in any case related to the IP order. I have no 
> evidence for, but when I was having problems, the IP in question was among 
> the last ones in the reply.
> 
> I'm curious what you'll find…

FYI, after digging deeper into this, I figured out that this was an issue 
with the DNS forwarders/resolver I was using (unfortunately not under my 
control)
on this particular mail server: The forwarder is not able to resolve 
relay.yourmailgateway.de  
at all, likely due to the large number of A records 52 A + 13  records. 

I believe there is a limit in BIND suite (32) and OpenBSD libc (35) and others, 
which restricts older gethostbyname() calls with struct hostent results 
down to that 30-something number. Likely the used resolver was using 
these old/obsolete libc functions…

But OpenSMTPD and filter FCrDNS and OpenBSD ASR all doing fine here, 
because using getaddrinfo() alike under the hood with dynamic struct addrinfo 
result allocation, which does not expose any such limits and resolves 
all 65 A and  records just fine.

Thanks,
Regards,
Joerg

Re: New report function for libopensmtpd

[Leo Unglaub]

If you follow this, you will not be so far of:

https://man.openbsd.org/style

On 18/10/2022 12:00, Martin Kjær Jørgensen wrote:

Okay I will.

Have you got a pattern the code should be written in or a
tool, like clang-format, to check/format with?

Re: New report function for libopensmtpd

[Martin Kjær Jørgensen]

Okay I will.

Have you got a pattern the code should be written in or a
tool, like clang-format, to check/format with?

On Tue, Oct 18 2022, Martijn van Duren  wrote:

> There's no particular reason why I didn't implement it.
> It should be relatively straight forward, if you have a patch
> which is up to par I'm willing to add it to my repo.
>
> martijn@
>
> On Tue, 2022-10-18 at 10:34 +0200, Martin Kjær Jørgensen wrote:
>> Hello,
>>
>> I came across your libopensmtpd while developing a relative simple
>> reporting plugin for smtpd. I see the API has alot of existing calls,
>> but I'm basically missing the following function or something like it;
>>
>> void osmtpd_register_report_auth(int, void (*)(struct osmtpd_ctx *,
>> const char * username, enum osmtpd_auth status));
>>
>> I wan't to monitor amount of failed auth attempts and block IP/port
>> temporarily based on statistics.
>>
>> Do you consider it a bad or unneeded feature, or would you accept the
>> feature if I write a patch;
>>
>> /Martin
>>

Re: New report function for libopensmtpd

[Martijn van Duren]

There's no particular reason why I didn't implement it.
It should be relatively straight forward, if you have a patch
which is up to par I'm willing to add it to my repo.

martijn@

On Tue, 2022-10-18 at 10:34 +0200, Martin Kjær Jørgensen wrote:
> Hello,
> 
> I came across your libopensmtpd while developing a relative simple
> reporting plugin for smtpd. I see the API has alot of existing calls,
> but I'm basically missing the following function or something like it;
> 
> void osmtpd_register_report_auth(int, void (*)(struct osmtpd_ctx *,
> const char * username, enum osmtpd_auth status));
> 
> I wan't to monitor amount of failed auth attempts and block IP/port
> temporarily based on statistics.
> 
> Do you consider it a bad or unneeded feature, or would you accept the
> feature if I write a patch;
> 
> /Martin
> 

Re: New report function for libopensmtpd

[Martijn van Duren]

There's no particular reason why I didn't implement it.
It should be relatively straight forward, if you have a patch
which is up to par I'm willing to add it to my repo.

martijn@

On Tue, 2022-10-18 at 10:34 +0200, Martin Kjær Jørgensen wrote:
> Hello,
> 
> I came across your libopensmtpd while developing a relative simple
> reporting plugin for smtpd. I see the API has alot of existing calls,
> but I'm basically missing the following function or something like it;
> 
> void osmtpd_register_report_auth(int, void (*)(struct osmtpd_ctx *,
> const char * username, enum osmtpd_auth status));
> 
> I wan't to monitor amount of failed auth attempts and block IP/port
> temporarily based on statistics.
> 
> Do you consider it a bad or unneeded feature, or would you accept the
> feature if I write a patch;
> 
> /Martin
> 

New report function for libopensmtpd

[Martin Kjær Jørgensen]

Hello,

I came across your libopensmtpd while developing a relative simple
reporting plugin for smtpd. I see the API has alot of existing calls,
but I'm basically missing the following function or something like it;

void osmtpd_register_report_auth(int, void (*)(struct osmtpd_ctx *,
const char * username, enum osmtpd_auth status));

I wan't to monitor amount of failed auth attempts and block IP/port
temporarily based on statistics.

Do you consider it a bad or unneeded feature, or would you accept the
feature if I write a patch;

/Martin