Re: filter-dnsbl and Abusix

[Martijn van Duren]

On Sat, 2024-02-10 at 14:10 -0500, J Doe wrote:
> Hello,
> 
> I have configured OpenSMTPD to make use of: filter-dnsbl:
> 
>  /etc/mail/smtpd.conf
>  . . .
>  filter check_abusix proc-exec "filter-dnsbl -v
>  .black.mail.abusix.zone" user _dnsbl group _dnsbl
>  . . .
>  filter port_25_filters  chain { check_rev_DNS, check_spamhaus,
> check_abusix... }
> 
> ...however, if I try either the combined DNSBL from Abusix or the black
> DNSBL from Abusix, it will reject mail from Hotmail as well as e-mail
> that is hosted via 1&1's e-mail service.
> 
> The man page for filter-dnsbl mentions Abusix, so I am assuming it
> supports it, but why would this be happening ?  It seems like all
> responses via Abusix are detected as spam.
> 
> Does anyone else make use of Abusix and see this behaviour ?
> 
> Thanks,
> 
> - J
> 
I don't use abusix myself. Some time ago someone pointed out to me
that keys were part of the address and thus popped up in the logs and
return codes. For the providers that are known to have keys I've
implemented a hardcoded way of stripping the key itself. Other than
that they have no special treatment in filter-dnsbl.

If you're sure these servers aren't listed it might be possible that
they return some special whitelist status. To keep filter-dnsbl simple
all answers are interpreted at listed.

martijn@

Re: Status of filter-spf

[Martijn van Duren]

I've started filter-spf, but never gotten to finish it. No clue when
or if I want to continue with it. At the moment my priorities are
somewhere else.

martijn@

On Sun, 2024-01-28 at 14:04 +0100, Kirill A.Korinsky wrote:
> Greetings,
> 
> This list seems as the right place to discuss
> about http://imperialat.at/dev/filter-spf
> 
> So, here I'm asking about the status of this project.
> 
> As far as I can see it has only one import to svn from some code.
> 
> I've read that code and I doubt that it can be compiled.
> 
> Does anyone know how far away it from ready to use filter?
> 
> I have an idea to make a filter-auth on reusing a filter-dkimverify and
> filter-spf to produce one nice header with result of authication.
> 
> If it works, moving future to timplement DMARC as OpenSMTPd filters won't be
> such a big deal :)
> 
> Anyway, SPF in term of DNS resolution with all that include:, a:, ptr: and so 
> on
> is quite large, and I'd like to avoid implementing it from scratch to avoid 
> tons
> of bugs.
> 
> And before I jump into that black hole, I'd like to guess how deep it is.
> 
> Any ideas?
> 
> --
> wbr, Kirill
> 

Re: filter-dnsbl: feature request and bug report

[Martijn van Duren]

On Thu, 2023-12-28 at 22:40 +0100, Kirill A. Korinsky wrote:
> > On 28. Dec 2023, at 22:17, Martijn van Duren  
> > wrote:
> > 
> > On Thu, 2023-12-28 at 20:05 +0100, Kirill A. Korinsky wrote:
> > > 
> > > Example of software is sieve: as far as I know it doesn't support 
> > > matching case insensitive strings.
> > 
> > Does this currently pose a problem for anyone? If not I don't see a
> > reason to make a new release for it.
> 
> 
> Well, right now it should be written in sieve like this:
> 
> > if anyof(header :is "X-Spam" "yes", header :is "X-Spam" "Yes") {
> >   fileinto :create "Junk";
> > }
> 
> 
> a bit ugly but I agree that it's not enough for a release.

I've never used sieve, but this already is a custom rule and not a
X-Spam specific header check from sieve itself. However, a quick
online search shows me the i;ascii-casemap comparator. Maybe you
can give that a try.

Also, smtpd.conf(5), from which I've taken the string, uses a lower
case "yes".
> 
> 
> > > 
> > > I've read the code and I agree that implementing whitelist can be quite 
> > > tricky.
> > > 
> > > Anyway, I do have one idea: let introduce flag -i (inverse). It should 
> > > remove X-Spam: yes if matches with -m.
> > 
> > Why? What does this bring? Why do you need this?
> 
> 
> Right now I'm making a kind of the experiment: living without any statistical 
> analyser for my mail.
> 
> The hypotesa: usual mail traffic for family mail server is too small to make 
> statistical analyser like spamassasian useful by impact of mails.
> 
> So, I'm testing another approach: only DNSBL which delivers everything that 
> is matched into Junk folder.
> 
> Long story short I do have the following configuration:
> 
>  - NiX Spam and blocklist.de at spamd
>  - smptd configuration:
> 
> > filter dnsbl proc-exec "filter-dnsbl -m \
> >        all.spamrats.com \
> >        bip.virusfree.cz \
> >        bl.mailspike.org \
> >        bl.spamcop.net \
> >        bl.spameatingmonkey.net \
> >        cbl.abuseat.org \
> >        dnsbl-1.uceprotect.net \
> >        dnsbl.dronebl.org \
> >        mail-abuse.blacklist.jippg.org \
> >        psbl.surriel.com \
> >        rbl.0spam.org \
> >        truncate.gbudb.net \
> >        zen.spamhaus.org \
> >        XXX.combined.mail.abusix.zone \
> >        "
> > 
> > filter dnswl proc-exec "filter-dnsbl -m \
> >        XXX.white.mail.abusix.zone \
> >        "
> > 
> > filter "senderscore" proc-exec "filter-senderscore -junkBelow 70"
> > 
> > listen on egress inet4 port smtp tls pki mx1.catap.net \
> >        filter { "rdns", "fcrdns", dnsbl, dnswl, "senderscore" }
> 
> - and sieve script to move mail:
> 
> > if allof(
> >   anyof(header :is "X-Spam" "yes", header :is "X-Spam" "Yes"),
> >   not header :is "X-Spam-DNSBL" "Listed at white.mail.abusix.zone") {
> >     fileinto :create "Junk";
> > }
> 
> this works like a charm, really.
> 
> The idea of both changes to use white lists to remove X-Spam: yes from both 
> negative filters.

The discussion about having a single whitelist overrule a whole sluice
of lists apart. If you want whitelisting in filter-dnsbl it would
require special handling of a whole range of different options:
- Which response means what for what list
- Which option takes precedence in what situation
- Do we need to remove existing X-Spam headers?
- Are there other headers that need removing/modifying?

This would make filter-dnsbl grow way beyond of what it was ever
intended for into something where I'm afraid is not properly
maintainable for both programmer and admin.

Maybe you can write your own filter-dnswl with filter-dnsbl and
filter-admdscrub as inspiration.
> 
> > > 
> > > But I haven't see any easy way to implement it for non -m case.
> > > 
> > > During read the code of this filter I guess I've found third point which 
> > > I'd like to raise: filter fails in the case when one of provided DNSBL 
> > > returns error.
> > > 
> > > Shall it continue?
> > 
> > If a filter (or the intermediate DNS layer) returns an error we are in
> > limbo. If we accept the mail, but it's listed we're probably delivering
> > spam; if we reject the mail we're very likely to drop legit mail. Both
> > are undesirable. Failing the message asking to try again later seems th

Re: filter-dkimverify status

[Martijn van Duren]

On Thu, 2023-12-28 at 18:29 +0100, Kirill A. Korinsky wrote:
> Greetings,
> 
> This list seems to be the right place to ask about status of this filter 
> http://imperialat.at/dev/filter-dkimverify/
> 
> As I see via snv log the last commit was about a year ago.
> 
> Is it working? Or?
> 
> 
> 
> -- 
> wbr, Kirill
> 
It's fully functional. But due to circumstances I haven't made a release
yet. No promises on when I'll get around to it.
Feel free to use it as is and report any issues.

martijn@

Re: filter-dnsbl: feature request and bug report

[Martijn van Duren]

On Thu, 2023-12-28 at 20:05 +0100, Kirill A. Korinsky wrote:
> > On 28. Dec 2023, at 19:22, Martijn van Duren  
> > wrote:
> > 
> > On Thu, 2023-12-28 at 18:52 +0100, Kirill A. Korinsky wrote:
> > > 
> > > 
> > > 1. I'd like to report a small bug: OpenSMTPD injects header X-Spam: Yes 
> > > when filter decided that it is junk, and this filter injects yes (in the 
> > > lower case). Is it a bug?
> > 
> > I'm not aware about any specific standard when it comes to this header.
> > smtpd has `strcasecmp(line, "x-spam: yes")` in mail.maildir.c, so the
> > capitalisation isn't important there. However, if you use smtpd with
> > filter-dnsbl as a filter before forwarding it to another server which
> > does check this header in a case-sensitive manner it would matter.
> > So unless you can point to a piece of software which checks it in a
> > specific capitalisation I don't see a direct reason to fix it.
> 
> Neither do I.
> 
> Example of software is sieve: as far as I know it doesn't support matching 
> case insensitive strings.

Does this currently pose a problem for anyone? If not I don't see a
reason to make a new release for it.
> 
> > > 
> > > 2. Is it possible to add support of white list(s)? Let pass the message 
> > > if it contains on that list and optionally adds X-Spam-DNSWL: Listed at 
> > > ... header.
> > 
> > I've thought about adding whitelist support, but it's tough...
> > The RFC is explicitly vague on how to interpret responses, so there's
> > no way to determine how a response it to be interpreted without
> > extensive configuration either by the admin, or in the binary.
> > The latter would require in-depth knowledge of the different lists
> > on my end and actively maintain those, which I don't see myself doing.
> > 
> > Another reason why I don't see myself supporting whitelists is because
> > I don't see their value. Mail is whitelist based in principle, so what
> > blocking feature is it supposed to overwrite and how is filter-dnsbl
> > supposed to do this? And that's not even starting on the prioritisation
> > of which list takes precedence.
> > 
> > Do you have a specific use-case for whitelisting and if so, how would
> > you suggest to implement it in a generic way without making the filter
> > needlessly complicated?
> > 
> > In short: I'm not against whitelists per se, but without the specific
> > use-case and a good plan of how to implement it without turning it
> > into a coding/admin nightmare I don't see it happening.
> 
> 
> I've read the code and I agree that implementing whitelist can be quite 
> tricky.
> 
> Anyway, I do have one idea: let introduce flag -i (inverse). It should remove 
> X-Spam: yes if matches with -m.

Why? What does this bring? Why do you need this?
> 
> But I haven't see any easy way to implement it for non -m case.
> 
> During read the code of this filter I guess I've found third point which I'd 
> like to raise: filter fails in the case when one of provided DNSBL returns 
> error.
> 
> Shall it continue?

If a filter (or the intermediate DNS layer) returns an error we are in
limbo. If we accept the mail, but it's listed we're probably delivering
spam; if we reject the mail we're very likely to drop legit mail. Both
are undesirable. Failing the message asking to try again later seems the
safest option to me.
> 
> --
> wbr, Kirill
> 

Re: filter-dnsbl: feature request and bug report

[Martijn van Duren]

On Thu, 2023-12-28 at 18:52 +0100, Kirill A. Korinsky wrote:
> Greetings,
> 
> This list seems as the right place to discuss about 
> http://imperialat.at/dev/filter-dnsbl

As the author, I agree. :-)
> 
> 1. I'd like to report a small bug: OpenSMTPD injects header X-Spam: Yes when 
> filter decided that it is junk, and this filter injects yes (in the lower 
> case). Is it a bug?

I'm not aware about any specific standard when it comes to this header.
smtpd has `strcasecmp(line, "x-spam: yes")` in mail.maildir.c, so the
capitalisation isn't important there. However, if you use smtpd with
filter-dnsbl as a filter before forwarding it to another server which
does check this header in a case-sensitive manner it would matter.
So unless you can point to a piece of software which checks it in a
specific capitalisation I don't see a direct reason to fix it.
> 
> 2. Is it possible to add support of white list(s)? Let pass the message if it 
> contains on that list and optionally adds X-Spam-DNSWL: Listed at ... header.

I've thought about adding whitelist support, but it's tough...
The RFC is explicitly vague on how to interpret responses, so there's
no way to determine how a response it to be interpreted without
extensive configuration either by the admin, or in the binary.
The latter would require in-depth knowledge of the different lists
on my end and actively maintain those, which I don't see myself doing.

Another reason why I don't see myself supporting whitelists is because
I don't see their value. Mail is whitelist based in principle, so what
blocking feature is it supposed to overwrite and how is filter-dnsbl
supposed to do this? And that's not even starting on the prioritisation
of which list takes precedence.

Do you have a specific use-case for whitelisting and if so, how would
you suggest to implement it in a generic way without making the filter
needlessly complicated?

In short: I'm not against whitelists per se, but without the specific
use-case and a good plan of how to implement it without turning it
into a coding/admin nightmare I don't see it happening.
> 
> The nice example of white list is dnswl.mail.abusix.zone
> 
> Thanks.
> 
> 
> 
> -- 
> wbr, Kirill
> 
martijn@

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: 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
> 

Re: Capturing the log output of opensmtpd

[Martijn van Duren]

On Sat, 2022-10-15 at 13:21 +0100, Simon Harrison wrote:
> Hello. I'm using Python subprocess to send mails on a linux server. For
> outlook.com addresses I get the following error in /var/log/mail.log:
> 
> Oct 14 11:41:22 myhost smtpd[1846073]: f01b467faa967988 mta delivery
> evpid=d9b3ae9518ff979a from= to=
> rcpt=<-> source="server.ip.address" relay="104.47.56.161
> (104.47.56.161)" delay=2s result="PermFail" stat="550 5.7.1
> Unfortunately, messages from [server.ip.address] weren't sent. Please
> contact your Internet service provider since part of their network is
> on our block list (S3140). You can also refer your provider to
> http://mail.live.com/mail/troubleshooting.aspx#errors.
> [CO1NAM11FT072.eop-nam11.prod.protection.outlook.com]"
> 
> So my question is, is there any way to get that output rather than
> ssh-ing into the server and checking the log? Can opensmtpd return that
> output as well as logging it? Python subprocess.stdout suggests that
> opensmtpd does not return anything over than 0 or 1.
> 
> Cheers,
> 
> Simon
> 
It's send over syslog. So you can do whatever your syslog daemon
supports. If you use rsyslog one option could be to write it to a
named pipe:
https://www.rsyslog.com/doc/v8-stable/configuration/modules/ompipe.html

martijn@

Re: what does "from=<>" mean?

[Martijn van Duren]

On Wed, 2022-07-06 at 08:39 +0200, Harald Dunkel wrote:
> Hi folks
> 
> I see quite a number of EMails mentioned in /var/log/maillog with a
> string "from=<>", e.g.
> 
> Jul  6 08:08:24 mailgate smtpd[84448]: 90d0e01d76abce9c mta delivery 
> evpid=e62074ed220d58f9 from=<> to= rcpt=<-> 
> source="10.0.96.7" relay="10.0.96.11 (mailhost.mydomain.com)" delay=0s 
> result="Ok" stat="250 2.0.0 26668Kn61587355 Message accepted for delivery"
> 
> Its pretty unlikely that an EMail pop ups from nowhere, so what does
> this "from=<>" actually mean?

>From RFC5321 section 4.5.5:
   There are several types of notification messages that are required by
   existing and proposed Standards to be sent with a null reverse-path,
   namely non-delivery notifications as discussed in Section 3.7, other
   kinds of Delivery Status Notifications (DSNs, RFC 3461 [32]), and
   Message Disposition Notifications (MDNs, RFC 3798 [37]).  All of
   these kinds of messages are notifications about a previous message,
   and they are sent to the reverse-path of the previous mail message.
   (If the delivery of such a notification message fails, that usually
   indicates a problem with the mail system of the host to which the
   notification message is addressed.  For this reason, at some hosts
   the MTA is set up to forward such failed notification messages to
   someone who is able to fix problems with the mail system, e.g., via
   the postmaster alias.)

So most likely something like a delivery failure message, assuming
valid messages.
> 
> Would it be possible to add some more useful information to this line?

Without parsing the actual message (at this point I wouldn't even know
what to look for exactly) I don't see what what additional information
can be placed there.
> 
> 
> Regards
> 
> Harri
> 

Re: dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

[Martijn van Duren]

On Fri, 2022-01-28 at 00:09 +0100, Martijn van Duren wrote:
> On Mon, 2022-01-24 at 16:20 +0100, Tim van der Molen wrote:
> > Hi,
> > 
> > Martijn van Duren (2022-01-23 20:13 +0100):
> > > >  From: r...@relayclient.example.com (Cron Daemon)
> > > 
> > > According to RFC5322 section 3.4[0] this is not a valid e-mail format.
> > 
> > Just to point out this actually is valid. Text in parentheses is a
> > comment. See RFC 5322 section 3.2.2. Also this quote from section 3.4
> > which describes the format used above:
> > 
> >   Note: Some legacy implementations used the simple form where the
> >   addr-spec appears without the angle brackets, but included the
> >   name of the recipient in parentheses as a comment following the
> >   addr-spec.  Since the meaning of the information in a comment is
> >   unspecified, implementations SHOULD use the full name-addr form of
> >   the mailbox, instead of the legacy form, to specify the display
> >   name associated with a mailbox.  Also, because some legacy
> >   implementations interpret the comment, comments generally SHOULD
> >   NOT be used in address fields to avoid confusing such
> >   implementations.
> > 
> > Best,
> > Tim
> 
> Thanks for pointing this one out, it made me take a closer look at the
> spec. So when I originally responded I was only thinking in terms of
> what characters are used in a domain name, but the " (Cron Daemon)" part
> is not to be interpreted as domain characters, but a CFWS (or comment
> folding whitespace). This means that it should not be returned by
> osmtpd_mheader_from_domain() as part of the domain. So it is valid
> syntax, but I shouldn't have returned it when comparing against the
> known domain list. Similarly there were also a couple of FWS that I
> could ignore.
> 
> As for Paul's remark "SHOULD NOT" when it comes to this syntax: It's
> part of the current syntax (e.g. not obsolete), so I don't see any
> reason not to. Sorry for the confusion.
> 
> I have the following changes lined up in my repo[0]:
> - Fix a couple of memory leaks in error paths (pointed out by
>   Peter)
> - Add support for -D file, where file contains one domain per line. All
>   other rules from -d apply. (requested by Mischa and Renaud)
> - Fix FWS and CFWS issues when parsing a domain (pointed out by
>   Paul/Tim)
> 
> If people could help me test the latest code (or even check the diffs
> of revision 75-HEAD) that would help prepare for a new release.
> 
> martijn@
> 
> [0] http://imperialat.at/dev/filter-dkimsign/

Did anyone test this yet? I would like to have other people test this
before creating a new release.

Re: opensmtpd-filter-dnsbl

[Martijn van Duren]

On Sun, 2022-02-20 at 14:33 +, Pete Long wrote:
> Hi all,
> 
> I hope this is ok but I just wanted to say thanks to the developer of 
> 'opensmtpd-filter-dnsbl' whom I believe is Martijn van Duren. This filter is 
> superb and just what I was looking for in order to use the great resource 
> that is Spamhaus.
> 
> I can't seem to find a personal email address on the following site so that's 
> why I'm saying thanks on the list: 
> https://openports.pl/path/mail/opensmtpd-filters/dnsbl
> 
> Here's how I've used it in my smtpd.conf on OpenBSD 7.0:
> 
> filter dnsbl proc-exec "filter-dnsbl -mv zen.spamhaus.org"
> 
> listen on em0 tls pki mydomain.tld \
> hostname mydomain.tld filter { check_rdns, dnsbl }
> 
> I will shortly remove the -m flag which just adds headers rather than 
> rejecting the mail.
> 
> 
> Pete.

You're welcome.
And there's nothing wrong with using -m if that suits your needs, it's
designed with maildir's junk flag in mind.

martijn@

Re: dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

[Martijn van Duren]

On Mon, 2022-01-24 at 16:20 +0100, Tim van der Molen wrote:
> Hi,
> 
> Martijn van Duren (2022-01-23 20:13 +0100):
> > >  From: r...@relayclient.example.com (Cron Daemon)
> > 
> > According to RFC5322 section 3.4[0] this is not a valid e-mail format.
> 
> Just to point out this actually is valid. Text in parentheses is a
> comment. See RFC 5322 section 3.2.2. Also this quote from section 3.4
> which describes the format used above:
> 
>   Note: Some legacy implementations used the simple form where the
>   addr-spec appears without the angle brackets, but included the
>   name of the recipient in parentheses as a comment following the
>   addr-spec.  Since the meaning of the information in a comment is
>   unspecified, implementations SHOULD use the full name-addr form of
>   the mailbox, instead of the legacy form, to specify the display
>   name associated with a mailbox.  Also, because some legacy
>   implementations interpret the comment, comments generally SHOULD
>   NOT be used in address fields to avoid confusing such
>   implementations.
> 
> Best,
> Tim

Thanks for pointing this one out, it made me take a closer look at the
spec. So when I originally responded I was only thinking in terms of
what characters are used in a domain name, but the " (Cron Daemon)" part
is not to be interpreted as domain characters, but a CFWS (or comment
folding whitespace). This means that it should not be returned by
osmtpd_mheader_from_domain() as part of the domain. So it is valid
syntax, but I shouldn't have returned it when comparing against the
known domain list. Similarly there were also a couple of FWS that I
could ignore.

As for Paul's remark "SHOULD NOT" when it comes to this syntax: It's
part of the current syntax (e.g. not obsolete), so I don't see any
reason not to. Sorry for the confusion.

I have the following changes lined up in my repo[0]:
- Fix a couple of memory leaks in error paths (pointed out by
  Peter)
- Add support for -D file, where file contains one domain per line. All
  other rules from -d apply. (requested by Mischa and Renaud)
- Fix FWS and CFWS issues when parsing a domain (pointed out by
  Paul/Tim)

If people could help me test the latest code (or even check the diffs
of revision 75-HEAD) that would help prepare for a new release.

martijn@

[0] http://imperialat.at/dev/filter-dkimsign/

Re: dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

[Martijn van Duren]

On Sun, 2022-01-23 at 09:29 -0800, Paul Pace wrote:
> On 2021-11-24 04:01, Martijn van Duren wrote:
> > On Tue, 2021-11-23 at 08:47 -0800, Paul Pace wrote:
> > > Hello!
> > > 
> > > I have an Ubuntu 18.04 server running Postfix 3.3 that relays through 
> > > a
> > > local OpenSMTPD mail relay on OpenBSD 7.0. Messages sent from system
> > > messages and directly from mail command are signed by dkimsign as
> > > expected.
> > > 
> > > Messages sent from letstencrypt run through cron.weekly are not being
> > > signed by dkimsign with the expected domain. Log entries for correctly
> > > signed and incorrectly signed messages are identical on both client 
> > > and
> > > relay server.
> > > 
> > > Here are the key portions of the header in the received inbox for the
> > > cron.weekly job:
> > > 
> > > 
> > > DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=10172021;
> > > bh=rNFy7e0QC/J
> > >   YFcHTI8wUywlRSY3eJ4LLLsOZrSC0XBc=; h=date:subject:to:from;
> > >   d=example.com; 
> > > b=KqmB7rxJfpLcF6Nif/4bQRAbcQDDhVmFh+8KDeCqc9ujlr8ogK7...
> > > Received: from relayclient.example.com ( [172.16.13.2])
> > >   by smtp.example.com (OpenSMTPD) with ESMTPS id 44fa8358
> > > (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)
> > >   for ;
> > >   Sun, 14 Nov 2021 06:47:03 -0800 (PST)
> > > Received: by relayclient.example.com (Postfix)
> > >   id 881F75F401; Sun, 14 Nov 2021 06:47:03 -0800 (PST)
> > > Delivered-To: r...@relayclient.example.com
> > > Received: by relayclient.example.com (Postfix, from userid 0)
> > >   id 81D885F402; Sun, 14 Nov 2021 06:47:03 -0800 (PST)
> > >  From: r...@relayclient.example.com (Cron Daemon)
> > > To: r...@relayclient.example.com
> > > Subject: Cron  test -x /usr/sbin/anacron || ( cd / 
> > > &&
> > > run-parts --report /etc/cron.weekly )
> > > MIME-Version: 1.0
> > > Content-Type: text/plain; charset=ISO-8859-1
> > > Content-Transfer-Encoding: 8bit
> > > X-Cron-Env: 
> > > X-Cron-Env:
> > > 
> > > X-Cron-Env: 
> > > X-Cron-Env: 
> > > Message-Id: <2024144703.81d885f...@relayclient.example.com>
> > > Date: Sun, 14 Nov 2021 06:47:03 -0800 (PST)
> > > 
> > > 
> > > Note in this above headers that d=example.com and expected is
> > > d=relayclient.example.com
> > > 
> > > Here are the key portions of the headers in the received inbox from 
> > > the
> > > same client but for some other system message:
> > > 
> > > 
> > > DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=10172021;
> > > bh=r8XLAjeCvrx
> > >   jCndiJeywanw7UmGo9LRF4gIb07HheJc=; h=date:to:from:subject;
> > >   d=relayclient.example.com;
> > > b=QfD3av5+JxEZyCgzeZ7GcnhIf3/sMmeCNDtEvz/4/hGZf...
> > > Received: from relayclient.example.com ( [172.16.13.2])
> > >   by relayclient.example.com (OpenSMTPD) with ESMTPS id b3c796f1
> > > (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)
> > >   for ;
> > >   Sat, 20 Nov 2021 06:40:29 -0800 (PST)
> > > Received: by relayclient.example.com (Postfix)
> > >   id AFFC95E476; Sat, 20 Nov 2021 06:40:29 -0800 (PST)
> > > Delivered-To: r...@relayclient.example.com
> > > Received: by relayclient.example.com (Postfix, from userid 0)
> > >   id A961A5F42E; Sat, 20 Nov 2021 06:40:29 -0800 (PST)
> > > Subject: unattended-upgrades result for relayclient.example.com: True
> > >  From: r...@relayclient.example.com
> > > To: r...@relayclient.example.com
> > > Auto-Submitted: auto-generated
> > > MIME-Version: 1.0
> > > Content-Type: text/plain; charset="utf-8"
> > > Content-Transfer-Encoding: quoted-printable
> > > Message-Id: <20211120144029.a961a5f...@relayclient.example.com>
> > > Date: Sat, 20 Nov 2021 06:40:29 -0800 (PST)
> > > 
> > > 
> > > Note in this above headers that d=relayclient.example.com, as 
> > > expected.
> > > 
> > > Here is smtpd.conf:
> > > 
> > > 
> > > pki int_net cert "/etc/ssl/176.16.13.1.crt"
> > > pki int_net key "/etc/ssl/private/smtp.example.com.key"
> > > 
> > > table aliases file:/etc/mail/aliases
> > > 
> > > filter "dkimsign_loc_rsa" proc-exec "filter-dkimsign \
> > > -d smtp.example.com -s 10172021 \
> > > -k /etc/mail/dkim/10172021.rsa

Re: dkimsign uses unexpected domain in signature on message from Ubuntu/Postfix relay client

[Martijn van Duren]

On Tue, 2021-11-23 at 08:47 -0800, Paul Pace wrote:
> Hello!
> 
> I have an Ubuntu 18.04 server running Postfix 3.3 that relays through a 
> local OpenSMTPD mail relay on OpenBSD 7.0. Messages sent from system 
> messages and directly from mail command are signed by dkimsign as 
> expected.
> 
> Messages sent from letstencrypt run through cron.weekly are not being 
> signed by dkimsign with the expected domain. Log entries for correctly 
> signed and incorrectly signed messages are identical on both client and 
> relay server.
> 
> Here are the key portions of the header in the received inbox for the 
> cron.weekly job:
> 
> 
> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=10172021; 
> bh=rNFy7e0QC/J
>   YFcHTI8wUywlRSY3eJ4LLLsOZrSC0XBc=; h=date:subject:to:from;
>   d=example.com; b=KqmB7rxJfpLcF6Nif/4bQRAbcQDDhVmFh+8KDeCqc9ujlr8ogK7...
> Received: from relayclient.example.com ( [172.16.13.2])
>   by smtp.example.com (OpenSMTPD) with ESMTPS id 44fa8358 
> (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)
>   for ;
>   Sun, 14 Nov 2021 06:47:03 -0800 (PST)
> Received: by relayclient.example.com (Postfix)
>   id 881F75F401; Sun, 14 Nov 2021 06:47:03 -0800 (PST)
> Delivered-To: r...@relayclient.example.com
> Received: by relayclient.example.com (Postfix, from userid 0)
>   id 81D885F402; Sun, 14 Nov 2021 06:47:03 -0800 (PST)
>  From: r...@relayclient.example.com (Cron Daemon)
> To: r...@relayclient.example.com
> Subject: Cron  test -x /usr/sbin/anacron || ( cd / && 
> run-parts --report /etc/cron.weekly )
> MIME-Version: 1.0
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 8bit
> X-Cron-Env: 
> X-Cron-Env: 
> 
> X-Cron-Env: 
> X-Cron-Env: 
> Message-Id: <2024144703.81d885f...@relayclient.example.com>
> Date: Sun, 14 Nov 2021 06:47:03 -0800 (PST)
> 
> 
> Note in this above headers that d=example.com and expected is 
> d=relayclient.example.com
> 
> Here are the key portions of the headers in the received inbox from the 
> same client but for some other system message:
> 
> 
> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=10172021; 
> bh=r8XLAjeCvrx
>   jCndiJeywanw7UmGo9LRF4gIb07HheJc=; h=date:to:from:subject;
>   d=relayclient.example.com; 
> b=QfD3av5+JxEZyCgzeZ7GcnhIf3/sMmeCNDtEvz/4/hGZf...
> Received: from relayclient.example.com ( [172.16.13.2])
>   by relayclient.example.com (OpenSMTPD) with ESMTPS id b3c796f1 
> (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO)
>   for ;
>   Sat, 20 Nov 2021 06:40:29 -0800 (PST)
> Received: by relayclient.example.com (Postfix)
>   id AFFC95E476; Sat, 20 Nov 2021 06:40:29 -0800 (PST)
> Delivered-To: r...@relayclient.example.com
> Received: by relayclient.example.com (Postfix, from userid 0)
>   id A961A5F42E; Sat, 20 Nov 2021 06:40:29 -0800 (PST)
> Subject: unattended-upgrades result for relayclient.example.com: True
>  From: r...@relayclient.example.com
> To: r...@relayclient.example.com
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: quoted-printable
> Message-Id: <20211120144029.a961a5f...@relayclient.example.com>
> Date: Sat, 20 Nov 2021 06:40:29 -0800 (PST)
> 
> 
> Note in this above headers that d=relayclient.example.com, as expected.
> 
> Here is smtpd.conf:
> 
> 
> pki int_net cert "/etc/ssl/176.16.13.1.crt"
> pki int_net key "/etc/ssl/private/smtp.example.com.key"
> 
> table aliases file:/etc/mail/aliases
> 
> filter "dkimsign_loc_rsa" proc-exec "filter-dkimsign \
> -d smtp.example.com -s 10172021 \
> -k /etc/mail/dkim/10172021.rsa.key" user _dkimsign group _dkimsign
> 
> filter "dkimsign_int_rsa" proc-exec "filter-dkimsign \
> -d example.com \
> -d smtp.example.com \
> -d relayclient.example.com
> -s 10172021 -k /etc/mail/dkim/10172021.rsa.key" user _dkimsign group 
> _dkimsign
> 
> listen on socket
> listen on lo0 filter "dkimsign_loc_rsa"
> listen on vio1 tls pki int_net filter "dkimsign_int_rsa"
> 
> action "local_mail" mbox alias 
> action "local_redirect" relay host smtp+notls://127.0.0.1:25
> action "outbound" relay
> 
> match from socket action "local_redirect"
> match for local action "local_mail"
> match from any for any action "outbound"
> 
> 
> The vio1 interface is on the private network and access is controlled 
> through PF.
> 
> Thank you!
> 
> Paul
> 
I can't reproduce this in the most simple form and I don't notice
anything in the code that might point to a bug of this kind.
(tried with smtp(1) and a single filter with the subdomains in the
same order as you have)

What the code does: it starts with the first domain in the list (in this
case example.com) and then gets the domain part of the first e-mail
address in the from-list and compares it to all the specified domains,
if a match is found that domain is used. If none is found labels are
stripped from the from-domain until a match is found. If none is found
at all we stick with the first domain in the list.

Since I highly doubt 

Re: dkimsign doesn't sign message sent from mail command

[Martijn van Duren]

On Wed, 2021-10-20 at 20:19 -0700, p...@mostlybsd.com wrote:
> Hello!
> 
> I am killing myself on configuring this simple tool. Messages sent from 
> mail command ($ mail u...@example.com) aren't being signed but otherwise 
> arrive at the external receiving server with everything else looking 
> good.
> 
> smtpd.conf:
> 
> filter "dkimsign_rsa" proc-exec "filter-dkimsign -d smtp.mostlybsd.com 
> -s 10172021 \
>  -k /etc/mail/dkim/10172021.rsa.key" user _dkimsign group 
> _dkimsign
> 
> listen on socket filter "dkimsign_rsa"
> listen on lo0 filter "dkimsign_rsa"
> listen on vio1 filter "dkimsign_rsa"
> 
> action "outbound" relay
> 
> match from any for any action "outbound"
> 
> The only thing a little unusual in regards to dkimsign is I first 
> installed the ed25519 version, then deleted it (including pkg_delete -a 
> and removing user and group), then added again with the RSA only 
> version.
> 
> At the moment, I don't have anything else configured for sending mail 
> from this server.
> 
> If anyone can enlighten me as to what I am missing, I would really 
> appreciate it.
> 
> Thank you,
> 
> 
> Paul
> 
A quick test shows that 'listen on socket' does the trick for me.
Could you show how you actually submit the mail to smtpd? Do you use the
sendmail command, or are you using something else?

martijn@

Re: max-message-size

[Martijn van Duren]

This area of the code is not my strong suit, so my answer might be a
bit rough around the edges.

First of, a max-message-size-send doesn't make sense, since from the
perspective of smtpd an mbox delivery and relay are basically the
same, it's just some different backend code. So having a
max-message-size-recv of 35MB and max-message-size-send of 10MB would
result in the same behaviour in all cases: the limit will be 10MB.

If you want to expand on the train of thought and place a
max-message-size on action, this won't have the desired effect either,
because of the way smtpd is structured. A mail transaction works in
two phases.
In the first phase a mail is received (e.g. over smtp) and stored in a
backend (usually a file on disk) including some metadata.
In the second phase a mail and metadata is retrieved from the backend
and an appropriate action is choosen (e.g. relaying)

The problem arrises from the fact that these two phases are completely
independent from each other. As soon as a mail is committed ("." line in
the body) we can only state that we received it correctly and that it's
safe. If the commit is confirmed we can't be sure that it's send right
away (network issues, untimely restart of smtpd, ...). Now if during the
receiving and sending a config reload takes place we can't be sure that
the original action is still there or maybe the action changed because
the match rules changed.

This doesn't even include any issues further down the mail-path, e.g.
a final recipient might have a limit of 5MB. That's why we have the
report mails.

If you really do want this I suggest that you set up different servers
for incoming and outgoing mails.

martijn@

On Mon, 2021-07-12 at 13:44 +, Kent Watsen wrote:
> Would it be okay to add direction-specific versions of "max-message-size", 
> e.g., "max-message-size-send” and "max-message-size-recv”?
> 
> Reason:
> 
> My outbound email relay provider (amazonses) limits outbound message size to 
> 10M.   If I don’t set "max-message-size 10M” and accidentally send a larger 
> message, then my SMTP-client thinks the
> message is “sent” even though the backend relay fails.  Silent failures are 
> unacceptable to me, so I set "max-message-size 10M”.
> 
> But setting "max-message-size 10M” also limits inbound messages and I have a 
> contacts that like to send large attachments from time to time.  Fortunately 
> they do receive a “server reject due to
> size” message, and so know to instead try again by sending a link to some 
> file-service (e.g., dropbox), but apparently it’s enough of a hassle for them 
> to complain about.
> 
> 
> Thank you for your consideration.
> 
> Kent
> 
> 

Re: Tutorial for filter-dkimsign on Debian

[Martijn van Duren]

On Wed, 2021-06-23 at 15:52 +0100, Simon Harrison wrote:
> Not sure if I'm supposed to do this, but as I like to document things
> that I've found hard, I've put up a tutorial for getting dkim working
> with opensmtpd. The link is below in case it might help someone now or
> in the future:
> 
> https://simonh.uk/2021/06/23/get-dkim-working-with-opensmtpd/
> 

Note that with this setup you only sign mail received via the local unix
socket. In other words: via the sendmail command submission. Also, if
a mail is send via this way and smtpd is down it's "manually" queued by
smtpctl (in sendmail mode) itself, which circumvents the filter code.
If a mail is send over tcp via localhost it won't be signed, since it
doesn't have have the filter statement.

The filter command should be placed on each "listen on" statement you
want the filter to apply. Maybe you intend it like this, but if you're
going to post this it might become a pitfall for others.

Anyway, thanks for sharing and hope it runs well for you.

Re: filter-dkimsign -- listen on socket required?

[Martijn van Duren]

On Wed, 2021-06-23 at 14:13 +0100, Simon Harrison wrote:
> Afternoon all.
> 
> After *much* hunting around for examples, I've finally gotten
> filter-dkimsign working correctly (on Debian 10). 
> 
> from my /etc/smtpd.conf:
> 
> filter dkimsign proc-exec "filter-dkimsign -d mydomain.com -s 20210622
> -k /etc/mail/dkim/private.rsa.key" user _dkimsign group _dkimsign
> 
> listen on socket filter "dkimsign"
> listen on localhost tls pki mydomain.com
> 
> It turned out that the line:
> 
> listen on socket filter "dkimsign" 
> 
> did the trick. To be fair, it's right there on 
> 
> https://man.openbsd.org/smtpd.conf
> 
> but I must have continually missed it until now. Perhaps it might be
> helpful to have a couple of examples in the filter-dkimsign man page?
> 
> Also, it would be great to see this filter incorporated into the main
> package as the alternatives (dkimproxy, rspamd) seem to need ~200MB of
> ram.
> 
I worked hard recently to get it into Debian with rak@debian.[0][1]

A simple example of how to set it up is part of the OpenBSD package[2]
and will also be part of Debian's package[3].

"Unfortunately" Debian is currently getting ready for release, so it
might take some time before this work actually lands in the Debian
repos, but it's all queued up.

Hope this helps.

martijn@

[0] https://www.mail-archive.com/misc@opensmtpd.org/msg05329.html
[1] https://www.mail-archive.com/misc@opensmtpd.org/msg05336.html
[2] 
http://cvsweb.openbsd.org/ports/mail/opensmtpd-filters/dkimsign/pkg/README?rev=1.2=text/x-cvsweb-markup
[3] 
https://salsa.debian.org/debian/opensmtpd-filter-dkimsign/-/blob/debian/sid/debian/README.Debian

Re: New release libopensmtpd and filter-dkimsign

[Martijn van Duren]

On Thu, 2021-06-10 at 15:23 +0100, Simon Harrison wrote:
> On Thu, 10 Jun 2021 13:13:30 +0200
> Martijn van Duren  wrote:
> 
> > EHLO,
> > 
> > I just pushed a new release of libopensmtpd and filter-dkimsign to the
> > OpenBSD ports tree. These contains the following changes:
> > 
> > libopensmtpd (0.7):
> > - Registering OSMTPD_PHASE_LINK_CONNECT should be OSMTPD_TYPE_REPORT
> > - Fix manpage: 0 is for outgoing connections, not 2.
> >   From Edgar Pettijohn  pettijohn-web  com>
> > - Fix a spelling mistake.
> >   From Ryan Kavanagh  debian  org>
> > - Major overhaul of the Makefile.gnu so that things properly build on
> >   Debian (not relevant for OpenBSD)
> >   With Ryan Kavanagh  debian  org>
> > 
> > filter-dkimsign (0.5):
> > - Add support for ed25519. This currently requires openssl1.1
> > libcrypto and is thus only enabled in an ed25519 flavor of the
> > package. Lots of help from tb@ and sthen@
> > - Fix error handling in a couple of places
> > - Fix an initialization issue
> >   Spotted by Maarten de Vries  de-vri  es>
> > - Fix a couple of signedness warnings
> > - Allow filter-dkimsign to be build on Debian (not relevant for
> > OpenBSD) With Ryan Kavanagh  debian  org>
> > 
> > The two major things:
> > - filter-dkimsign now supports ed25519. Since LibreSSL doesn't have
> >   ed25519 signing yet it requires building against OpenSSL (I've only
> >   tested version 1.1). People on OpenBSD wanting to sign with ed25519
> >   should intall the ed25519 flavor, which links against openssl's
> >   libcrypto. Note that in my testing many major mail platforms don't
> >   support ed25519 verifying, so continuing to sign with RSA in
> > addition to ed25519 is still recommended.
> > - libopensmtpd and filter-dkimsign should now be able to build on
> > Debian without problems and should appear in the testing release of
> > Debian soon(tm). This also means that other Linux distros should
> > probably be able to compile and package them. If you run into issue
> > please contact me so that things can be ironed out.
> > 
> > For people who want to test filter-dkimsign on other platforms, the
> > source can be downloaded at:
> > https://distfiles.sigtrap.nl/libopensmtpd-0.7.tar.gz
> > https://distfiles.sigtrap.nl/filter-dkimsign-0.5.tar.gz
> > 
> > martijn@
> > 
> > 
> 
> Hello again. I've got libopensmtpd and filter-dkimsign compiled and
> installed successfully (I think) but something is wrong as no mail is
> sent with the below config. According to
> 
> https://dmarcly.com/tools/dkim-record-checker
> 
> everything is fine DNS wise. 
> 
> I used the sample from
> 
> https://openports.pl/path/mail/opensmtpd-filters/dkimsign
> 
> Here is my /etc/smtpd.conf:
> 
> #   $OpenBSD: smtpd.conf,v 1.10 2018/05/24 11:40:17 gilles Exp $
> 
> # This is the smtpd server system-wide configuration file.
> # See smtpd.conf(5) for more information.
> 
> table aliases file:/etc/aliases
> 
> # To accept external mail, replace with: listen on all
> #
> listen on localhost
> 
> action "local" maildir alias 
> action "relay" relay
> 
> # Uncomment the following to accept external mail for domain
> "example.org" #
> # match from any for domain "example.org" action "local"
> match for local action "local"
> match from local for any action "relay"
> 
> # Below is for filter-dkimsign
> filter "dkimsign" proc-exec "filter-dkimsign -d  -s -k

Missing domain and selector argument   ^^

> /mail/dkim/b0x.key" user _dkimsign group _dkimsign listen on localhost
> filter "dkimsign"
> 
> I'm wondered if the user and group might be the issue so commented them
> out, but that didn't help. 

The private key must be readable by the user under which the filter is
being executed. So if your permissions on /mail/dkim/b0x.key is not in
accordance with the user/group from your filter line it won't work.
> 
> Do I need to create a _dkimsign user and group? Any help appreciated. I
> feel so close now. I've tried rspamd and dkimproxy but they both use
> about 200MB on my server which seems somewhat heavy.

In most cases of misconfiguring the filter smtpd will crash immediately
after startup. What does your mail.log say (search for the name of the
filter as specified in your smtpd.conf).

Re: New release libopensmtpd and filter-dkimsign

[Martijn van Duren]

On Thu, 2021-06-10 at 12:35 +0100, Simon Harrison wrote:
> On Thu, 10 Jun 2021 13:13:30 +0200
> Martijn van Duren  wrote:
> 
> > EHLO,
> > 
> > I just pushed a new release of libopensmtpd and filter-dkimsign to the
> > OpenBSD ports tree. These contains the following changes:
> > 
> > libopensmtpd (0.7):
> > - Registering OSMTPD_PHASE_LINK_CONNECT should be OSMTPD_TYPE_REPORT
> > - Fix manpage: 0 is for outgoing connections, not 2.
> >   From Edgar Pettijohn  pettijohn-web  com>
> > - Fix a spelling mistake.
> >   From Ryan Kavanagh  debian  org>
> > - Major overhaul of the Makefile.gnu so that things properly build on
> >   Debian (not relevant for OpenBSD)
> >   With Ryan Kavanagh  debian  org>
> > 
> > filter-dkimsign (0.5):
> > - Add support for ed25519. This currently requires openssl1.1
> > libcrypto and is thus only enabled in an ed25519 flavor of the
> > package. Lots of help from tb@ and sthen@
> > - Fix error handling in a couple of places
> > - Fix an initialization issue
> >   Spotted by Maarten de Vries  de-vri  es>
> > - Fix a couple of signedness warnings
> > - Allow filter-dkimsign to be build on Debian (not relevant for
> > OpenBSD) With Ryan Kavanagh  debian  org>
> > 
> > The two major things:
> > - filter-dkimsign now supports ed25519. Since LibreSSL doesn't have
> >   ed25519 signing yet it requires building against OpenSSL (I've only
> >   tested version 1.1). People on OpenBSD wanting to sign with ed25519
> >   should intall the ed25519 flavor, which links against openssl's
> >   libcrypto. Note that in my testing many major mail platforms don't
> >   support ed25519 verifying, so continuing to sign with RSA in
> > addition to ed25519 is still recommended.
> > - libopensmtpd and filter-dkimsign should now be able to build on
> > Debian without problems and should appear in the testing release of
> > Debian soon(tm). This also means that other Linux distros should
> > probably be able to compile and package them. If you run into issue
> > please contact me so that things can be ironed out.
> > 
> > For people who want to test filter-dkimsign on other platforms, the
> > source can be downloaded at:
> > https://distfiles.sigtrap.nl/libopensmtpd-0.7.tar.gz
> > https://distfiles.sigtrap.nl/filter-dkimsign-0.5.tar.gz
> > 
> > martijn@
> > 
> > 
> 
> Hello. Just tried compiling on MX Linux 19.4 (Debian 10) and get this
> error:
> 
> $ make -f Makefile.gnu 
> cc -I/home/simon/src/libopensmtpd-0.7/
> -I/home/simon/src/libopensmtpd-0.7//openbsd-compat/ -Wall
> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
> -Wshadow -Wpointer-arith -Wcast-qual -Wsign-compare -fPIC
> -DNEED_RECALLOCARRAY=1 -DNEED_STRLCAT=1 -DNEED_STRLCPY=1
> -DNEED_STRTONUM=1   -c -o opensmtpd.o opensmtpd.c opensmtpd.c:27:10:
> fatal error: event.h: No such file or directory #include 
> ^ compilation terminated. make: *** [: opensmtpd.o]
> Error 1
> 
> 
> 
You're missing the libevent-dev.

When I get a header missing error I usually go to:
https://packages.debian.org and search via
"Search the contents of packages" for that particular file.

New release libopensmtpd and filter-dkimsign

[Martijn van Duren]

EHLO,

I just pushed a new release of libopensmtpd and filter-dkimsign to the
OpenBSD ports tree. These contains the following changes:

libopensmtpd (0.7):
- Registering OSMTPD_PHASE_LINK_CONNECT should be OSMTPD_TYPE_REPORT
- Fix manpage: 0 is for outgoing connections, not 2.
  From Edgar Pettijohn  pettijohn-web  com>
- Fix a spelling mistake.
  From Ryan Kavanagh  debian  org>
- Major overhaul of the Makefile.gnu so that things properly build on
  Debian (not relevant for OpenBSD)
  With Ryan Kavanagh  debian  org>

filter-dkimsign (0.5):
- Add support for ed25519. This currently requires openssl1.1 libcrypto and
  is thus only enabled in an ed25519 flavor of the package.
  Lots of help from tb@ and sthen@
- Fix error handling in a couple of places
- Fix an initialization issue
  Spotted by Maarten de Vries  de-vri  es>
- Fix a couple of signedness warnings
- Allow filter-dkimsign to be build on Debian (not relevant for OpenBSD)
  With Ryan Kavanagh  debian  org>

The two major things:
- filter-dkimsign now supports ed25519. Since LibreSSL doesn't have
  ed25519 signing yet it requires building against OpenSSL (I've only
  tested version 1.1). People on OpenBSD wanting to sign with ed25519
  should intall the ed25519 flavor, which links against openssl's
  libcrypto. Note that in my testing many major mail platforms don't
  support ed25519 verifying, so continuing to sign with RSA in addition
  to ed25519 is still recommended.
- libopensmtpd and filter-dkimsign should now be able to build on Debian
  without problems and should appear in the testing release of Debian
  soon(tm). This also means that other Linux distros should probably be
  able to compile and package them. If you run into issue please contact
  me so that things can be ironed out.

For people who want to test filter-dkimsign on other platforms, the source
can be downloaded at:
https://distfiles.sigtrap.nl/libopensmtpd-0.7.tar.gz
https://distfiles.sigtrap.nl/filter-dkimsign-0.5.tar.gz

martijn@

Re: smtpctl spf walk -6 ?

[Martijn van Duren]

On Wed, 2021-05-12 at 15:45 +0200, Harald Dunkel wrote:
> On 5/12/21 2:56 PM, Martijn van Duren wrote:
> > Apparently it's a problem in glibc's inet_net_pton. It does not support
> > AF_INET6. to.c has the same problem and works around this problem by
> > handcrafting broken_inet_net_pton_ipv6().
> > 
> 
> Would it be possible to use inet_pton() ?
> 
> 
> Regards
> Harri
> 
Nope, inet_pton doesn't support CIDR.
broken_inet_net_pton_ipv6() uses inet_pton internally.

Re: smtpctl spf walk -6 ?

[Martijn van Duren]

On Wed, 2021-05-12 at 13:33 +0200, Harald Dunkel wrote:
> On 5/12/21 8:56 AM, nathanael wrote:
> > 
> > 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
> > 
> 
> On OpenBSD 6.8 and 6.9 I get the expected result, too. The problem
> shows up on Debian 10 and Unstable (opensmtpd 6.8.0p2).
> 
> Using strace I verified that smtpctl and dig connect to the same DNS
> server. Yet dig reports the IPv6 addresses, smtptl spf walk doesn't.
> Its unlikely that the DNS server drops the IPv6 addresses from a TXT
> record, anyway.
> 
> Maybe its a problem of the BSD compatibility layer, included in
> the portable version?
> 
> 
> Regards
> Harri
> 
Apparently it's a problem in glibc's inet_net_pton. It does not support
AF_INET6. to.c has the same problem and works around this problem by
handcrafting broken_inet_net_pton_ipv6().

Someone from -portable should probably copy this function over to
spfwalk.c.

martijn@

filter-dkimsign: ed25519 support

[Martijn van Duren]

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) {

Re: dkim signing integrated in opensmtpd?

[Martijn van Duren]

On Mon, 2021-05-10 at 16:35 +0200, Harald Dunkel wrote:
> On 5/10/21 3:14 PM, Martijn van Duren wrote:
> > There's filter-dkimsign in packages, which is also mentioned in
> > smtpd.conf. I don't think there's a more lightweight solution
> > possible.
> > 
> 
> I had found your web site https://palant.info/2020/11/09/adding-\
> dkim-support-to-opensmtpd-with-custom-filters/, but it mentioned
> building opensmtpd-filter-dkimsign from "some Dutch web server".
> I didn't expect a package.

palant.info is not my website, but yes: I'm some dutch guy doing some
self hosting for some of my code. I don't see the problem in that.

Also, support for multiple domains landed in the my repository in
august 2020 and got released in september, so the article was already
outdated when published.
> 
> Actually I am running my major MTA with sendmail, still. The
> problem in this configuration is, the opendkim milter is called
> before masquerading is done. opendkim signs a header that is
> modified my sendmail later. (There are some workarounds, but they
> are unreliable.)
> 
> Is there a similar pitfall for opensmtpd-filter-dkimsign and
> opensmtpd?

Unfortunately the data goes through the filter before it goes through
the masquerade, so you either need to write a masquerade filter and
use that instead of smtpd's internal masquerade feature and you can
put that filter before the filter-dkimsign via chaining, or you need
to reroute the data over a loopback connection; similar to how
dkim signing was previously suggested:
https://poolp.org/posts/2018-05-21/switching-to-opensmtpd-new-config/
Personally I'd like to see a more elaborate senders/masquerade
functionality in filters at some point, but I haven't found the time
and proper inspiration to do so myself yet.

If you want to debug your dkim signatures you can add 1 or 2 -z flags
to filter-dkimsign, so that the headers at the time of signing are
placed inside the dkim header.

Hope this helps.

martijn@
> 
> 
> Regards
> Harri
> 

Re: dkim signing integrated in opensmtpd?

[Martijn van Duren]

On Mon, 2021-05-10 at 14:55 +0200, Harald Dunkel wrote:
> Hi folks,
> 
> Would it be possible to *integrate* dkim signatures in opensmtpd?
> I saw rspamd, but this is not an option. I am looking for a
> lightweight solution for signing EMail headers.
> 
> 
> Regards
> Harri
> 
There's filter-dkimsign in packages, which is also mentioned in
smtpd.conf. I don't think there's a more lightweight solution
possible.

martijn@

Re: smtpd failure

[Martijn van Duren]

The culrpit can be found...

On Wed, 2021-05-05 at 23:19 -0500, Hakan E. Duran wrote:
> Dear all,
> 
> After upgrading to OpenBSD 6.9 my smtpd server fails to run normally and
> exits with failure. I pasted the output of `#smtpd -dv` below. As you
> can see I redacted the server name, IP addresses, etc. from the output.
> Any pointers will be greatly appreciated.
> 
> Thanks,
> 
> Hakan
> 
> 
> 
> debug: init ssl-tree
> info: loading pki information for mail.myserver.com
> debug: init ca-tree
> debug: init ssl-tree
> info: loading pki keys for mail.myserver.com
> debug: using "fs" queue backend
> debug: using "ramqueue" scheduler backend
> debug: using "ram" stat backend
> info: OpenSMTPD 6.9.0 starting
> debug: init ssl-tree
> info: loading pki information for mail.myserver.com
> debug: init ca-tree
> debug: init ssl-tree
> info: loading pki keys for mail.myserver.com
> debug: init ssl-tree
> info: loading pki information for mail.myserver.com
> debug: init ca-tree
> debug: init ssl-tree
> info: loading pki keys for mail.myserver.com
> debug: init ssl-tree
> info: loading pki information for mail.myserver.com
> debug: init ca-tree
> debug: init ssl-tree
> info: loading pki keys for mail.myserver.com
> debug: using "fs" queue backend
> debug: using "ramqueue" scheduler backend
> debug: using "ram" stat backend
> setup_peer: queue -> control[12578] fd=4
> setup_peer: queue -> dispatcher[95018] fd=5
> setup_peer: queue -> lookup[358] fd=6
> setup_peer: queue -> scheduler[63225] fd=7
> debug: init ssl-tree
> info: loading pki information for mail.myserver.com
> debug: init ca-tree
> debug: init ssl-tree
> info: loading pki keys for mail.myserver.com
> debug: using "fs" queue backend
> debug: using "ramqueue" scheduler backend
> debug: using "ram" stat backend
> setup_peer: crypto -> control[12578] fd=4
> setup_peer: crypto -> dispatcher[95018] fd=5
> setup_done: ca[61403] done
> debug: using "fs" queue backend
> debug: using "ramqueue" scheduler backend
> debug: using "ram" stat backend
> setup_peer: lookup -> control[12578] fd=4
> setup_peer: lookup -> dispatcher[95018] fd=5
> setup_peer: lookup -> queue[89046] fd=6
> debug: init ssl-tree
> info: loading pki information for mail.myserver.com
> debug: init ca-tree
> debug: init ssl-tree
> info: loading pki keys for mail.myserver.com
> debug: using "fs" queue backend
> debug: using "ramqueue" scheduler backend
> debug: using "ram" stat backend
> setup_peer: dispatcher -> control[12578] fd=4
> setup_peer: dispatcher -> crypto[61403] fd=5
> setup_peer: dispatcher -> lookup[358] fd=6
> setup_proc: crypto done
> setup_peer: dispatcher -> queue[89046] fd=7
> debug: using "fs" queue backend
> debug: init ssl-tree
> debug: using "ramqueue" scheduler backend
> info: loading pki information for mail.myserver.com
> debug: using "ram" stat backend
> debug: init ca-tree
> setup_peer: control -> crypto[61403] fd=4
> debug: init ssl-tree
> setup_peer: control -> lookup[358] fd=5
> info: loading pki keys for mail.myserver.com
> setup_peer: control -> dispatcher[95018] fd=6
> debug: using "fs" queue backend
> setup_peer: control -> queue[89046] fd=7
> debug: using "ramqueue" scheduler backend
> setup_peer: control -> scheduler[63225] fd=8
> debug: using "ram" stat backend
> setup_done: control[12578] done
> setup_proc: lookup done
> setup_done: lka[358] done
> setup_proc: dispatcher done
> debug: rsa_engine_init: using RSA privsep engine
> debug: ecdsa_engine_init: using ECDSA privsep engine
> mta_postfork: local_mail
> mta_postfork: outbound
> setup_done: dispatcher[95018] done
> setup_proc: queue done
> debug: dispatcher: rsae_init
> setup_done: queue[89046] done
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> setup_peer: scheduler -> control[12578] fd=4
> setup_peer: scheduler -> queue[89046] fd=5
> setup_done: scheduler[63225] done
> smtpd: setup done
> setup_proc: control done
> setup_proc: scheduler done
> debug: bounce warning after 4h
> debug: parent_send_config_ruleset: reloading
> debug: parent_send_config: configuring dispatcher process
> debug: parent_send_config: configuring ca process
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: init private ssl-tree
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: dispatcher: rsae_init
> debug: 

Re: Monitoring SMTPD

[Martijn van Duren]

On Thu, 2021-04-29 at 07:30 +0200, Martijn van Duren wrote:
> On Thu, 2021-04-29 at 11:22 +1000, Antonino Sidoti wrote:
> > Hello,
> > 
> > I was wondering what options are available to monitor OpenBSD SMTPD? Can 
> > SNMP be utilise? My monitoring system is PRTG and I am using that for most 
> > of my systems. Can someone share their way of
> > monitoring please? I run two OpenSMTP mail servers and would very much like 
> > to get some insight as to how they are performing day to day. 
> > 
> > Thanks
> > 
> > Antonino Sidoti
> 
> I've build the following diff some time ago. But isn't going in as is,
> because the other devs want something like the filter interface for this
> feature, which is understandable. But that needs to be thought out fully
> and then also implemented, which might take some time. I'm currently
> focussing on other parts of the snmp stack before I want to venture into
> smtp processes again.
> 
> Anyway, the diff adds basic agentx support around the NETWORK-SERVICE-
> MIB (RFC2788) and the MTA-MIB (RFC2789). Feel free to use it, test it,
> and to report bugs. It will probably help keep things in shape, or maybe
> even improve its shape, until we finally have that external process.
> Keep in mind that this lacks the proper peer review expected from most
> OpenBSD base code.
> 
> Usage:
> Let net-snmpd (snmpd(8) currently has no agentx support) create an
> agentx socket:
>   master agentx
> smtpd connects via the parent process, which is root, so no need for
> custom agentXPerms.

Forgot to mention: start up net-snmpd with "-I-mta_sendmail", because
you get some garbage values from net-snmpd trying to interpret some
nonexisting sendmail (at least, that's my interpretation of the
output, haven't delved in too deep)

> Then you just add the following keyword to smtpd.conf
>   agentx
> And you can walk the data:
> martijn$ snmp walk 127.0.0.1 mib_2.27
> mib_2.27.1.1.2.1 = STRING: OpenSMTPd
> mib_2.27.1.1.3.1 = STRING: 
> mib_2.27.1.1.4.1 = STRING: 6.9.0
> mib_2.27.1.1.5.1 = Timeticks: (2100) 0:00:21.00
> mib_2.27.1.1.6.1 = INTEGER: 1
> mib_2.27.1.1.7.1 = Timeticks: (0) 0:00:00.00
> mib_2.27.1.1.16.1 = STRING: OpenSMTPD is a FREE implementation of the 
> server-side SMTP protocol as defined by RFC 5321, with some additional 
> standard extensions. It allows ordinary machines to
> exchange emails with other systems speaking the SMTP protocol.
> mib_2.27.1.1.17.1 = STRING: 
> martijn$ snmp walk 127.0.0.1 mib_2.28
> mib_2.28.1.1.1.1 = Counter32: 0
> mib_2.28.1.1.2.1 = Counter32: 0
> mib_2.28.1.1.3.1 = Counter32: 0
> mib_2.28.1.1.12.1 = Counter32: 0
> 
> You can set custom (agentx-master-)path and context as well.
> 
> If you have other applications running that uses the NETWORK-SERVICES
> MIB and you want predictable indices from the applIndex you can set it
> via the applIndex keyword. Keep in mind that your other applications
> need to play nice with the indexAllocate system in any case.
> 
> If you're running on !OpenBSD let me know, I have some diffs to make
> libagentx work on at least Ubuntu and maybe others.
> 
> martijn@
> 
> Index: agentx_control.c
> ===========
> RCS file: agentx_control.c
> diff -N agentx_control.c
> --- /dev/null   1 Jan 1970 00:00:00 -
> +++ agentx_control.c29 Apr 2021 05:22:14 -
> @@ -0,0 +1,279 @@
> +/* $OpenBSD$ */
> +
> +/*
> + * Copyright (c) 2020 Martijn van Duren 
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "log.h"
> +#include "smtpd.h"
> +
> +static void agentx_control_nofd(struct agentx *, void *, int);
> +static void agentx_control_tryconnect(int, short, void *);
> +static void agentx_control_read(int, short, void *);
> 

Re: Monitoring SMTPD

[Martijn van Duren]

On Thu, 2021-04-29 at 11:22 +1000, Antonino Sidoti wrote:
> Hello,
> 
> I was wondering what options are available to monitor OpenBSD SMTPD? Can SNMP 
> be utilise? My monitoring system is PRTG and I am using that for most of my 
> systems. Can someone share their way of
> monitoring please? I run two OpenSMTP mail servers and would very much like 
> to get some insight as to how they are performing day to day. 
> 
> Thanks
> 
> Antonino Sidoti

I've build the following diff some time ago. But isn't going in as is,
because the other devs want something like the filter interface for this
feature, which is understandable. But that needs to be thought out fully
and then also implemented, which might take some time. I'm currently
focussing on other parts of the snmp stack before I want to venture into
smtp processes again.

Anyway, the diff adds basic agentx support around the NETWORK-SERVICE-
MIB (RFC2788) and the MTA-MIB (RFC2789). Feel free to use it, test it,
and to report bugs. It will probably help keep things in shape, or maybe
even improve its shape, until we finally have that external process.
Keep in mind that this lacks the proper peer review expected from most
OpenBSD base code.

Usage:
Let net-snmpd (snmpd(8) currently has no agentx support) create an
agentx socket:
  master agentx
smtpd connects via the parent process, which is root, so no need for
custom agentXPerms.
Then you just add the following keyword to smtpd.conf
  agentx
And you can walk the data:
martijn$ snmp walk 127.0.0.1 mib_2.27
mib_2.27.1.1.2.1 = STRING: OpenSMTPd
mib_2.27.1.1.3.1 = STRING: 
mib_2.27.1.1.4.1 = STRING: 6.9.0
mib_2.27.1.1.5.1 = Timeticks: (2100) 0:00:21.00
mib_2.27.1.1.6.1 = INTEGER: 1
mib_2.27.1.1.7.1 = Timeticks: (0) 0:00:00.00
mib_2.27.1.1.16.1 = STRING: OpenSMTPD is a FREE implementation of the 
server-side SMTP protocol as defined by RFC 5321, with some additional standard 
extensions. It allows ordinary machines to
exchange emails with other systems speaking the SMTP protocol.
mib_2.27.1.1.17.1 = STRING: 
martijn$ snmp walk 127.0.0.1 mib_2.28
mib_2.28.1.1.1.1 = Counter32: 0
mib_2.28.1.1.2.1 = Counter32: 0
mib_2.28.1.1.3.1 = Counter32: 0
mib_2.28.1.1.12.1 = Counter32: 0

You can set custom (agentx-master-)path and context as well.

If you have other applications running that uses the NETWORK-SERVICES
MIB and you want predictable indices from the applIndex you can set it
via the applIndex keyword. Keep in mind that your other applications
need to play nice with the indexAllocate system in any case.

If you're running on !OpenBSD let me know, I have some diffs to make
libagentx work on at least Ubuntu and maybe others.

martijn@

Index: agentx_control.c
===
RCS file: agentx_control.c
diff -N agentx_control.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ agentx_control.c29 Apr 2021 05:22:14 -
@@ -0,0 +1,279 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2020 Martijn van Duren 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "log.h"
+#include "smtpd.h"
+
+static void agentx_control_nofd(struct agentx *, void *, int);
+static void agentx_control_tryconnect(int, short, void *);
+static void agentx_control_read(int, short, void *);
+static void agentx_control_emptystring(struct agentx_varbind *);
+static void agentx_control_applName(struct agentx_varbind *);
+static void agentx_control_applVersion(struct agentx_varbind *);
+static void agentx_control_applUptime(struct agentx_varbind *);
+static void agentx_control_applOperStatus(struct agentx_varbind *);
+static void agentx_control_applLastChange(struct agentx_varbind *);
+static void agentx_control_applDescription(struct agentx_varbind *);
+static void agentx_control_applURL(struct agentx_varbind *);
+static void agentx_control_mtaReceivedMessages(struct agentx_varbind *);
+static void agentx_control_mtaStoredMessages(struct agentx_varbind *);
+static void agentx_control_mtaTransmittedMessages(struct agentx_varbind *);
+static void agentx_control_mtaLoopsDetected(struct agentx_varbind *);
+
+static struct agentx *sa;
+static

Re: What DKIM RSA key length to use

[Martijn van Duren]

On Sun, 2021-04-11 at 04:13 +0200, Thomas Bohl wrote:
> Hello,
> 
> > In the filter-dkimsign readme I suggest to use 2048 and I stand by it.
> 
> Thanks for mentioning and coding filter-dkimsign! Somehow I was unaware 
> of it. I used rspamd just for DKIM. Which is overkill. The daemon racks 
> up nearly 28000 daily DNS requests to free services (like dnswl.org, 
> senderscore.com, spamhaus.org etc.) just by running. (I didn't use it as 
> an inbound filter. I overwrote rbl.conf. I have no clue what it is 
> doing.) So I switched to filter-dkimsign.

Glad you like it.
> 
> I also switched to a 2048 bits key. Which looks good so far. Ironically 
> only dkimvalidator.com had a problem verifying until I relaxed the 
> canonicalization algorithms.

That´s weird. I just tested this with simple/simple, relaxed/simple,
relaxed/relaxed and simple/relaxed, all with a 2048 bits key, but all my
messages got accepted. Can you reproduce this issue and share me the
content of the mail (ncluding headers) that had the issue?

> (Other tests like mail-tester.com or github.com/lieser/dkim_verifier had 
> no problem with it being simple.)
> 
Cool, it´s always good to hear from more test-cases.

martijn@

Re: RCPT syntax error from bank

[Martijn van Duren]

On Sun, 2021-04-04 at 07:03 -0600, Anthony J. Bentley wrote:
> Hi,
> 
> I had an interesting occurrence today... I was performing an action
> that required a confirmation code from my bank, which they sent by
> email. Unfortunately the mail never arrived, because:
> 
> Apr  4 03:25:16 axx smtpd[59645]: fdc8f818f7adb2aa smtp failed-command
> command="RCPT TO:<"username"@example.com>"
> result="501 5.1.3 Recipient address syntax error"
> 
> I assume the double quotes in there were the problem. I had to switch
> to a GMail account to receive it.
> 
Since everyone responding likes to point to what might be a nice and
comfy workaround, let me take some inspiration from RFC5321.

>From section 3.3:
  RCPT TO: [ SP  ] 

So let´s expand forward-path from section 4.1.2:
   Forward-path   = Path
   Path   = "<" [ A-d-l ":" ] Mailbox ">"
   Mailbox= Local-part "@" ( Domain / address-literal )
   Local-part = Dot-string / Quoted-string
  ; MAY be case-sensitive
   Quoted-string  = DQUOTE *QcontentSMTP DQUOTE

In other words: the bank is correct (although maybe a little unusual)
to use a double-quote surrounding the local-part. This should be fixed
in smtpd.

I´m not very familiar with that part of the code and I don´t know when
I have the time to look into it. If anyone else beats me to this I would
most welcome it. :-)

martijn@

Re: What DKIM RSA key length to use

[Martijn van Duren]

In the filter-dkimsign readme I suggest to use 2048 and I stand by it.
>From RFC1035:
 is a single
length octet followed by that number of characters.  
is treated as binary information, and can be up to 256 characters in
length (including the length octet).

Followed by:
TXT-DATAOne or more s.

An RR has an RDLENGTH of 16 bits, meaning that you can fit about shy of
64k characters in the RR devided over aprox 256 character strings. (not
accounting for the maximum DNS packet length).

Since you already pointed to RFC6376, also have a look at section
3.6.2.2:
   Strings in a TXT RR MUST be concatenated together before use with no
   intervening whitespace.

So if an implementation were to truncate a DKIM TXT record at the 255
bytes boundry, it is a violation of the RFC and the validator should be
fixed.

The same goes for SPF, which specifies in RFC7208 section 3.3:
   As defined in [RFC1035], Sections 3.3 and 3.3.14, a single text DNS
   record can be composed of more than one string.  If a published
   record contains multiple character-strings, then the record MUST be
   treated as if those strings are concatenated together without adding
   spaces.

martijn@


On Sun, 2021-03-28 at 16:46 +0200, Thomas Bohl wrote:
>  Hello,
>  
>  I only recently started to use DKIM and DMARC. (Yesterday to be exact. Now 
> mails to Gmail go to the inbox and not the spam-folder. Which is nice.) I 
> started with a 1024 bits RSA key.
>  
>  I followed
> https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/
>  and
>  https://prefetch.eu/blog/2020/email-server/#dkim
>  
>  poolp.org talks in length about why to use a 1024 bits key in order not to 
> truncate the DNS TXT record.
>  prefetch.eu uses 2048 bits and talks shortly about why not to use something 
> bigger. (Which makes sense, since RFC 6376 says that up to 2048 bits MUST be 
> supported and larger keys only MAY be.)
>  
>  Microsoft 365 talks about that 1024 and 2048 bitness is supported, but 
> defaults to 1024.
> https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dkim-to-validate-outbound-email?view=o365-worldwide#manually-upgrade-your-1024-bit-keys-to-2048-bit-dkim-encryption-keys
>  
>  Google Workspace recommends a key with 2048 bits, if your domain host can 
> manage it.
>  https://support.google.com/a/answer/174126
>  
>  
>  I guess my question is: Is the problem with a truncate the DNS TXT record, 
> as described on poolp.org still a think to worry about, or have think 
> improved since 2019 and one can unhesitatingly use a
> 2048 bits key?
>  
>  Thanks for reading
>  
>  

Re: smtpctl spf walk chokes on macros - is it possible to work around this?

[Martijn van Duren]

On Fri, 2021-03-19 at 11:46 +0100, Peter N. M. Hansteen wrote:
> Watching indly while I run the script that refreshes my nospamd data[1] I see
> several occurences of messages like
> 
> 
> processing verticalresponse.com
> smtpctl: lookup_record: %{i}._spf.mta.salesforce.com contains macros and 
> can't be resolved
> 
> digging through the dig $domain txt output turns up the salesforce.com record 
> is
> 
> _spf.salesforce.com.3512IN  TXT "v=spf1 
> exists:%{i}._spf.mta.salesforce.com -all"
> 
> is there a way to shoehorn this into something useful in our context?

I don't see how this can be done in a sane way, since the content of
the macro's isn't know at the time of resolving via spf walk.

In this particular case we would have to walk over every single ipv4
and ipv6 ip-address in existence and paste it before
_spf.mta.salesforce.com in order to know which hosts are allowed to
mail from spf.salesforce.com. Not something that's very likely.

*Maybe* there could be some option where we could add something like
`smtpctl spf walk -i 127.0.0.1 verticalresponse.com`, but I guess
that would not be a useful option for you, since you want to know
which hosts are allowed to begin with.

martijn@
> 
> All the best,
> Peter
> 
> [1] Described in 
> https://bsdly.blogspot.com/2018/11/goodness-enumerated-by-robots-or.html
> 

Re: what happened to smtpd-filters.7 ?

[Martijn van Duren]

filters are implemented in lka_filter.c.
According to cvs log filter.c is removed in 2017 and was probably part
of the first filter attempt.

smtpd-filters.7 has never been hooked up to the build. Probably
because it needs a little more scrutiny. But most in there can be
used.

martijn@

On Fri, 2021-03-19 at 07:56 +0100, Harald Dunkel wrote:
> Hi folks,
> 
> looking at github there is a file "smtpd-filters.7" and "filter.c"
> in smtpd, but apparently they are not used at build or install time.
> configure.ac doesn't mention them, either, so I wonder whats the
> story here? Have they been forgotten? Obsolete code?
> 
> 
> Regards
> Harri
> 

Re: how to watch opensmtpd filters at work?

[Martijn van Duren]

Could you show your config, steps to reproduce and expected behaviour?
Because I'm not entirely sure what you try to achieve.

On Thu, 2021-01-07 at 13:24 +0100, Harald Dunkel wrote:
> On 1/7/21 1:03 PM, Martijn van Duren wrote:
> > Your question isn't really specific, but my best guess is that -Tfilters
> > will do the trick.
> > 
> 
> I tried "smtpctl trace all", but there was no visual effect.
> 
> 
> Regards
> Harri
> 

Re: how to watch opensmtpd filters at work?

[Martijn van Duren]

Your question isn't really specific, but my best guess is that -Tfilters
will do the trick.

martijn@

On Thu, 2021-01-07 at 12:45 +0100, Harald Dunkel wrote:
> Hi folks,
> 
> for debugging I would like to know which "match" line does
> actually match the incoming EMails. Is there some option for
> opensmtpd to watch it? "-v" seems to be insufficient.
> 
> Every insightful comment would be highly appreciated.
> 
> 
> Regards
> Harri
> 

filter-dkims support for multiple domains

[Martijn van Duren]

Hello,

I've always said that I would not add support for multiple domains in
filter-dkimsign until someone could point me to a good reason to do so.
Recently this was done by Maarten de Vries who pointed out to me that
there is such a requirement in DMARC (RFC7489 section 3.1) stating that
the DKIM signature must be aligned with the From-header.
Unforunately the from-header is a mailbox-list; I decided to only use
the first mailbox in the list, which should cover most use-cases.

As expected, this diff is more intrusive then I would've liked, but
works so far in my testing. It works by using a single selector and
trying to do a strict match on domain first, falling back to a relaxed
match if none is found and ultimately going for the first domain in the
list.

I would like to ask everyone who wants this feature to test this and
report back to me. I plan to create a new release in a week or 2 turning
it into a less voluntary test. :-)

Source-code can be found here (svn):
http://imperialat.at/dev/filter-dkimsign/
This is still OpenBSD only, but Maarten can probably supply people with
an arch-compatible version.

martijn@

Re: Usage example for filter-dnsbl

[Martijn van Duren]

I run filter-dnsbl as follow:

...
filter dnsbl proc-exec "filter-dnsbl -mv zen.spamhaus.org dnsbl.dronebl.org 
bl.spamcop.net"
...
listen on egress tls pki keys filter dnsbl
...

To be clear: filters in proc-exec chooes their own "phase, so there's no
need for you to worry about that. The only thing you need to know is
which blacklists you want to use and on which listen socket they should
be executed on (and optionally where in a filter-chain if you have
multiple).

martijn@

On Mon, 2020-08-17 at 11:23 +0200, Leo Unglaub wrote:
> Hey,
> i installed the filter "filter-dnsbl" from here 
> (http://imperialat.at/dev/filter-dnsbl/) and now i want to add it to my 
> config. However, i have to admit i have no idea how to do that? In what 
> "phase" should i put this filter? I looked around but i found a couple 
> of outdated blog posts on filters, but nothing current. I also read thru 
> here 
> (https://github.com/openbsd/src/blob/master/usr.sbin/smtpd/smtpd-filters.7), 
> but i found nothing.
> 
> If someone of you has a working example on how to use that filter, could 
> you please be so kind and send it to me?
> 
> Thanks so much and greetings
> Leo
> 

Re: Fwd: 553 ORCPT address syntax error on OpenBSD 6.7

[Martijn van Duren]

On Wed, 2020-07-29 at 02:57 -0400, Larkin Nickle wrote:
> On 2020-07-29 02:54, Martijn van Duren wrote:
> > I was talking about the mails we exchanged in private.
> > 
> > On Wed, 2020-07-29 at 02:51 -0400, Larkin Nickle wrote:
> > > I did obtain consent before sending here but didn't mention it.
> 
> Oh right, I'm sorry about that. I was under the impression I just 
> started a chain out of the mailing list by hitting the wrong reply 
> button somewhere and we just kept going out-of-list by mistake. You're 
> right, I should've asked.
> 
No harm done and apology accepted.

Re: Fwd: 553 ORCPT address syntax error on OpenBSD 6.7

[Martijn van Duren]

I was talking about the mails we exchanged in private.

On Wed, 2020-07-29 at 02:51 -0400, Larkin Nickle wrote:
> I did obtain consent before sending here but didn't mention it.

Re: Fwd: 553 ORCPT address syntax error on OpenBSD 6.7

[Martijn van Duren]

On Tue, 2020-07-28 at 22:05 -0400, Larkin Nickle wrote:
> On 2020-07-28 06:02, Martijn van Duren wrote:
> > On Tue, 2020-07-28 at 05:37 -0400, Larkin Nickle wrote:
> > > > Doing a little more searching on "ORCPT :1:1" shows me the following
> > > > links:
> > > > https://groups.google.com/forum/#!topic/mailing.postfix.users/a2wjRII3Q_Y
> > > > https://community.microfocus.com/t5/GroupWise-User-Discussions/550-5-7-1-Unable-to-relay-to-certain-provider/td-p/2302331?p=2287440
> > > > https://info-ims.arnold.narkive.com/GtKAJz28/off-topic-research-on-rcpt-to-s-orcpt-extension
> > > > All complaining about that postfix.
> > > > 
> > > > This looks more and more like a misfeature from groupwise. So unless
> > > > there is some solid evidence that this is actually allowed I'd tell
> > > > your colleague to either turn of this misfeature or change software.
> > > > Or my personal favourite: If I can't receive your mails because you
> > > > violate the protocol I can't handle any requests in those mails.
> > > > 
> > > 
> > > It doesn't actually seem like DSN is enabled as there's no "NOTIFY=" in
> > > the SMTP command either (in the last link they said turning off DSN
> > > server-side fixed things). GroupWise is a major email server software,
> > > if this is actually the issue I wonder if it would be better to just
> > > work around it (esp. since others seem to).
> > 
> > Just because it's major doesn't mean it does the correct thing, just
> > because others don't seem to trip over it doesn't mean it's wise to
> > deviate from the spec.
> > 
> > Personally I'm not inclined to change this check for (imho) the worst,
> > but I'm not the lead developer on this project. So if you want it
> > changed you can write a diff around the smtp_session.c code I pointed
> > to in my previous mail with a detailed explination on how this
> > improves the situation, how this header attribute is/can be used down
> > the line and how this may or may not negatively impact that downstream.
> > Even better would be if you can point to the part of the specifications
> > that allow for this behaviour.
> > 
> > It's quite a bit of work and it might still not be accepted. I'm
> > unlikely to commit it unless you can show me I'm wrong in my previous
> > assessment, but I won't object if you can show us it's not detrimental.
> > 
> > Hope this helps.
> > 
> 
> He got this reply from Micro Focus upon asking them about it:
> 
> ```
> I was able to find a defect that matched this issue back in 2009 for 
> GroupWise version 8.
> 
> The defect specifically mentions that we are following the RFC as directed:
> 
> The :1:1 is essential to GroupWise status tracking.
> The numbers represent the host and user numbers for the creating a 
> GroupWise internal status message.
> 
> According to the RFC, the format of the ORCPT is ;xtext
> We use RFC822 for the address type and we use xtext to contain the 
> information that we need, which is
> groupwise-::
> 
> xtext is defined (see http://tools.ietf.org/html/rfc3461) as any ASCII 
> characters between "!" and "~" excluding "+" and "="
> 
> If this were not the case, we would be seeing tons of undeliverables, 
> but we are not. GroupWise 18.2.1 was released on March 4th of this year 
> and this is the first case we have dealing with undeliverables because 
> of the RFC standard.
> ```
> 
> So according to them it should actually be okay and OpenSMTPD is wrong 
> here. (check 4. Additional parameters for RCPT and MAIL commands for 
> example)
> 

While they are correct that the ABNF only prescribes xtext, they fail to
look at the text the paragraph directly after it:

while the "xtext" portion contains an encoded representation of the
original recipient address using the rules in section 5 of this document.

and the paragraph after that opens with:

When initially submitting a message via SMTP, if the ORCPT parameter is
used, it MUST contain the same address as the RCPT TO address (unlike
the RCPT TO address, the ORCPT parameter will be encoded as xtext).

Now let's follow it to section 5.2.1 (final sentence):

(d) If any ORCPT parameter was present in the RCPT command for a
recipient when the message was received, an ORCPT parameter with the
identical original-recipient-address MUST appear in the RCPT command
issued for that recipient when relaying the message. (For example, the
MTA therefore MUST NOT change the case of any alphabetic characters in
an ORCPT parameter.) If no ORCPT parameter was p

Re: dmarc

[Martijn van Duren]

I'm not 100% sure what you mean, but let me give it a best effort.

On Sat, 2020-07-25 at 11:00 +0200, Peter J. Philipp wrote:
> Hi,
> 
> This is sorta a feature request.  A lot of people use dmarc to check for
> incoming mails.  Is there a way to turn off dmarc checking in the smtpd?
> This would be valuable for trusted sources such as mailing lists.

This reads as if you want to disable checking on the receiving end,
which is smtpd. This is not needed since smtpd has no support for
DMARC, SPF, or DKIM verification at this moment.
> 
> Let me give you an example.  I mail 1000 bytes to openbsd-misc and there is
> thousands of recipients on that mailing list.  When their software delivers
> to these thousands I get a DNS request (I'm predicting 40 bytes in the 
> question,
> and no less than 40 bytes in the answer * thousands) that's already a minimum
> of 80K bytes DNS traffic generated by a 1K byte mail.

If you're worried about those numbers I would stop hosting DNS yourself
and just put it at a company who can handle it.
> 
> It would be cool if OpenBSD could set a "X-DMARC-VERIFIED" header or something
> and based on a policy on every smtpd that receives this no dmarc dns request
> is caused.  This would make me very happy.

I'm not aware of this mail header, nor is google. Also this would make
your mail susceptible for a man in the middle to disabling DMARC.

But if you want this header you should be able to do this quite easily
with a custom filter. The documentation is not installed by default, but
a draft is available in the smtpd soures: smtpd-filters.7.
> 
> Is this all technically possible?
> 
> Best Regards,
> -peter
> 
martijn@

Re: Filter trustee src bypass - syntax error

[Martijn van Duren]

In that case we'd need to know which version of OpenSMTPd you're running
and your full configuration. This was just an educated guess, but
without all the information it's impossible to help you.

On 4/28/20 11:07 AM, KJ (Klaas Jan) Schuurs wrote:
> Dear Martijn,
> 
> Thank you for your answer. I've corrected my table definition to:
> 
> table trustedip file:/etc/mail/trustedip
> 
> I'm still getting syntax error on the line with:
> filter trusted phase mail-from match src  bypass
> 
> 
> 
> KJ (Klaas Jan) Schuurs
> 
> 
> 
> Martijn van Duren schreef op 2020-04-28 10:45:
>> On 4/28/20 10:29 AM, KJ (Klaas Jan) Schuurs wrote:
> 
>>> ***
>>> smtpd.conf
>>> ***
>>> table  file:/etc/mail/trustedip
>>
>> This should be:
>> table trustedip file:/etc/mail/trustedip
>>
>> Can you tell if it works with this change?
>>

Re: Filter trustee src bypass - syntax error

[Martijn van Duren]

On 4/28/20 10:29 AM, KJ (Klaas Jan) Schuurs wrote:
> Dear all,
> 
> Hi! This is the first time I'm posting to this mailinglist. English is 
> not my native language, so if I'm not making sense, then accept my 
> apologies.
> 
> First of all I would like to tell @Gilles and others that I love 
> opensmtpd. I've used it now for like two years and I like it way better 
> than postfix.
> 
> I'm trying to setup a filter bypass. I've looked at the example Gilles 
> has provided on his website.
> 
> ***
> smtpd.conf
> ***
> table  file:/etc/mail/trustedip

This should be:
table trustedip file:/etc/mail/trustedip

Can you tell if it works with this change?

> 
> filter trusted phase mail-from match src  bypass
> 
> listen on all tls pki example.com filter { trusted check_rdns ... }
> ***
> 
> ***
> /etc/mail/trustedip
> ***
> 192.168.1.0/24
> ***
> 
> When I do 'smtpd -n' I get a syntax error on the line where I define the 
> filter trusted.
> 
> I'm not sure what the error is.
> 
> I'm running openbsd 6.6 release.
> 
> Can someone shed some light on my syntax error?
> 
> Thank you!
> 
> With regards,
> 
> KJ (Klaas Jan) Schuurs
> 

Re: Custom filter

[Martijn van Duren]

On 4/16/20 3:58 PM, Jacky wrote:
> Hi,
> 
> I am using Opensmtp 6.6.4p1. I am going to use Opensmtp as outgoing SMTP 
> server, and use POP before SMTP method for authentication.
> 
> Is it possible for us to write and use custom filter ? If yes, is there any 
> information / resources available in the web ?
> 
> Jacky
> 

There are a couple of filters available, but I'm not aware of how
cross-platform available they are.
>From the OpenBSD ports tree there's the following written in go:
- https://github.com/poolpOrg/filter-rspamd
- https://github.com/poolpOrg/filter-senderscore
- spamassassin via https://www.umaxx.net
The latter has a couple of other filters, but aren't in the ports
tree, so probably have a little less testing.

I have written filter-dnsbl and filter-dkimsign in C:
- http://imperialat.at/dev/libopensmtpd/ (dependency for both)
- http://imperialat.at/dev/filter-dnsbl/
- http://imperialat.at/dev/filter-dkimsign/

I've got libopensmtpd to compile on Linux, but after that my need to get
them to work on Linux disappeared so the filters themselves never got 
there. If you want to use them I'm willing to help you set them up in 
your environment and commit the changes to my repo.

Other filters are relatively easy to write, but I don't think the
protocol is properly documented. You can look at this thread[0] as a
starting point, but there have been some minor changes since then, so
make sure to check your input.

martijn@

[0] https://www.mail-archive.com/misc@opensmtpd.org/msg03727.html

Re: Unable to setup my OpenSMTPd (version 6.6.4p1)

[Martijn van Duren]

On 4/15/20 11:21 AM, Pete wrote:
> Hey,
> 
>> match from any for rcpt-to  action action_relay
> shouldn't that be:
> match from any for domain mydoain.com rcpt-to  action 
> action_relay
> 
> 
Turns out you're right. I got my versions mixed up. For completeness:
The for rcpt-to  was added by gilles on 2019/11/26.
The 6.6.4 release was released on February 24th, but this was only
a bugfix release.

So the syntax will be valid for the next release.

martijn@

Re: Unable to setup my OpenSMTPd (version 6.6.4p1)

[Martijn van Duren]

On 4/15/20 5:50 AM, Jacky wrote:
> Hi,
> 
>  
> 
> I was unable to setup my Opensmtpd (version 6.6.4p1). At the end of this 
> message, there are content of the recipient table and smtpd.conf. When 
> opensmtpd start, I get the following error message :-
> 
>  
> 
>  /etc/opensmtpd/smtpd.conf:38: syntax error
> 
>  
> 
> Line 38 of smtpd.conf stand for the "match from ..." line. Can anybody please 
> advice what's wrong with my configuration file.
> 
>  
> 
> Thank you very much.
> 
>  
> 
>  
> 
> Jacky
> 
>  
> 
>  
> 
> #
> 
> #
> 
> #   /etc/opensmtpd/recipienttable
> 
> #
> 
> #
> 
>  
> 
> r...@mydomain.com
> 
> t...@mydomain.com
> 
>  
> 
>  
> 
> #
> 
> #
> 
> #   /etc/opensmtpd/smtpd.conf
> 
> #
> 
> #
> 
>  
> 
> pki server01 cert "/etc/opensmtpd/cert/mydomain.com/fullchain.cer"
> 
> pki server01 key "/etc/opensmtpd/cert/mydomain.com/mydomain.com.key"
> 
> pki server01 dhe auto
> 
>  
> 
> table table_recipient file:/etc/opensmtpd/recipienttable
> 
>  
> 
> listen on 192.168.0.2 port 25 tls pki server01 hostname mydomain.com
> 
> listen on 192.168.0.2 port 587 tls-require pki server01 hostname mydomain.com
> 
>  
> 
> action action_relay relay host smtp://127.0.0.1:10025
> 
> match from any for rcpt-to  action action_relay
> 
>  
> 
>  
> 

Your config file is not complete (it's far from 38 lines).
If I strip your config of tls and adjust the paths it works for me.

Could you send over your entire config? If you're not comfortable to do
it publicly feel free to do so in a personal mail.

martijn@

Re: opensmtpd 6.6.4p1 crashes on netbsd 9.0

[Martijn van Duren]

On 3/9/20 8:15 AM, Andi Vajda wrote:
> 
>> On Mar 8, 2020, at 23:58, Martijn van Duren  
>> wrote:
>>
>> I guess not a lot of opensmtpd developers have a NetBSD machine at hand
>> (I certainly don't). Could you supply us with a backtrace, which most
>> likely will be needed from the pony process.
> 
> Rebuilding with libressl 3.0.2 (instead of openssl 1.1.1d) worked around the 
> problem.

So it's safe for me to assume you're fine with applying the workaround
for every release and letting other people do the same?
> 
> Andi..
> 
>>
>> martijn@

Re: opensmtpd 6.6.4p1 crashes on netbsd 9.0

[Martijn van Duren]

I guess not a lot of opensmtpd developers have a NetBSD machine at hand
(I certainly don't). Could you supply us with a backtrace, which most
likely will be needed from the pony process.

martijn@

On 3/7/20 1:38 AM, Andi Vajda wrote:
> 
>   Hi,
> 
> I've been running opensmtpd 6.6.4p1 on netbsd 7.2 just fine.
> 
> I'm now upgrading to netbsd 9.0 and I'm seeing that opensmtpd 6.6.4p1 crashes
> when mail is submitted to it. The crash seems to happen right after 'message
> begin':
> 
>--- snip ---
> smtp: 0x7ad646215000: fd 24 from queue
> smtp: 0x7ad646215000: message fd 24
> smtp: 0x7ad646215000: message begin
> debug: parent -> pony: pipe closed
> debug: control -> pony express: pipe closed
> debug: control agent exiting
> smtpd: process pony socket closed
> debug: ca -> pony express: pipe closed
>--- snip ---
> 
> If I copy the smtpd binary built on netbsd 7.2 to netbsd 9.0 then smtpd works
> fine again:
>--- snip ---
> smtp: 0x76e3f19b8000: fd 24 from queue
> smtp: 0x76e3f19b8000: message fd 24
> smtp: 0x76e3f19b8000: message begin
> debug: 0x76e3f19b8000: end of message, error=0
> ad1ae4fedfe423f1 smtp message msgid=c931775c size=567 nrcpt=1 proto=ESMTP
>--- snip --- 
> and mail is delivered as expected.
> 
> There is an ldd difference between the two binaries:
> 
> on netbsd 7.2:
>  -lz.1 => /usr/pkg/lib/libz.so.1
>  -lgcc_s.1 => /usr/lib/libgcc_s.so.1
>  -lc.12 => /usr/lib/libc.so.12
>  -lcrypto.1.1 => /usr/pkg/lib/libcrypto.so.1.1
>  -lpthread.1 => /usr/lib/libpthread.so.1
>  -lssl.1.1 => /usr/pkg/lib/libssl.so.1.1
>  -levent-2.1.7 => /usr/pkg/lib/libevent-2.1.so.7
>  -lasr.0 => /usr/pkg/lib/libasr.so.0
>  -lcrypt.1 => /usr/lib/libcrypt.so.1
> 
>   on netbsd 9.0:
>  -lz.1 => /usr/pkg/lib/libz.so.1
>  -lc.12 => /usr/lib/libc.so.12
>  -lcrypto.1.1 => /usr/pkg/lib/libcrypto.so.1.1
>  -lpthread.1 => /usr/lib/libpthread.so.1
>  -lssl.1.1 => /usr/pkg/lib/libssl.so.1.1
>  -levent-2.1.7 => /usr/pkg/lib/libevent-2.1.so.7
>  -lasr.0 => /usr/pkg/lib/libasr.so.0
>  -lcrypt.1 => /usr/lib/libcrypt.so.1
> 
> The -lgcc_s.1 entry is not present on 9.0.
> 
> The compiler used on netbsd 7.2: gcc (nb2 20150115) 4.8.5
> The compiler used on netbsd 9.0: gcc (nb3 20190319) 7.4.0
> 
> I also tried building opensmtpd 6.6.2p1 on netbsd 9.0, with the same result.
> 
> Is there something about netbsd 9.0 (and its gcc 7.4.0 system compiler) that
> is known to cause this ? Is there some configure setting I need to change ?
> (on both OSs, I'm only changing paths, ie --prefix, --with-libssl, 
> --with-libasr, --with-libevent as I'm using the pkgsrc installations (also 
> built from sources) of these libraries).
> 
> I'm going to try building opensmtpd with llvm next...
> Thank you for your insights !
> 
> Andi..
> 

Re: filter question

[Martijn van Duren]

On 3/6/20 5:00 PM, epektasis wrote:
> Greetings.  I have my own blacklist file of email addresses
> (some in the format microcen...@microcenter.com and some in 
> the format *@squaredeals.com), one per line.  I would like to
> filter each incoming email so that a mail-from address
> that matches any line in the blacklist file will go to a
> junk file.  In the smtpd.conf I have tried
> 
> table blksender file:/etc/blksender
> filter mail-from  junk
> match filter mail-from  junk
> 
> but get syntax errors on both of the last two lines when
> checking the configuration.  There's something I'm not
> understanding and am asking for advice.
>   epektasis
> 
Have another look at the manpage:
 filter filter-name phase phase-name match conditions decision
 Register a filter filter-name.  A decision about what to do
 with the mail is taken at phase phase-name when matching
 conditions.  Phases, matching conditions, and decisions are
 described in MAIL FILTERING, below.

So without testing (you should do that yourself anyway) I think what you
want would be:

table blksender file:/etc/blksender
filter blksender phase mail-from match mail-from  junk
listen on   filter blksender

Re: Non stop /bsd: smtpctl[51626]: pledge "fattr", syscall 124

[Martijn van Duren]

Quite some time I made a change that made smtpctl use tmpfile(3).
Are you kernel, libc and smtpctl all up to date?
(e.g. did you compile smtpctl from source without updating libc)

martijn@

On 1/7/20 5:04 PM, Johannes Krottmayer wrote:
> On 07.01.20 at 07:22,  Mik J wrote:
>> Hello,
>>
>> I keep having these logs in my /var/log/messages do you know what this
>> means ?
>> Jan  7 06:51:01 v /bsd: smtpctl[51626]: pledge "fattr", syscall 124
>> Jan  7 06:52:01 v /bsd: smtpctl[64532]: pledge "fattr", syscall 124
>> Jan  7 06:52:01 v /bsd: smtpctl[13532]: pledge "fattr", syscall 124
>> Jan  7 06:53:01 v /bsd: smtpctl[20480]: pledge "fattr", syscall 124
>> Jan  7 06:53:01 v /bsd: smtpctl[70486]: pledge "fattr", syscall 124
>> Jan  7 06:54:01 v /bsd: smtpctl[88165]: pledge "fattr", syscall 124
>> Jan  7 06:54:01 v /bsd: smtpctl[96175]: pledge "fattr", syscall 124
>> Jan  7 06:55:01 v /bsd: smtpctl[22724]: pledge "fattr", syscall 124
>> Jan  7 06:55:01 v /bsd: smtpctl[56931]: pledge "fattr", syscall 124
>> Jan  7 06:55:01 v /bsd: smtpctl[99044]: pledge "fattr", syscall 124
>>
>> Thank you
> 
> FYI:
> 
> The pledge mechanism is a security feature from OpenBSD.
> 
> I your case it means that the kernel AFAIK has prevent "smtpctl" to call
> the function "fattr".
> 
> Details:
> https://man.openbsd.org/pledge.2
> 
> Cheers,
> Johannes K.
> 
> 
> 
> 

Re: Postgres backend missing?

[Martijn van Duren]

$ pkg_info -Q opensmtpd-extras
...
opensmtpd-extras-pgsql-6.4.0p0v0
...

On 12/8/19 7:04 PM, Norman Golisz wrote:
> Hi,
> 
> I'm currently migrating an old instance of OpenSMTPD (6.3) on OpenBSD to
> current.
> 
> This setup uses Postgres as backend for the user database. Now, it seems
> the Postgres backend is gone, because smtpd claims there is no such
> backend. Then I've installed the opensmtpd-extras package to no avail.
> 
> So, is the Postgres backend gone forever, WIP, or am I just failing to
> read manuals properly?
> 
> Thanks!
> 
> Norman
> 
> 

Re: opensmtpd setresgid ubuntu crash

[Martijn van Duren]

That seems to do the trick. Thanks.
Sorry for the noise.

On 11/15/19 11:40 AM, Gilles Chehade wrote:
> Try using the 6.6.1p1 tag, I'm currently reworking the dev branch to 
> completely revamp compat layer, things will be shaky for the next few days
> 
> On Nov 15, 2019 11:22, Martijn van Duren  wrote:
> 
> EHLO,
> 
> I'm currently trying to port filter-dnsbl to ubuntu, but I'm stuck at
> not being able to startup smtpd. Is there anyone who has seen this
> before and who has a (possible) solution?
> 
> This all is freshly installed.
> 
> OS: Ubuntu 18.04.3 LTS
> OpenSMTPD: git portable (latest)
> Installed packages:
> - build-essential
> - autoconf
> - libtool
> - libssl-dev
> - libz-dev
> - bison
> - libasr-dev
> - gdb
> configure parameters: none
> backtrace:
> #0  setresgid (rgid=rgid@entry=1001, egid=1001, egid@entry= variable: DWARF-2 expression error: Loop detected (257).>, sgid=1001, 
> sgid@entry= (257).>) at setresgid.c:29
> #1  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #2  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #3  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #4  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #5  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #6  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #7  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #8  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #9  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #10 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #11 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #12 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #13 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #14 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #15 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #16 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #17 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #18 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #19 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #20 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).>) at setresgid.c:29
> #21 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid= reading variable: DWARF-2 expression error: Loop detected (257).>, 
> sgid= (257).&

opensmtpd setresgid ubuntu crash

[Martijn van Duren]

EHLO,

I'm currently trying to port filter-dnsbl to ubuntu, but I'm stuck at
not being able to startup smtpd. Is there anyone who has seen this
before and who has a (possible) solution?

This all is freshly installed.

OS: Ubuntu 18.04.3 LTS
OpenSMTPD: git portable (latest)
Installed packages:
- build-essential
- autoconf
- libtool
- libssl-dev
- libz-dev
- bison
- libasr-dev
- gdb
configure parameters: none
backtrace:
#0  setresgid (rgid=rgid@entry=1001, egid=1001, egid@entry=, sgid=1001, 
sgid@entry=) at setresgid.c:29
#1  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#2  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#3  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#4  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#5  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#6  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#7  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#8  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#9  0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#10 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#11 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#12 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#13 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#14 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#15 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#16 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#17 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#18 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#19 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#20 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#21 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#22 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#23 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#24 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#25 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#26 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#27 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#28 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#29 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#30 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#31 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#32 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#33 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#34 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29
#35 0x55c9b388d0c8 in setresgid (rgid=rgid@entry=1001, egid=, sgid=) at setresgid.c:29


martijn@

Re: filter-rspamd DKIM checks failing intermittently.

[Martijn van Duren]

On 10/13/19 3:05 PM, Gilles Chehade wrote:
> I don't think that is the issue,

I never said it's the issue in this particular case, I said that non-RFC
line-endings are most definitively an issue with DKIM and that clients
who send incorrect line-endings should be fixed.

> it is probably the filter-rspamd reconstruction of the message that is 
> incorrect.

I'm not familiar enough with filter-rspamd to know if that's the case.
> 
> On Sun, Oct 13, 2019, 15:00 Martijn van Duren  <mailto:opensm...@list.imperialat.at>> wrote:
> 
> On 10/13/19 1:59 PM, Reio Remma wrote:
> > Hello!
> >
> > I finally moved to Rspamd (2.0) on my production server and I'm seeing
> > lots of failed DKIM checks, specifically dkim=fail (body hash did not
> > verify).
> >
> >
> > Authentication-Results: host.domain.com <http://host.domain.com>;
> >      dkim=fail (body hash did not verify) header.d=facebookmail.com 
> <http://facebookmail.com>
> > header.s=s1024-2013-q3 header.b=pNWbKJUd;
> >      dmarc=pass (policy=reject) header.from=facebookmail.com 
> <http://facebookmail.com>;
> >      spf=pass (host.domain.com <http://host.domain.com>: domain of 
> notificat...@facebookmail.com <mailto:notificat...@facebookmail.com>
> > designates 66.220.144.215 as permitted sender)
> > smtp.mailfrom=notificat...@facebookmail.com 
> <mailto:notificat...@facebookmail.com>
> >
> > My current stab-in-the-dark theory is that there might be something
> > going on with line endings when mails are fed to Rspamd.
> >
> > Any better theories? :)
> 
> It's a known issue that mails that don't end on \r\n (both \r\r\n and
> \n) cause issues. There's efforts going on to see how we can remedy
> this, but in the mean time tell your senders that they should fix their
> mails (RFC5321):
>    In addition, the appearance of "bare" "CR" or "LF" characters in text
>    (i.e., either without the other) has a long history of causing
>    problems in mail implementations and applications that use the mail
>    system as a tool.  SMTP client implementations MUST NOT transmit
>    these characters except when they are intended as line terminators
>    and then MUST, as indicated above, transmit them only as a 
>    sequence.
> >
> > Thanks,
> > Reio
> >
> >
> 

Re: filter-rspamd DKIM checks failing intermittently.

[Martijn van Duren]

On 10/13/19 1:59 PM, Reio Remma wrote:
> Hello!
> 
> I finally moved to Rspamd (2.0) on my production server and I'm seeing 
> lots of failed DKIM checks, specifically dkim=fail (body hash did not 
> verify).
> 
> 
> Authentication-Results: host.domain.com;
>      dkim=fail (body hash did not verify) header.d=facebookmail.com 
> header.s=s1024-2013-q3 header.b=pNWbKJUd;
>      dmarc=pass (policy=reject) header.from=facebookmail.com;
>      spf=pass (host.domain.com: domain of notificat...@facebookmail.com 
> designates 66.220.144.215 as permitted sender) 
> smtp.mailfrom=notificat...@facebookmail.com
> 
> My current stab-in-the-dark theory is that there might be something 
> going on with line endings when mails are fed to Rspamd.
> 
> Any better theories? :)

It's a known issue that mails that don't end on \r\n (both \r\r\n and
\n) cause issues. There's efforts going on to see how we can remedy
this, but in the mean time tell your senders that they should fix their
mails (RFC5321):
   In addition, the appearance of "bare" "CR" or "LF" characters in text
   (i.e., either without the other) has a long history of causing
   problems in mail implementations and applications that use the mail
   system as a tool.  SMTP client implementations MUST NOT transmit
   these characters except when they are intended as line terminators
   and then MUST, as indicated above, transmit them only as a 
   sequence.
> 
> Thanks,
> Reio
> 
> 

Re: How can I integrate opensmtpd with opendkim?

[Martijn van Duren]

Hello Ihor,

On 10/10/19 5:39 PM, Ihor Antonov wrote:
> Hello everyone,
> 
> I am seriously thinking about replacing Postfix with OpenSMTPD on my
> Linux box (I am very attracted by configuration simplicity and
> security-mindedness of the project)
> 
Good.
> 
> So I found this issue on github where Gilles is redirecting a user's
> question to mailing list.
> 
> https://github.com/OpenSMTPD/OpenSMTPD/issues/733
> 
> Unfortunately I did not find any follow-ups on the subject. Is
> opensmtpd + opendkim possible? I know that there is new filter API
> released recently, is it something that can be used to achieve this> 
> Or maybe it is possible to write some sort of C plugin? (akin to table
> lookup API)
> 
> I am not looking for any other DKIM solutions (dkimproxy is abandoned,
> and as for p5-Mail-DKIM I don't want to introduce Perl into my setup)
> 
> I am very new to OpenSMTPD so I apologize for possibly  stupid
> questions.

I'm not sure if you want to sign or verify signatures.
At the moment we have an API which allows us to write custom plugins and
I have written a dkim signer myself[0][1], but it's written specifically
for OpenBSD and I haven't tested it on Linux (probably needs a few
tweaks for that).

If you want something that does spamfiltering (including dkim verify)
see Gilles' rspamd plugin[2] or Joerg's spamassassin plugin[3].

If you're lazy just wait a few weeks for OpenBSD 6.6 to be released,
which will contain these filters in the package managers. If you
want to stay on Linux see how far you get with compiling these codebases
yourself and contact me once you need help (at least the dkimsign one).
> 
> 
> Thanks
> 
> ---
> Ihor Antonov
> 
> 
martijn@

[0] http://imperialat.at/dev/libopensmtpd/
[1] http://imperialat.at/dev/filter-dkimsign/
[2] https://github.com/poolpOrg/filter-rspamd/
[3] https://www.umaxx.net

Re: Service names in listen on directives

[Martijn van Duren]

On 8/24/19 9:32 PM, Darren S. wrote:
> OpenBSD 6.5 amd64
> OpenSMTPD 6.5.0
> 
> port [port]
> Listen on the given port instead of the default port 25.
> 
> I wanted to confirm if service names are intended to be supported for
> `listen on` option in smtpd.conf.
> 
> These result in syntax failure:
> 
> listen on lo port smtp
> listen on lo port smtps
> 
> These do not:
> 
> listen on lo port 25
> listen on lo port 465
> 
> This also does not:
> 
> listen on lo port submission
> 
> Found it curious that `submission` may be used in place of a port
> number but not the other service names.
> 
Thanks for the report.
This should work in the next release.

Note that you can use the quoted syntax pointed out by gilles@ now and
will remain working after upgrading to the next release.

martijn@

Re: forcing SMTP authentication

[Martijn van Duren]

On 8/21/19 8:47 AM, Selmeci Tamás wrote:
> On Wed, 21 Aug 2019 08:19:24 +0200 Martijn van Duren
>  wrote:
> 
>> From smtpd.conf(5):
>>
>>  auth-optional []
>>  Support SMTPAUTH optionally: clients need not
>>  authenticate, but may do so.  This allows a listen on
>>  directive to both accept incoming mail from untrusted
>>  senders and permit outgoing mail from authenticated 
>> users
>>  (using match auth).  It can be used in situations where
>>  it is not possible to listen on a separate port (usually
>>  the submission port, 587) for users to authenticate.
> 
> Sounds good, but unauthenticated relaying still works with this...
> 
auth-optional []
...snip...
(using match auth)
...snip...

 match options action name
 If at least one mail envelope matches the options of one match
 action directive, receive the incoming message, put a copy into
 each matching envelope, and atomically save the envelopes to the
 mail spool for later processing by the respective dispatcher
 name.
...snip...
 [!] auth
 Matches transactions which have been authenticated.

Re: forcing SMTP authentication

[Martijn van Duren]

>From smtpd.conf(5):

 auth-optional []
 Support SMTPAUTH optionally: clients need not
 authenticate, but may do so.  This allows a listen on
 directive to both accept incoming mail from untrusted
 senders and permit outgoing mail from authenticated users
 (using match auth).  It can be used in situations where
 it is not possible to listen on a separate port (usually
 the submission port, 587) for users to authenticate.


On 8/21/19 7:39 AM, Selmeci Tamás wrote:
> Hello!
> 
> In brief: STARTTLS is enabled, there is a self-signed certificate for
> encryption (better than nothing), smarthost is used to send mails from
> my domain. My problem is that it still accepts SMTP connections (over
> TLS) without authentication. What I want:
> - anybody can send email to my email address in my domain (now it's
> working);
> - relaying through my SMTP server is allowed only after successful
> authentication (now anybody can relay through my server without
> authentication, e.g. to send spams). Authentication should be based on
> regular /etc/passwd file (local users of the computer). In order to
> hide the passwords, STARTTLS should be used;
> 
> It's a rather simple configuration, but I wasn't able to set it up. If
> I put 'auth' into the 'listen on' line, it needs authentication to any
> access of the SMTP server, so other machines (e.g. from google.com)
> can't send me mails. Using 'authenticated' in 'accept from' directives
> also didn't do the trick appropriately (it wasn't able to receive any
> mails at all).
> 
> Could you please help me out with this?
> 
> Thanks, regards,
> ---
> ---
> pki mail.486.hu certificate "/etc/smtpd/mail.486.hu.crt"
> pki mail.486.hu key "/etc/smtpd/mail.486.hu.key"
> 
> table cred file:/etc/smtpd/cred
> 
> listen on eth0  port 25 hostname mail.486.hu tls-require
> listen on localhost port 25 hostname mail.486.hu tls-require
> 
> # Storing mails arriving at the domain '486.hu'.
> accept from any for domain 486.hu deliver to mbox
> 
> # If the recipient is out of domain '486.hu', the mail is relayed through the
> # smarthost using TLS and authentication, see 'cred' file.
> accept from any for ! domain 486.hu relay via
> tls+auth://t-onl...@mail.t-online.hu auth  
> 

Re: How to deal with spam and opensmtpd

[Martijn van Duren]

On 04/19/18 13:36, Mik J wrote:
> I don't know how it works for you but for me these marketing companies change 
> their IPs every week (they use a few different subnets everyweek).
> So this task can be very time consuming.

This filters on sender e-mail address, not ip-address.
> 
> 
> Le jeudi 19 avril 2018 à 13:31:33 UTC+2, Martijn van Duren 
> <opensm...@list.imperialat.at> a écrit :
> 
> 
> Hello Mik,
> 
> On 04/19/18 13:18, Mik J wrote:
>> Thank you Simon for your answer.
>>
>> Actually, this marketing company is not doing heavy spam so they qualify 
>> mail adresses then have time to retry to send their email.
>> Their unsubscribe button is worthless.
>>
>> Another option could be to subscribe their services with a spamtrap adress.
>>
>> But I was wondering what do you guys use to filter content of emails at the 
>> smtp server level.
> 
> For these kind of cases I keep it rather low-tech. I added the following
> line to my smtpd.conf:
> reject from any sender  for any
> 
> and just manually add the the spam addresses to this table.
>>
>> Regards
>>
>> Le mercredi 18 avril 2018 à 22:50:32 UTC+2, Simon McFarlane <s...@desu.ne.jp 
>> <mailto:s...@desu.ne.jp>> a écrit :
>>
>>
>> On 04/18/2018 01:44 AM, Mik J wrote:> What other (not spamd and
>>
>> spamassassing) do you use ?
>>
>>
>> I use bgp-spamd [1] and a hand-assembled blacklist (using
>> dovecot-pigeonhole) of certain terms that usually only appear in spam.
>> It's not as good as SpamAssassin but it seems to stop the majority of
>> the spam I get. I'm down from 2-3 spam messages per day to one 10 days
>> or so.
>>
>> Simon
>>
>> [1] https://bgp-spamd.net/
>>
>> --
>> You received this mail because you are subscribed to misc@opensmtpd.org 
>> <mailto:misc@opensmtpd.org> <mailto:misc@opensmtpd.org 
>> <mailto:misc@opensmtpd.org>>
>> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org 
>> <mailto:unsubscr...@opensmtpd.org> <mailto:unsubscr...@opensmtpd.org 
>> <mailto:unsubscr...@opensmtpd.org>>
> 
>>
>>
> 
> -- 
> You received this mail because you are subscribed to misc@opensmtpd.org 
> <mailto:misc@opensmtpd.org>
> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org 
> <mailto:unsubscr...@opensmtpd.org>
> 

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: How to deal with spam and opensmtpd

[Martijn van Duren]

Hello Mik,

On 04/19/18 13:18, Mik J wrote:
> Thank you Simon for your answer.
> 
> Actually, this marketing company is not doing heavy spam so they qualify mail 
> adresses then have time to retry to send their email.
> Their unsubscribe button is worthless.
> 
> Another option could be to subscribe their services with a spamtrap adress.
> 
> But I was wondering what do you guys use to filter content of emails at the 
> smtp server level.

For these kind of cases I keep it rather low-tech. I added the following
line to my smtpd.conf:
reject from any sender  for any

and just manually add the the spam addresses to this table.
> 
> Regards
> 
> Le mercredi 18 avril 2018 à 22:50:32 UTC+2, Simon McFarlane  
> a écrit :
> 
> 
> On 04/18/2018 01:44 AM, Mik J wrote:> What other (not spamd and
> 
> spamassassing) do you use ?
> 
> 
> I use bgp-spamd [1] and a hand-assembled blacklist (using
> dovecot-pigeonhole) of certain terms that usually only appear in spam.
> It's not as good as SpamAssassin but it seems to stop the majority of
> the spam I get. I'm down from 2-3 spam messages per day to one 10 days
> or so.
> 
> Simon
> 
> [1] https://bgp-spamd.net/
> 
> -- 
> You received this mail because you are subscribed to misc@opensmtpd.org 
> 
> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org 
> 
> 
> 

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

deny sender not working completely.

[Martijn van Duren]

Hello,

For my mailserver I have a blacklist so that I can black annoying
senders. According to smtpd.conf(5) I should be able to block entire
domains by prepending a domain with '@', but this doesn't work for me.
An full email address is blocked.

martijn@

Version: OpenBSD 5.9-stable
$ cat /etc/mail/smtpd.conf
#   $OpenBSD: smtpd.conf,v 1.4 2012/07/16 05:56:16 jmc Exp $

# This is the smtpd server system-wide configuration file.
# See smtpd.conf(5) for more information.

pki keys certificate "/etc/ssl/mail.imperialat.at.crt"
pki keys key "/etc/ssl/private/mail.imperialat.at.key"

table authdb sqlite:/etc/mail/auth.conf
table rejectdb sqlite:/etc/mail/reject.conf
table blacklist sqlite:/etc/mail/blacklist.conf

filter dkim dkim-signer "-D" "imperialat.at" "-p"
"/etc/mail/dkim/private.key" "-s" "deathstar"

listen on egress tls pki keys auth-optional 
listen on all port submission filter dkim tls-require pki keys auth 

# Email addresses
table aliases db:/etc/mail/aliases.db

reject from any sender  for any
reject from any for domain  recipient 
accept from any for domain  virtual  userbase 
deliver to maildir "%{user.directory}/Maildir/%{dest.domain}/%{dest.user:strip}"

accept for local alias  deliver to mbox
accept for any relay
$ cat /etc/mail/blacklist.conf
dbpath  /etc/mail/storage.db

query_mailaddr SELECT sender FROM blacklist WHERE sender=?;
# sqlite3 /etc/mail/storage.db
sqlite> SELECT * FROM blacklist;
...
@bar.com
f...@bar.com
...
$ telnet mail.imperialat.at smtp
Trying 92.111.209.89...
Connected to imperialat.at.
Escape character is '^]'.
220 mail.imperialat.at ESMTP OpenSMTPD
HELO hackroom.obsd
250 mail.imperialat.at Hello hackroom.obsd [x.x.x.x], pleased to meet you
MAIL FROM: 
250 2.0.0: Ok
RCPT TO: 
250 2.1.5 Destination address valid: Recipient ok
QUIT
221 2.0.0: Bye
Connection closed by foreign host.
$ telnet mail.imperialat.at smtp
Trying 92.111.209.89...
Connected to imperialat.at.
Escape character is '^]'.
220 mail.imperialat.at ESMTP OpenSMTPD
HELO hackroom.obsd
250 mail.imperialat.at Hello hackroom.bsd [x.x.x.x], pleased to meet you
MAIL FROM: 
250 2.0.0: Ok
RCPT TO: 
550 Invalid recipient
QUIT
221 2.0.0: Bye
Connection closed by foreign host.

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: Pledge() in smtpd

[Martijn van Duren]

On 11/12/15 01:37, michalzient...@gmail.com wrote:

Hello guys,

Recently i was reading about new OpenBSD security mechanism called pledge(). I 
think this is another great idea from OpenBSD. Are you going to make use of it ?

Regards,
Michal Zientara



Pledge is already used within the OpenBSD tree[1], so yes.
On other platforms I can't tell you, since I'm not a developer on either 
smtpd or the other platforms, although I reckon it's highly unlikely, 
since it's an in kernel implementation. But as Theo stated[2]: someone 
smart might be able to build a compatible layer upon seccomp. Just don't 
hold your breath.


[1] 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/smtpd/smtpd.c?rev=1.254=text/x-cvsweb-markup

[2] http://www.openbsd.org/papers/hackfest2015-pledge/mgp00034.html

--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org