Re: No supported AUTH method

[Christian Schulte]

On 26.07.24 06:26, Ziqin Wang wrote:

On 2024/7/26 at 05:54, Christian Schulte wrote:

Just one example. There had been plenty of issues with Thunderbird, 
Outlook and whatever MUA misbehaving, downgrading to plaintext 
passwords without anyone noticing. I did not follow those issues over 
time. If I remember correctly, enabling PLAIN and LOGIN made most of 
those auto account setup dialogs "enter your email address and 
password and I will setup everything automatically for you" features 
setup things in the most insecure ways possible. That's the reason 
only CRAM-MD5 and DIGEST-MD5 were allowed. I remember, there was in 
issue with PLAIN and clients sending AUTH PLAIN 
base64(username:password) on one line before the MSA could reject by 
telling them to use STARTTLS before. OpenSMTPD does not send anything 
like that. I am a bit confused if I better not offer PLAIN and only 
LOGIN. There is not much you can do about MUAs behaving in those ways 
which is perfectly valid according to the RFCs. Veryfied the setup 
with telnet and sendmail does not offer AUTH until STARTTLS has been 
called and refuses to accept anything without authentication. That's 
pretty much what I needed it to do.


In OpenSMTPD smtpd.conf, you can use "tls-require" on SMTP submission 
port to force STARTTLS before offering AUTH.


With this setup, the Telnet log looks like:

220 mail.example.net ESMTP OpenSMTPD
EHLO client.example.com
250-mail.example.net Hello client.example.com [*], pleased to meet you
250-8BITMIME
250-ENHANCEDSTATUSCODES
250-SIZE 36700160
250-DSN
250-STARTTLS
250 HELP
AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ=
503 5.5.1 Invalid command: Command not supported
QUIT
221 2.0.0 Bye

Is this what you want, Christian?



No no. I was talking about sendmail behaviour from ancient times, right 
after AUTH and STARTTLS had been implemented. There is no 250-AUTH 
advertised, so a MUA sending an AUTH command in such a situation would 
be broken. If there would have been 250-AUTH in the EHLO response, the 
client would have behaved correctly. If the server responds with an 
error requesting the client to first issue STARTTLS, the clear text 
password would already have been send over the net. Let's not talk about 
issue solved decades ago. Everything is fine.


Regards,
--
Christian

Re: No supported AUTH method

[Christian Schulte]

On 26.07.24 10:57, Philipp wrote:

[2024-07-25 23:54] Christian Schulte 

On 25.07.24 16:52, Philipp wrote:

[2024-07-25 11:10] Christian Schulte 

The no-verify is due to the smarthost using a self signed certificate.


There is a (currently not fully documented) ca option for the relay
action. You can use this to verify the smarthost.


Thanks. Was searching the man page for a way to verify the certificate
in some way. That would have helped.


The documentation has been fixed.


[...]
I would not want to
enable clear text passwords on the smarthost. How to setup OpenSMTPD to
talk to that smarthost using STARTTLS and the supported AUTH methods?


First of all it's not a good idea to allow auth without tls. Also MD5
is not considered secure anymore.


The smarthost is a sendmail setup I am using since 2003 - 2 decades.
That setup has grown over time and had to deal with plenty of issues.
Mainly with broken MUAs. Enabling LOGIN and PLAIN, I am a bit paranoid I
am opening a can of worms I closed years ago. Haven't read sendmails
op.me for nearly 15 years. Enabled LOGIN and PLAIN, disabled CRAM-MD5
and DIGEST-MD5 and made sendmail refuse to accept those base64 based
mechanisms without STARTTLS. This is working now. I am not sure when
this option got introduced. Maybe I just oversaw it 2 decades ago. Maybe
that option got introduced somewhen without me noticing it.


I would guess this was introduced later, because of the downgrading
bugs/attacks.


Still catching up reading documentation.

Seems AuthOptions=p makes this work in sendmail. At least it behaves the 
same way OpenSMTPD does by not offering the AUTH capability without the 
client having issued STARTTLS successfully before.


p don't permit mechanisms susceptible to simple passive attack (e.g., 
PLAIN, LOGIN), unless a security layer is active.






By can of
worms I am talking about things like



Just one example. There had been plenty of issues with Thunderbird,
Outlook and whatever MUA misbehaving, downgrading to plaintext passwords
without anyone noticing. I did not follow those issues over time. If I
remember correctly, enabling PLAIN and LOGIN made most of those auto
account setup dialogs "enter your email address and password and I will
setup everything automatically for you" features setup things in the
most insecure ways possible. That's the reason only CRAM-MD5 and
DIGEST-MD5 were allowed. I remember, there was in issue with PLAIN and
clients sending AUTH PLAIN base64(username:password) on one line before
the MSA could reject by telling them to use STARTTLS before. OpenSMTPD
does not send anything like that. I am a bit confused if I better not
offer PLAIN and only LOGIN. There is not much you can do about MUAs
behaving in those ways which is perfectly valid according to the RFCs.
Veryfied the setup with telnet and sendmail does not offer AUTH until
STARTTLS has been called and refuses to accept anything without
authentication. That's pretty much what I needed it to do.


When you don't offer auth before STARTTLS, limiting auth to LOGIN doesn't
change anything. When a buggy client sends it's password before STARTTLS,
there is not mutch you can do against it[0]. But limit auth to LOGIN
doesn't harm.


I ended up with PLAIN as the only mechanism. A lot seems to have 
changed. For example, LOGIN and DIGEST-MD5 are obsolete. CRAM-MD5 is 
"limited". PLAIN is "common".




Maybe those will be removed in an upcoming Cyrus SASL release.




..

So with PLAIN only, it should be safe for the next upgrade.




So for your problem: In general there are two ways for remote password
auth. Send the plaintext password ower an encrypted channel or use some
challenge response method (i.e. cram or digets) to keep the password
secret from listeners. In both cases the channel must be authenticated
to be secure against active attacker.

The plain version has the benefit that you can store a hash of the password
on the server. So when somehow your database leaks an attacker can't use
the password. With the challenge response method your server must store
the password in plaintext.


This has been discussed to death on the SASL mailing list somewhen
around 2002. Sendmail is using SASL. Everyone complained about e.g.
sasldb storing plaintext passwords. I am wondering why the smtpd.conf
man page has exactly this in the examples. Would be better, if that man
page would not encourage anyone to store plaintext passwords in database
files and instead give examples on how to avoid that. Reading it, I just
remembered those complaints about sasldb and plaintext passwords and
just did not think about it.


Are you referencing the first example? There the password of the
client is stored in plaintext. When a client wants to use a password
to 

Re: No supported AUTH method

[Philipp]

[2024-07-25 23:54] Christian Schulte 
> On 25.07.24 16:52, Philipp wrote:
> > [2024-07-25 11:10] Christian Schulte 
> >> The no-verify is due to the smarthost using a self signed certificate.
> > 
> > There is a (currently not fully documented) ca option for the relay
> > action. You can use this to verify the smarthost.
>
> Thanks. Was searching the man page for a way to verify the certificate 
> in some way. That would have helped.

The documentation has been fixed.

> >> [...]
> >> I would not want to
> >> enable clear text passwords on the smarthost. How to setup OpenSMTPD to
> >> talk to that smarthost using STARTTLS and the supported AUTH methods?
> >
> > First of all it's not a good idea to allow auth without tls. Also MD5
> > is not considered secure anymore.
>
> The smarthost is a sendmail setup I am using since 2003 - 2 decades.
> That setup has grown over time and had to deal with plenty of issues.
> Mainly with broken MUAs. Enabling LOGIN and PLAIN, I am a bit paranoid I
> am opening a can of worms I closed years ago. Haven't read sendmails
> op.me for nearly 15 years. Enabled LOGIN and PLAIN, disabled CRAM-MD5
> and DIGEST-MD5 and made sendmail refuse to accept those base64 based
> mechanisms without STARTTLS. This is working now. I am not sure when
> this option got introduced. Maybe I just oversaw it 2 decades ago. Maybe
> that option got introduced somewhen without me noticing it.

I would guess this was introduced later, because of the downgrading
bugs/attacks.

> By can of
> worms I am talking about things like
>
> 
>
> Just one example. There had been plenty of issues with Thunderbird,
> Outlook and whatever MUA misbehaving, downgrading to plaintext passwords
> without anyone noticing. I did not follow those issues over time. If I
> remember correctly, enabling PLAIN and LOGIN made most of those auto
> account setup dialogs "enter your email address and password and I will
> setup everything automatically for you" features setup things in the
> most insecure ways possible. That's the reason only CRAM-MD5 and
> DIGEST-MD5 were allowed. I remember, there was in issue with PLAIN and
> clients sending AUTH PLAIN base64(username:password) on one line before
> the MSA could reject by telling them to use STARTTLS before. OpenSMTPD
> does not send anything like that. I am a bit confused if I better not
> offer PLAIN and only LOGIN. There is not much you can do about MUAs
> behaving in those ways which is perfectly valid according to the RFCs.
> Veryfied the setup with telnet and sendmail does not offer AUTH until
> STARTTLS has been called and refuses to accept anything without
> authentication. That's pretty much what I needed it to do.

When you don't offer auth before STARTTLS, limiting auth to LOGIN doesn't
change anything. When a buggy client sends it's password before STARTTLS,
there is not mutch you can do against it[0]. But limit auth to LOGIN
doesn't harm.

> > So for your problem: In general there are two ways for remote password
> > auth. Send the plaintext password ower an encrypted channel or use some
> > challenge response method (i.e. cram or digets) to keep the password
> > secret from listeners. In both cases the channel must be authenticated
> > to be secure against active attacker.
> >
> > The plain version has the benefit that you can store a hash of the password
> > on the server. So when somehow your database leaks an attacker can't use
> > the password. With the challenge response method your server must store
> > the password in plaintext.
>
> This has been discussed to death on the SASL mailing list somewhen
> around 2002. Sendmail is using SASL. Everyone complained about e.g.
> sasldb storing plaintext passwords. I am wondering why the smtpd.conf
> man page has exactly this in the examples. Would be better, if that man
> page would not encourage anyone to store plaintext passwords in database
> files and instead give examples on how to avoid that. Reading it, I just
> remembered those complaints about sasldb and plaintext passwords and
> just did not think about it.

Are you referencing the first example? There the password of the
client is stored in plaintext. When a client wants to use a password
to authenticate against a server, then the client allways needs the
password in plaintext. This is (more or less) true for all
authentication methods. Even with smartcards the smartcard needs access
to the raw private key.

On the server side this looks a bit different. For passwords the server
only needs a hash (with salt) of the password. Asuming a cryptographic
secure hash function, you can't restore the password from the hash. This
is done with the encrypt subcommand of smtpctl(8) in opensmtpd and non
hashed passwords are not supported (expect for details, to long to explain).

> > Because with server authentication you get encryption for free[0] it's
> > consider more secure to use plain text auth and store only a hash of

Re: No supported AUTH method

[Ziqin Wang]

On 2024/7/26 at 05:54, Christian Schulte wrote:

Just one example. There had been plenty of issues with Thunderbird, 
Outlook and whatever MUA misbehaving, downgrading to plaintext 
passwords without anyone noticing. I did not follow those issues over 
time. If I remember correctly, enabling PLAIN and LOGIN made most of 
those auto account setup dialogs "enter your email address and 
password and I will setup everything automatically for you" features 
setup things in the most insecure ways possible. That's the reason 
only CRAM-MD5 and DIGEST-MD5 were allowed. I remember, there was in 
issue with PLAIN and clients sending AUTH PLAIN 
base64(username:password) on one line before the MSA could reject by 
telling them to use STARTTLS before. OpenSMTPD does not send anything 
like that. I am a bit confused if I better not offer PLAIN and only 
LOGIN. There is not much you can do about MUAs behaving in those ways 
which is perfectly valid according to the RFCs. Veryfied the setup 
with telnet and sendmail does not offer AUTH until STARTTLS has been 
called and refuses to accept anything without authentication. That's 
pretty much what I needed it to do.


In OpenSMTPD smtpd.conf, you can use "tls-require" on SMTP submission 
port to force STARTTLS before offering AUTH.


With this setup, the Telnet log looks like:

220 mail.example.net ESMTP OpenSMTPD
EHLO client.example.com
250-mail.example.net Hello client.example.com [*], pleased to meet you
250-8BITMIME
250-ENHANCEDSTATUSCODES
250-SIZE 36700160
250-DSN
250-STARTTLS
250 HELP
AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ=
503 5.5.1 Invalid command: Command not supported
QUIT
221 2.0.0 Bye

Is this what you want, Christian?

--
Ziqin
A ship in harbor is safe, but that is not what ships are built for.

Re: No supported AUTH method

[Christian Schulte]

On 25.07.24 16:52, Philipp wrote:

[2024-07-25 11:10] Christian Schulte 

I'd like to setup opensmtpd on my laptop to use a self hosted smarthost.
In smtpd.conf I have:


action "outbound" relay host smtp+tls://user@smarthost:587 auth
 tls no-verify

The no-verify is due to the smarthost using a self signed certificate.


There is a (currently not fully documented) ca option for the relay
action. You can use this to verify the smarthost.


Thanks. Was searching the man page for a way to verify the certificate 
in some way. That would have helped.





[...]
Jul 25 10:57:52 x500 smtpd[29053]: 7ebb7ff8c6ccd82b mta error reason=no
supported AUTH method

[...]
250-AUTH DIGEST-MD5 CRAM-MD5
250-STARTTLS
250-DELIVERBY
250 HELP

Is DIGEST-MD5 and CRAM-MD5 supported by OpenSMTPD?


No only "auth plain" and "auth login" is suported.


Read smtp_session.c by now myself.




I would not want to
enable clear text passwords on the smarthost. How to setup OpenSMTPD to
talk to that smarthost using STARTTLS and the supported AUTH methods?


First of all it's not a good idea to allow auth without tls. Also MD5
is not considered secure anymore.


The smarthost is a sendmail setup I am using since 2003 - 2 decades. 
That setup has grown over time and had to deal with plenty of issues. 
Mainly with broken MUAs. Enabling LOGIN and PLAIN, I am a bit paranoid I 
am opening a can of worms I closed years ago. Haven't read sendmails 
op.me for nearly 15 years. Enabled LOGIN and PLAIN, disabled CRAM-MD5 
and DIGEST-MD5 and made sendmail refuse to accept those base64 based 
mechanisms without STARTTLS. This is working now. I am not sure when 
this option got introduced. Maybe I just oversaw it 2 decades ago. Maybe 
that option got introduced somewhen without me noticing it. By can of 
worms I am talking about things like




Just one example. There had been plenty of issues with Thunderbird, 
Outlook and whatever MUA misbehaving, downgrading to plaintext passwords 
without anyone noticing. I did not follow those issues over time. If I 
remember correctly, enabling PLAIN and LOGIN made most of those auto 
account setup dialogs "enter your email address and password and I will 
setup everything automatically for you" features setup things in the 
most insecure ways possible. That's the reason only CRAM-MD5 and 
DIGEST-MD5 were allowed. I remember, there was in issue with PLAIN and 
clients sending AUTH PLAIN base64(username:password) on one line before 
the MSA could reject by telling them to use STARTTLS before. OpenSMTPD 
does not send anything like that. I am a bit confused if I better not 
offer PLAIN and only LOGIN. There is not much you can do about MUAs 
behaving in those ways which is perfectly valid according to the RFCs. 
Veryfied the setup with telnet and sendmail does not offer AUTH until 
STARTTLS has been called and refuses to accept anything without 
authentication. That's pretty much what I needed it to do.




So for your problem: In general there are two ways for remote password
auth. Send the plaintext password ower an encrypted channel or use some
challenge response method (i.e. cram or digets) to keep the password
secret from listeners. In both cases the channel must be authenticated
to be secure against active attacker.

The plain version has the benefit that you can store a hash of the password
on the server. So when somehow your database leaks an attacker can't use
the password. With the challenge response method your server must store
the password in plaintext.


This has been discussed to death on the SASL mailing list somewhen 
around 2002. Sendmail is using SASL. Everyone complained about e.g. 
sasldb storing plaintext passwords. I am wondering why the smtpd.conf 
man page has exactly this in the examples. Would be better, if that man 
page would not encourage anyone to store plaintext passwords in database 
files and instead give examples on how to avoid that. Reading it, I just 
remembered those complaints about sasldb and plaintext passwords and 
just did not think about it.




Because with server authentication you get encryption for free[0] it's
consider more secure to use plain text auth and store only a hash of
the password. This is also secure with self signed certs, because most
user agents use trust on first use when the server use a self signed
cert.

So I would sugguest to copy your cert to the client and configure a ca
to verify the server. Keep in mind your cert needs to have the hostname
in the subject or subjectAltName. Then hash the passwords on the server
and change the authentication methode to plain or login.

Philipp

[0] I assume over the Internet



Deploying certificates and encouraging users to use S/MIME never worked 
out. It's just to complex to setup for the average user. Would go that 
route personally, of course.


Regards,
--
Christian

Re: No supported AUTH method

[Philipp]

[2024-07-25 11:10] Christian Schulte 
> I'd like to setup opensmtpd on my laptop to use a self hosted smarthost. 
> In smtpd.conf I have:
>
>
> action "outbound" relay host smtp+tls://user@smarthost:587 auth 
>  tls no-verify
>
> The no-verify is due to the smarthost using a self signed certificate.

There is a (currently not fully documented) ca option for the relay
action. You can use this to verify the smarthost.

> [...]
> Jul 25 10:57:52 x500 smtpd[29053]: 7ebb7ff8c6ccd82b mta error reason=no 
> supported AUTH method
>
> [...]
> 250-AUTH DIGEST-MD5 CRAM-MD5
> 250-STARTTLS
> 250-DELIVERBY
> 250 HELP
>
> Is DIGEST-MD5 and CRAM-MD5 supported by OpenSMTPD?

No only "auth plain" and "auth login" is suported.

> I would not want to 
> enable clear text passwords on the smarthost. How to setup OpenSMTPD to 
> talk to that smarthost using STARTTLS and the supported AUTH methods?

First of all it's not a good idea to allow auth without tls. Also MD5
is not considered secure anymore.

So for your problem: In general there are two ways for remote password
auth. Send the plaintext password ower an encrypted channel or use some
challenge response method (i.e. cram or digets) to keep the password
secret from listeners. In both cases the channel must be authenticated
to be secure against active attacker.

The plain version has the benefit that you can store a hash of the password
on the server. So when somehow your database leaks an attacker can't use
the password. With the challenge response method your server must store
the password in plaintext.

Because with server authentication you get encryption for free[0] it's
consider more secure to use plain text auth and store only a hash of
the password. This is also secure with self signed certs, because most
user agents use trust on first use when the server use a self signed
cert.

So I would sugguest to copy your cert to the client and configure a ca
to verify the server. Keep in mind your cert needs to have the hostname
in the subject or subjectAltName. Then hash the passwords on the server
and change the authentication methode to plain or login.

Philipp

[0] I assume over the Internet

Re: Table C API

[Philipp]

[2024-07-11 12:00] Omar Polo 
> Sorry for the long delay, I just missed the previous mail in the
> backlog, I'm afraid.
>
> Please don't feel bad to send a ping message if you don't hear a reply
> in about a week, sometimes life just get in the way and the mails lost
> in the backlog.
>
> Philipp  wrote:
> > Hi
> > 
> > [2024-05-30 21:54] Philipp 
> > > I'm currently working on the C API for the tables implementations. The
> > > current API has the problem that the callbacks mixes request and
> > > response. So I have created a new C api with callbacks for requests
> > > and extra functios for response. The callbacks looks the following:
> > >
> > > [...]
> > >
> > > What do you think about the new API?
>
> Mostly looking good to me.  I have a few nits and ideas on how we can
> further simplify all of this so the table_stdio.c layer can remain very
> simple.
>
> > > I have also implement some fallback handler for the old api. They are
> > > primary for simpler testing and development. Patcher are tested with
> > > table-ldap and attached. The patches are currenty seperated by query
> > > type. For the push I would put them togetter in one commit.
>
> Actually the backward compat is not important.  This is an internal
> library used by a few tables, it's not published standalone and we don't
> make any compatibility promise of any sort (ABI or API.)
>
> It's fine to break the ABI/API if it makes sense, and I can help
> migrating the existing code to the new one.

The backwards compatibility helps me to develop and test my changes.
Also they are quite simple to implement. Also the old methods are marked
as depricated. I would remove them if/when they are not needed anymore.
But yes backward compatibility is not importend, but when it's easy to
implement I take it.

> > > My next step is to change the getline loop to a pool based loop. Then
> > > add some registration for other fd. This way the backend can be full
> > > asyncron.
>
> I think this is fine but table_stdio.c is not the right place to do so.
> event loop are delicate, the application might need to schedule its own
> events (at least postgres could query asynchronously the db IIRC) so I
> prefer not to force the event loop in table_stdio.c.  Not all tables
> need to be asynchronous.

The loop is to suport asynchronous implementation. For example with
postgres[0] you get the underlining fd. Then you can call a search and
wait (i.e. with poll) till the fd has some data. As far as I see
something like this is also possible with all other tables.

> What table_stdio.c should be in my opinion is just a tiny layer to parse
> a line into a struct or something equivalent and write the replies.
> Once it does this, then writing both blocking and async tables on top
> becomes way more easy.

Writing a blocking table is as easy as before. You register your callbacks
and in your callbacks you block till the table has finished.

For an async/nonblocking table you register also your fd and get called
when the fd is ready. After that you can check what data is returned in
your fd and return the new data.

> > I now also have implemented a simple poll based event loop. So a table
> > implementation can register fds with the following api:
> > 
> > void table_api_register_fd(int fd, short events, fd_callback cb);
> > void table_api_replace_fd(int old, int new);
> > void table_api_remove_fd(int fd);
>
> So this is what I'd avoid.  Let's try to have each layer doing one thing
> only (more or les), and leave the fd tracking and correlate events to
> other layers.

I have implementented this because I want to avoid duplicated code. When
you look at the current tables they all look quite similar[1]. So when
all table already does the same then the API could take this job.

> I'd refactor the changes so that the APIs exported are something like
> this, but mind you that this is just a suggestion, I haven't implemented
> it
>
>   struct table_request {
>   enum table_operation op;
>   /* maybe even time_t timestamp; */
>   char*table_name;
>   enum table_service   service;
>   char*id;
>   char*key;
>   };
>
>   /* parses the line into the provided storage for the struct */
>   int table_api_parse_request(struct table_request *, char *);

I more or less have this function already. In handle_request a protocol
line is parsed in a request struct. This function then calles the
registerd callbacks. I have also planed to add some api to query open
requests. Make the handle_request api pulbic (with some changes) is also
posible.

>   /* routines for the reply */
>   int table_api_update(struct table_request *, int);
>   int table_api_error(struct table_request *, const char *);
>   int table_api_found(struct table_request *, const char *);
>   int table_api_not_found(struct table_request *);
>
> 

Re: Table C API

[Omar Polo]

Hello,

Sorry for the long delay, I just missed the previous mail in the
backlog, I'm afraid.

Please don't feel bad to send a ping message if you don't hear a reply
in about a week, sometimes life just get in the way and the mails lost
in the backlog.

Philipp  wrote:
> Hi
> 
> [2024-05-30 21:54] Philipp 
> > I'm currently working on the C API for the tables implementations. The
> > current API has the problem that the callbacks mixes request and
> > response. So I have created a new C api with callbacks for requests
> > and extra functios for response. The callbacks looks the following:
> >
> > void update_cb(const char *id, const char *tname)
> > void check_cb(const char *id, const char *tname, int service, const char 
> > *key)
> > void lookup_cb(const char *id, const char *tname, int service, const char 
> > *key)
> > void fetch_cb(const char *id, const char *tname, int service)
> >
> > These are called on for each request. The backend register these callbacks
> > and calles a response function:
> >
> > void table_api_update_finish(const char *id)
> > void table_api_check_result(const char *id, bool found)
> > void table_api_lookup_result(const char *id, const char *buf)
> > void table_api_lookup_finish(const char *id)
> > void table_api_fetch_result(const char *id, const char *buf)
> > table_api_error(const char *id, const char *error)
> >
> > In most cases the return value (found/not-found/ok) is implicit. For
> > lookup there are two functions for response, one for the value and one
> > to finish the lookup. This has two reasons: First this makes it simpler
> > to handle multible (i.e. for alias) responses. Secound this allows to
> > change the protokoll for more flexible lookup tables (usefull for dns
> > tables). The error function implicit respones with the correct result
> > type.
> >
> > What do you think about the new API?

Mostly looking good to me.  I have a few nits and ideas on how we can
further simplify all of this so the table_stdio.c layer can remain very
simple.

> > I have also implement some fallback handler for the old api. They are
> > primary for simpler testing and development. Patcher are tested with
> > table-ldap and attached. The patches are currenty seperated by query
> > type. For the push I would put them togetter in one commit.

Actually the backward compat is not important.  This is an internal
library used by a few tables, it's not published standalone and we don't
make any compatibility promise of any sort (ABI or API.)

It's fine to break the ABI/API if it makes sense, and I can help
migrating the existing code to the new one.

> > My next step is to change the getline loop to a pool based loop. Then
> > add some registration for other fd. This way the backend can be full
> > asyncron.

I think this is fine but table_stdio.c is not the right place to do so.
event loop are delicate, the application might need to schedule its own
events (at least postgres could query asynchronously the db IIRC) so I
prefer not to force the event loop in table_stdio.c.  Not all tables
need to be asynchronous.

What table_stdio.c should be in my opinion is just a tiny layer to parse
a line into a struct or something equivalent and write the replies.
Once it does this, then writing both blocking and async tables on top
becomes way more easy.

> I now also have implemented a simple poll based event loop. So a table
> implementation can register fds with the following api:
> 
> void table_api_register_fd(int fd, short events, fd_callback cb);
> void table_api_replace_fd(int old, int new);
> void table_api_remove_fd(int fd);

So this is what I'd avoid.  Let's try to have each layer doing one thing
only (more or les), and leave the fd tracking and correlate events to
other layers.

I'd refactor the changes so that the APIs exported are something like
this, but mind you that this is just a suggestion, I haven't implemented
it

struct table_request {
enum table_operation op;
/* maybe even time_t timestamp; */
char*table_name;
enum table_service   service;
char*id;
char*key;
};

/* parses the line into the provided storage for the struct */
int table_api_parse_request(struct table_request *, char *);

/* routines for the reply */
int table_api_update(struct table_request *, int);
int table_api_error(struct table_request *, const char *);
int table_api_found(struct table_request *, const char *);
int table_api_not_found(struct table_request *);

This could be the base layer, it just deal with parsing into caller
provided storage and fills the struct, then provides APIs to deal with
the reply.  No dependencies on anything else other than the stdlib.

(after this, we can also add stuff to deal with multiple lookup result, I
really like your proposals wrt the 

Re: Table C API

[Philipp]

Hi

[2024-05-30 21:54] Philipp 
> I'm currently working on the C API for the tables implementations. The
> current API has the problem that the callbacks mixes request and
> response. So I have created a new C api with callbacks for requests
> and extra functios for response. The callbacks looks the following:
>
> void update_cb(const char *id, const char *tname)
> void check_cb(const char *id, const char *tname, int service, const char *key)
> void lookup_cb(const char *id, const char *tname, int service, const char 
> *key)
> void fetch_cb(const char *id, const char *tname, int service)
>
> These are called on for each request. The backend register these callbacks
> and calles a response function:
>
> void table_api_update_finish(const char *id)
> void table_api_check_result(const char *id, bool found)
> void table_api_lookup_result(const char *id, const char *buf)
> void table_api_lookup_finish(const char *id)
> void table_api_fetch_result(const char *id, const char *buf)
> table_api_error(const char *id, const char *error)
>
> In most cases the return value (found/not-found/ok) is implicit. For
> lookup there are two functions for response, one for the value and one
> to finish the lookup. This has two reasons: First this makes it simpler
> to handle multible (i.e. for alias) responses. Secound this allows to
> change the protokoll for more flexible lookup tables (usefull for dns
> tables). The error function implicit respones with the correct result
> type.
>
> What do you think about the new API?
>
> I have also implement some fallback handler for the old api. They are
> primary for simpler testing and development. Patcher are tested with
> table-ldap and attached. The patches are currenty seperated by query
> type. For the push I would put them togetter in one commit.
>
> My next step is to change the getline loop to a pool based loop. Then
> add some registration for other fd. This way the backend can be full
> asyncron.

I now also have implemented a simple poll based event loop. So a table
implementation can register fds with the following api:

void table_api_register_fd(int fd, short events, fd_callback cb);
void table_api_replace_fd(int old, int new);
void table_api_remove_fd(int fd);

The callback looks like this:

typedef void (*fd_callback)(int fd, short revent);

So you the registered callback gets called with the fd and the revent
from poll. This make it easy to implement a full async table.

Patches[0] are attached. I don't have full tested them but first tests
look good.

Philipp

[0] I have included the previous patches, because I don't know if I have
send all updates and haven't rebased my local branch.
From c3996e9007e198f3c69f31c580890d8d1f42c938 Mon Sep 17 00:00:00 2001
From: Philipp Takacs 
Date: Sun, 19 May 2024 11:18:26 +0200
Subject: [PATCH 01/16] move request handling to seperate function

---
 table_stdio.c | 230 ++
 1 file changed, 121 insertions(+), 109 deletions(-)

diff --git a/table_stdio.c b/table_stdio.c
index 289deab..98b8df4 100644
--- a/table_stdio.c
+++ b/table_stdio.c
@@ -123,15 +123,132 @@ table_api_get_name(void)
 	return tablename;
 }
 
-int
-table_api_dispatch(void)
+static void
+handle_request(char *line, size_t linelen)
 {
 	char		 buf[LINE_MAX];
 	char		*t, *vers, *tname, *type, *service, *id, *key;
+	int		 sid, r;
+
+	t = line;
+	(void) linelen;
+
+	if (strncmp(t, "table|", 6))
+		errx(1, "malformed line");
+	t += 6;
+
+	vers = t;
+	if ((t = strchr(t, '|')) == NULL)
+		errx(1, "malformed line: missing version");
+	*t++ = '\0';
+
+	if (strcmp(vers, "0.1") != 0)
+		errx(1, "unsupported protocol version: %s", vers);
+
+	/* skip timestamp */
+	if ((t = strchr(t, '|')) == NULL)
+		errx(1, "malformed line: missing timestamp");
+	*t++ = '\0';
+
+	tname = t;
+	if ((t = strchr(t, '|')) == NULL)
+		errx(1, "malformed line: missing table name");
+	*t++ = '\0';
+	strlcpy(tablename, tname, sizeof(tablename));
+
+	type = t;
+	if ((t = strchr(t, '|')) == NULL)
+		errx(1, "malformed line: missing type");
+	*t++ = '\0';
+
+	if (!strcmp(type, "update")) {
+		if (handler_update == NULL)
+			errx(1, "no update handler registered");
+
+		id = t;
+		r = handler_update();
+		printf("update-result|%s|%s\n", id,
+		r == -1 ? "error" : "ok");
+		if (fflush(stdout) == EOF)
+			err(1, "fflush");
+		return;
+	}
+
+	service = t;
+	if ((t = strchr(t, '|')) == NULL)
+		errx(1, "malformed line: missing service");
+	*t++ = '\0';
+	sid = service_id(service);
+
+	id = t;
+
+	r = -1;
+	if (!strcmp(type, "fetch")) {
+		if (handler_fetch == NULL)
+			errx(1, "no fetch handler registered");
+
+		if (registered_services & sid) {
+			r = handler_fetch(sid, ,
+			buf, sizeof(buf));
+		}
+		if (r == 1)
+			printf("fetch-result|%s|found|%s\n", id, buf);
+		else if (r == 0)
+			printf("fetch-result|%s|not-found\n", id);
+		else
+			printf("fetch-result|%s|error\n", id);
+		if (fflush(stdout) == EOF)
+			err(1, "fflush");
+		memset(buf, 0, 

Re: match "tls" option implementation

[Tassilo Philipp]

nope, it could be a binary option to match the fact that tls was specified, or it could be an option 
with suboptions (tls cipher ..., tls version ...) to match a more specific criteria.


if you implement the more general feature, you still want to put the data for the more specific ones 
in the envelope to avoid having to many envelope format changes for foreseen features.


Yeah makes sense.


it means that we have to tell everyone "sorry, the new envelopes are incompatible, you need to empty 
the queue and reload smtpd", it's painful for users so you really want to avoid it at all cost. It's 
not always avoidable, so if you HAVE to provoke one, we want to make sure it contains all changes we 
will need for upcoming features too.


Understood. Yep, painful for sure - maybe it's avoidable, we'll see, not 
familiar enough with the code, yet. 
I won't hesitate to ask for suggestions/ideas in case of.

Re: match "tls" option implementation

[gilles]

July 9, 2024 4:16 PM, "Tassilo Philipp"  wrote:

>>> Would it be enough to introduce a new flag in enum envelope_flags, >> and 
>>> set it when the session
>>> flag SF_SECURE is set, e.g. in smtp_tx()? >> E.g. some addition like (given 
>>> EF_TLS would be the new
>>> envelope >> flag):
>>> 
>>> if (s->flags & SF_SECURE)
>>> tx->evp.flags |= EF_TLS;
>>> 
>>> I would be open to work on a patch, or do I risk opening a can of >> worms, 
>>> b/c there is something
>>> I don't foresee?
>> 
>> You won't be opening a can of worms, no, but this diff is not enough:
>> 
>> What we want is to record not only that there was TLS but also what > TLS 
>> version and ciphers were
>> used, so just a binary flag isn't enough.
> 
> Mh... sounds like a good idea, however, smtpd.conf(5) itself would still just 
> be a binary option,
> no?
> 

nope, it could be a binary option to match the fact that tls was specified, or 
it could be an option
with suboptions (tls cipher ..., tls version ...) to match a more specific 
criteria.

if you implement the more general feature, you still want to put the data for 
the more specific ones
in the envelope to avoid having to many envelope format changes for foreseen 
features.


>> Furthermore, since this will require adding one or two fields to > 
>> envelopes, there will be a bump
>> in envelope version and _possibly_ a > flag day unless old envelopes missing 
>> fields can be updated
>>> transparently by a new smtpd expecting the field.
> 
> I might not follow... what would be the flag "day"?
> I can look at it, but...
> 

it means that we have to tell everyone "sorry, the new envelopes are 
incompatible, you need to empty
the queue and reload smtpd", it's painful for users so you really want to avoid 
it at all cost. It's
not always avoidable, so if you HAVE to provoke one, we want to make sure it 
contains all changes we
will need for upcoming features too.


>> Back then we had just released the new action-based envelopes so I > didn't 
>> want to impose another
>> flag day on users so soon after, it's > been years now so it's acceptable if 
>> needed. If needed, we
>> need to > check if other features might need to ride it so we can unlock > 
>> multiple features at
>> once even if we just provision the envelope but > don't expose the features 
>> yet.
> 
> ... I think I have to study the code a bit more thoroughly, first, and do 
> play around with it, to
> not miss anything. This might take a little bit longer, life's unfortunately 
> not that easy, lately.
> :-/
> 

no rush



>> I'd suggest you move forward with your diff, including envelope > changes, 
>> and we can discuss with
>> the full diff.
> 
> Sounds good! Will try to make it happen!
> 
> Thanks for the helpful feedback, glad I asked, first :)

Re: match "tls" option implementation

[Tassilo Philipp]

On Tue, Jul 09, 2024 at 01:59:02PM +, gil...@poolp.org wrote:

July 9, 2024 2:32 PM, "Tassilo Philipp"  wrote:


Hello ML,

I tried to make use of the "tls" option of match rules, and got 
confused that whenever that option is specified, the server tries to 
expand the "RCPT TO", address, no matter what action is specified. 
This results in a 451 Tempfail, when it cannot expand that address.


Unsure I understand, it might help to share some config.


Sorry, in hindsight, I confused myself. The logged error is:
451 Tempfail: 

In the verbose log, it quits on the expansion step, so I thought it 
tries to expand that address (but on the server there is no such user).


In the end, ruleset_match() just returns a tempfail, hard, in that case, 
so the log is simply confusing.



Would it be enough to introduce a new flag in enum envelope_flags, 
and set it when the session flag SF_SECURE is set, e.g. in smtp_tx()? 
E.g. some addition like (given EF_TLS would be the new envelope 
flag):


if (s->flags & SF_SECURE)
tx->evp.flags |= EF_TLS;

I would be open to work on a patch, or do I risk opening a can of 
worms, b/c there is something I don't foresee?




You won't be opening a can of worms, no, but this diff is not enough:

What we want is to record not only that there was TLS but also what 
TLS version and ciphers were used, so just a binary flag isn't enough.


Mh... sounds like a good idea, however, smtpd.conf(5) itself would still 
just be a binary option, no?



Furthermore, since this will require adding one or two fields to 
envelopes, there will be a bump in envelope version and _possibly_ a 
flag day unless old envelopes missing fields can be updated 
transparently by a new smtpd expecting the field.


I might not follow... what would be the flag "day"?
I can look at it, but...


Back then we had just released the new action-based envelopes so I 
didn't want to impose another flag day on users so soon after, it's 
been years now so it's acceptable if needed. If needed, we need to 
check if other features might need to ride it so we can unlock 
multiple features at once even if we just provision the envelope but 
don't expose the features yet.


.. I think I have to study the code a bit more thoroughly, first, and 
do play around with it, to not miss anything. This might take a little 
bit longer, life's unfortunately not that easy, lately. :-/



I'd suggest you move forward with your diff, including envelope 
changes, and we can discuss with the full diff.


Sounds good! Will try to make it happen!

Thanks for the helpful feedback, glad I asked, first :)

Re: match "tls" option implementation

[gilles]

July 9, 2024 2:32 PM, "Tassilo Philipp"  wrote:

> Hello ML,
> 
> I tried to make use of the "tls" option of match rules, and got confused that 
> whenever that option
> is specified, the server tries to expand the "RCPT TO", address, no matter 
> what action is
> specified. This results in a 451 Tempfail, when it cannot expand that address.
> 

Unsure I understand, it might help to share some config.


> Puzzled by this I looked into the code, and came across this implementation 
> in ruleset.c:
> 
> static int
> ruleset_match_smtp_starttls(struct rule *r, const struct envelope *evp)
> {
> if (!r->flag_smtp_starttls)
> return 1;
> 
> /* XXX - not until TLS flag is added to envelope */
> return -1;
> }
> 
> The retval of -1 will always trigger a tempfail in ruleset_match().
> 
> So basically it's simply not implemented, so far so good. The fact that it's 
> documented in the man
> page, makes me wonder if there was anything more complex that blocked the 
> implementation?
> 

No, not really complex, it just was a bad timing when I wrote this code.


> Would it be enough to introduce a new flag in enum envelope_flags, and set it 
> when the session flag
> SF_SECURE is set, e.g. in smtp_tx()? E.g. some addition like (given EF_TLS 
> would be the new
> envelope flag):
> 
> if (s->flags & SF_SECURE)
> tx->evp.flags |= EF_TLS;
> 
> I would be open to work on a patch, or do I risk opening a can of worms, b/c 
> there is something I
> don't foresee?
> 

You won't be opening a can of worms, no, but this diff is not enough:

What we want is to record not only that there was TLS but also what TLS version 
and ciphers were
used, so just a binary flag isn't enough.

Furthermore, since this will require adding one or two fields to envelopes, 
there will be a bump
in envelope version and _possibly_ a flag day unless old envelopes missing 
fields can be updated
transparently by a new smtpd expecting the field.

Back then we had just released the new action-based envelopes so I didn't want 
to impose another
flag day on users so soon after, it's been years now so it's acceptable if 
needed. If needed, we
need to check if other features might need to ride it so we can unlock multiple 
features at once
even if we just provision the envelope but don't expose the features yet.

I'd suggest you move forward with your diff, including envelope changes, and we 
can discuss with
the full diff.


> Thanks!
> 
> PS: my use case, just in case: in some company intranet we try to get every 
> machine to mail via
> TLS, either implicit or via STARTTLS. However, some crappy UPS have severely 
> outdated crypto stacks
> and there are no more firmware updates. Given that their status mails aren't 
> security issues, I
> wanted to basically whitelist those few devices, explicitly, so a "!tls" 
> would have come in handy
> (only other option I see is to provide a dedicated port, or making starttls 
> optional for any
> client).

Re: io-error: write failed: Connection reset by peer" from outbound.protection.outlook.com

[oreo]

Turned out that, the error

Jun 17 10:20:42 smtp01 smtpd[7838]: 33c0e6f7addb24d1 smtp disconnected 
reason="io-error: write failed: Connection reset by peer"

is harmless (in my case) and mail is received successfully.

But by investigating it discovered another problem.

On my server I have both rdns and fcrdns filers enabled

filter   "rdns" phase connect match   !rdns disconnect "550 rDNS error"
filter "fcrdns" phase connect match !fcrdns disconnect "550 fcrDNS error"

and  I noticed  a lot of (and similar)

Jul  1 08:56:15 smtp01 smtpd[7838]: 33c297056fc0b7f5 smtp connected 
address=40.107.149.96 
host=mail-germanywestcentralazon11022096.outbound.protection.outlook.
Jul  1 08:56:15 smtp01 smtpd[7838]: 33c297056fc0b7f5 smtp failed-command 
command="" result="550 fcrDNS error"

hostname longer than 64 chars 
(mail-germanywestcentralazon11022096.outbound.protection.outlook.com),
is truncated  (mail-germanywestcentralazon11022096.outbound.protection.outlook.)
and fcrdns filter failed.

There is an issue on github regarding this 


https://github.com/OpenSMTPD/OpenSMTPD/issues/1252

In my case I applied patch

https://github.com/morille/OpenSMTPD/commit/b9a09d61614f84e6dc9d43bd91952d85c4530d48
 


which resolved the problem with long hostnames.

Just sharing this info, in case somebody else stumble on this problem too.

--
Saulius

On Monday, July 1st, 2024 at 14:54, Marcus MERIGHI  
wrote:

> 

> 

> Hello Saulius,
> 

> o...@s12s.slmail.me (o...@s12s.slmail.me), 2024.07.01 (Mon) 10:09 (CEST):
> 

> > And recently I'm started getting such errors for e-mails coming from
> > outbound.protection.outlook.com servers.
> > 

> > Jun 17 10:20:42 smtp01 smtpd[7838]: 33c0e6f7addb24d1 smtp disconnected
> > reason="io-error: write failed: Connection reset by peer"
> > 

> > Is my understanding correct that "Connection reset by peer" means that
> > remote host (outlook.com) closed/reset the connection?
> 

> 

> I think that is what it means. And it reminds me of a recent thread on
> mai...@mailop.org (the list archive is private*). The gist, as stated:
> 

> 
> Date: Sat, 29 Jun 2024 10:31:06 +1000
> From: Viktor Dukhovni via mailop mai...@mailop.org
> 

> To: mai...@mailop.org
> 

> [...]
> Reading your first post brought to mind the recent report of potential
> issues at Microsoft's outbound servers with "too many" TLSA records
> (more than ~12). I was looking at your TLSA RRset (14 TLSA records):
> [...]
> That said, do you really need all 14 records?
> 
> 

> The OP replied with:
> 
> Date: Fri, 28 Jun 2024 23:23:04 -0400
> From: "Jim P. via mailop" mai...@mailop.org
> 

> To: mai...@mailop.org
> 

> [...]
> Thank you for the detailed breakdown of the problem and resolution. I
> have removed the E* TLSA records and mails from Microsoft are flowing
> in. I'll make a note to remove the R3/R4 records next week and then
> plan for adding the E* TLSA records back in and switching to ECDSA in
> the near future.
> Thanks again Viktor, you've been an awesome help.
> 
> 

> Is this something you should take a look at?
> 

> Marcus
> 

> * https://list.mailop.org/listinfo/mailop

signature.asc
Description: OpenPGP digital signature

Re: io-error: write failed: Connection reset by peer" from outbound.protection.outlook.com

[Marcus MERIGHI]

Hello Saulius, 

o...@s12s.slmail.me (o...@s12s.slmail.me), 2024.07.01 (Mon) 10:09 (CEST):
> And recently I'm started getting such errors for e-mails coming from
> outbound.protection.outlook.com servers.
>
> Jun 17 10:20:42 smtp01 smtpd[7838]: 33c0e6f7addb24d1 smtp disconnected
> reason="io-error: write failed: Connection reset by peer"
>
> Is my understanding correct that "Connection reset by peer" means that
> remote host (outlook.com) closed/reset the connection?

I think that is what it means. And it reminds me of a recent thread on
mai...@mailop.org (the list archive is private*). The gist, as stated:


Date: Sat, 29 Jun 2024 10:31:06 +1000
From: Viktor Dukhovni via mailop 
To: mai...@mailop.org

[...]
Reading your first post brought to mind the recent report of potential
issues at Microsoft's outbound servers with "too many" TLSA records
(more than ~12).  I was looking at your TLSA RRset (14 TLSA records):
[...]
That said, do you really need all 14 records?


The OP replied with:

Date: Fri, 28 Jun 2024 23:23:04 -0400
From: "Jim P. via mailop" 
To: mai...@mailop.org

[...]
Thank you for the detailed breakdown of the problem and resolution.  I
have removed the E* TLSA records and mails from Microsoft are flowing
in.  I'll make a note to remove the R3/R4 records next week and then
plan for adding the E* TLSA records back in and switching to ECDSA in
the near future.
Thanks again Viktor, you've been an awesome help.


Is this something you should take a look at?

Marcus

* https://list.mailop.org/listinfo/mailop

Re: Too many open files from fiter leads to smtpd death

[Kirill A . Korinsky]

On Mon, 17 Jun 2024 23:56:34 +0100,
gil...@poolp.org wrote:
> 
> June 16, 2024 2:12 PM, "Kirill A. Korinsky"  wrote:
> 
> In your specific case, you had a descriptor leak and a deadlock... what would
> be the best option for OpenSMTPD to cope with these ? your filter isn't going
> to end up closing descriptors so you're already toast no matter what we do...
> as for the deadlock, we could try to detect it, but we're already going to be
> hitting the session timeout and the filter will still be in a broken state by
> the next time we enter it.
> 
> The only improvement I see here is that if we could detect deadlock early, we
> could kill smtpd right away.

I spent some time to think about it, and I feel that killing smtpd is the
right move.

As you points before it dies when filter misbehave, and not reply for a
while, let say for 15 minutes, it defently misbehaving.

From another hand, such timeout should be large enough and announced to
filter, because the filter may do DNS requests and it can be quite slow.

-- 
wbr, Kirill

Re: Too many open files from fiter leads to smtpd death

[gilles]

June 16, 2024 2:12 PM, "Kirill A. Korinsky"  wrote:

> On Fri, 14 Jun 2024 01:53:48 +0100,
> Kirill A. Korinsky  wrote:
> 
>> Thus, I thought that I made something wrong and tried getrrsetbyname_async
>> without any success.
> 
> Indeed I did: run asr_abort without decreasign counters which leads to
> deadlock. Thus, asr debug log was useless due to missed debug output inside
> asr_abort [1].
> 
> Anyway, I still not sure that it is correct behaviour that filter may block
> processing of email indenfently.
> 

I think you are wrong in how you think of the issue: it is indeed not correct
behavior for a filter to block the processing of mail, so... maybe the filter
should just not do it to begin with ? :-)

Unlike MDA which are executed at delivery time and can retry, filters are not
graceful, they can't be retried, they affect directly the SMTP engine, so the
contract we have for the API is: do not misbehave.

In your specific case, you had a descriptor leak and a deadlock... what would
be the best option for OpenSMTPD to cope with these ? your filter isn't going
to end up closing descriptors so you're already toast no matter what we do...
as for the deadlock, we could try to detect it, but we're already going to be
hitting the session timeout and the filter will still be in a broken state by
the next time we enter it.

The only improvement I see here is that if we could detect deadlock early, we
could kill smtpd right away.

Re: Too many open files from fiter leads to smtpd death

[Kirill A . Korinsky]

On Fri, 14 Jun 2024 01:53:48 +0100,
Kirill A. Korinsky  wrote:
> 
> Thus, I thought that I made something wrong and tried getrrsetbyname_async
> without any success.
> 

Indeed I did: run asr_abort without decreasign counters which leads to
deadlock. Thus, asr debug log was useless due to missed debug output inside
asr_abort [1].

Anyway, I still not sure that it is correct behaviour that filter may block
processing of email indenfently.


Footnotes:
[1]  https://marc.info/?l=openbsd-misc=171853989911463=2

-- 
wbr, Kirill

Re: Network error on destination MXs on MX that starts with "_"

[Kirill A . Korinsky]

Hi Jesper,

On Tue, 11 Jun 2024 14:10:11 +0100,
Jesper Wallin  wrote:
> 
> This is indeed an invalid hostname.  A hostname must begin with a digit
> or letter. (https://www.rfc-editor.org/rfc/rfc1123#page-13)
>

You are wrong. For example, SRV records (RFC 2782) are widely used and have
the format _service._proto.name.

Next, I checked RFC 5321 section 5.1 and it uses the following wording:

   When a domain name associated with an MX RR is looked up and the
   associated data field obtained, the data field of that response MUST
   contain a domain name.  That domain name, when queried, MUST return
   at least one address record (e.g., A or  RR) that gives the IP
   address of the SMTP server to which the message should be directed.
   Any other response, specifically including a value that will return a
   CNAME record when queried, lies outside the scope of this Standard.
   The prohibition on labels in the data that resolve to CNAMEs is
   discussed in more detail in RFC 2181, Section 10.3 [38].

As you can see, it explicitly uses the domain name, not the hostname.

This means that the MX record is a domain name, and it can start with an
underscore.

-- 
wbr, Kirill

Re: Too many open files from fiter leads to smtpd death

[Kirill A . Korinsky]

On Tue, 11 Jun 2024 23:10:07 +0100,
Kirill A. Korinsky  wrote:
>
> Leak of descriptors is good point. On the same servers I had
> https://www.mail-archive.com/misc@opensmtpd.org/msg06241.html a while ago
> with the same filters which envolved since then a bit, but logic the same.
>
> And for a few hours it had leaked a few descriptiors which I see via fstat,
> so it probably is.
>
> Also, I run two MXs and both of them fails the same way almost the same
> moment, about 5 minutes between them.
>
> I register session / message related things like this:
>
>   osmtpd_local_session(auth_session_new, auth_session_free);
>   osmtpd_local_message(auth_message_new, auth_message_free);
>
> and I made an assumtion that both free method are called when I call:
>
> osmtpd_filter_disconnect(ctx, "Internal server error");
>
> am I right with that assumtion?
>

and I figured it out. Yes, both issues had the same root cause.

My filter runs a few DNS quereis to walk against SPF and get certificates
for DKIM and ARC signatures.

The last one is called by the code:

if ((query = res_query_async(sig->domain, C_IN, T_TXT, NULL)) == NULL)
osmtpd_err(1, "res_query_async");
if ((sig->query = event_asr_run(query, ar_rr_resolve, sig)) == NULL)
osmtpd_err(1, "event_asr_run");

and in may plan to execute more than one request for the same domain.

After a lot of hours of debuging I've added inside lookup function and
ar_rr_resolve log to print domain and address of sig object.

Well, it had proved that ar_rr_resolve not always call.

Huh.

tcpdump says that local DNS server replies, but the function never called.

The logic of filter is based on assumption that it will be called.

So, no call, it waits forever.

Really forewer.

Now wired things: seems some servers (at least Postfix at mail.nginx.org,
probably not only this) keeps connection... forever.

So, at some point all sockets are consumed by waited connections, and here
I had missbehaviour of filter on error (fixed) which lead to exit of smtpd.

Before I had implemented ARC signatures it uses DNS less and it may work
longer, that allows to achive: Disabling incoming SMTP connections: Client
limit reached.

Probably, after fixing a filter I also may achive that, but much faster.

Anyway, here the question: how should I run DNS queries? I've checked smtpd
code and seems that it is built on the same assumption that ar_rr_resolve
should be called.

Thus, I thought that I made something wrong and tried getrrsetbyname_async
without any success.

--
wbr, Kirill

Re: developers: unofficial OpenSMTD-framework

[Igor Zornik]

Hello,

> Could the context replace the custom session data structures ?

You mean `filter.SessionData`? Indeed, but I recommend to use a concrete 
type to make the API more clear and to avoid all those nasty type 
assertions (slightly off-topic, in newer versions of Go, empty 
interfaces should be `any`, not `interface{}`).


For instance, if you want to pass some sender data, you can use the 
following idiom:


// Not exported custom type to avoid context map key collision.
type key int
var sessionSenderKey key = 1

// Type available in the context.
type SessionSender struct {
Name string
Address string
}

// Set the value.
func NewSessionSenderContext(ctx context.Context,
s SessionSender) context.Context {
return context.WithValue(ctx, sessionSenderKey, s)
}

// Consumers retrieve the value with this.
func FromSessionSenderContext(ctx context.Context)
(SessionSender, bool) {
s, ok := ctx.Value(sessionSenderKey).(SessionSender)
if !ok {
return SessionSender{}, ok
}

return s, ok
}

// This is not necessary, but if the value is always expected, it makes 
// retrieving it a lot easier because you avoid the whole "if value, ok" 
// idiom.

func MustFromSessionSenderContext(ctx context.Context) SessionSender {
s, ok := FromSessionSenderContext(ctx)
if !ok {
panic(`key does not exist`)
}

return s
}

With the above pattern you can invent any other necessary data structure 
that should pass between service calls.


Here's how to set and pass it:

s := SessionSender{Name: `Foo`, Address: `f...@bar.org`}
ctx := context.Background()
ctx = NewSessionSenderContext(ctx, s)

// Noticed I removed `Session` from function signature to make it more 
// simple? Instead you can include that in another context or just pass 
// it as a regular string if the session ID is essential in every call.

dir.linkGreeting(ctx, timestamp, atoms[0])

Now the consumers can get the value if they are interested in it.

func linkGreetingCb(ctx context.Context, timestamp time.Time,
hostname string) {
fmt.Fprintf(os.Stderr, "%s: %v: link-greeting: %s\n", timestamp,
filter.MustFromSessionSenderContext(ctx), hostname)
}

And that's how passing values between calls goes.

With regard,

On 6/12/24 12:37, gil...@poolp.org wrote:
> June 12, 2024 11:05 AM, "Igor Zornik"  wrote:
>
>> Hello,
>>
>> Would it make sense to include context as the first parameter in 
each API call? That's how Go
>> usually handles service calls. Then you may use it to pass any 
arbitrary values or perform

>> operation cancellations.
>>
>> With regards
>>
>
> That's an interesting question.
>
> Could the context replace the custom session data structures ?
>
> I need to look into it, thanks for pointing it.

Re: Too many open files from fiter leads to smtpd death

[Kirill A . Korinsky]

On Tue, 11 Jun 2024 23:10:07 +0100,
Kirill A. Korinsky  wrote:
> 
> I register session / message related things like this:
> 
>   osmtpd_local_session(auth_session_new, auth_session_free);
>   osmtpd_local_message(auth_message_new, auth_message_free);
> 
> and I made an assumtion that both free method are called when I call:
> 
> osmtpd_filter_disconnect(ctx, "Internal server error");
> 
> am I right with that assumtion?
> 

Seems that I was wrong. Or at least it hasn't happened each connection.

It defently may missbehave on error, and to avoid complexity of code I
migrated filter to osmtpd_err/osmtpd_errx in case of error which exists a
filter if syscall returns something unexcpected.

Also, I've added trace log each time when auth_{message,session}_{new,free}
is called, as first statment of the function.

And for the last night I had 14 leaked files. All of them had happened from
incomming connections from mail.nginx.org, and usuall log associeted with
connection looks like:

mx1$ grep 78ba6f2a7dceb938 /var/log/maillog 
   
Jun 13 05:55:11 mx1 smtpd[97991]: 78ba6f2a7dceb938 smtp connected 
address=206.251.255.65 host=mail.nginx.com
Jun 13 05:55:11 mx1 smtpd[84725]: auth: 78ba6f2a7dceb938 session_new
Jun 13 05:55:13 mx1 smtpd[97991]: 78ba6f2a7dceb938 smtp tls 
ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
Jun 13 05:55:14 mx1 smtpd[84725]: auth: 78ba6f2a7dceb938 message_new
mx1$ 

No dissconnect, no call auth_{message,session}_free, nothing.

-- 
wbr, Kirill

Re: developers: unofficial OpenSMTD-framework

[gilles]

June 12, 2024 11:05 AM, "Igor Zornik"  wrote:

> Hello,
> 
> Would it make sense to include context as the first parameter in each API 
> call? That's how Go
> usually handles service calls. Then you may use it to pass any arbitrary 
> values or perform
> operation cancellations.
> 
> With regards
> 

That's an interesting question.

Could the context replace the custom session data structures ?

I need to look into it, thanks for pointing it.

Re: developers: unofficial OpenSMTD-framework

[Igor Zornik]

Hello,

Would it make sense to include context as the first parameter in each 
API call? That's how Go usually handles service calls. Then you may use 
it to pass any arbitrary values or perform operation cancellations.


With regards

On 6/10/24 01:22, gil...@poolp.org wrote:

Helo again,

I have worked on a package called the OpenSMTPD-framework for developing Golang 
filters,
it is an unofficial project that's only supported by me, don't bug OpenBSD with 
bugs :-)

It is available at:

 https://github.com/poolpOrg/OpenSMTPD-framework


It can currently be used to develop table backends and filters.

It contains an example table and an example filter but I have already 
implemented a filter-kicker
which took me about thirty minutes to get running and which you can find here:

 https://github.com/poolpOrg/filter-kicker


I will likely convert the popular filter-rspamd and filter-senderscore to this 
framework soon, so
it is easier for me to maintain them all.

Feel free to test, contribute and let me know if you use it as I'm still at a 
point where I might
break things to ease the API.

Cheers,

Re: Too many open files from fiter leads to smtpd death

[Kirill A . Korinsky]

On Tue, 11 Jun 2024 19:23:27 +0100,
gil...@poolp.org wrote:
>
> I'm unsure what the filter really did and it is a bit harsh to read,
> but the rules are as follow:
>

Here I anounced it: 
https://www.mail-archive.com/misc@opensmtpd.org/msg06292.html

> I may be wrong about your bug but with just a quick glance I saw mem leaks
> and the error message you have seems to imply a leak of descriptor as well
> so I'd be tempted to assume that the filter is misbehaving and that it did
> not report the fd exhaustion properly to smtpd leading to termination.

Leak of descriptors is good point. On the same servers I had
https://www.mail-archive.com/misc@opensmtpd.org/msg06241.html a while ago
with the same filters which envolved since then a bit, but logic the same.

And for a few hours it had leaked a few descriptiors which I see via fstat,
so it probably is.

Also, I run two MXs and both of them fails the same way almost the same
moment, about 5 minutes between them.

I register session / message related things like this:

osmtpd_local_session(auth_session_new, auth_session_free);
osmtpd_local_message(auth_message_new, auth_message_free);

and I made an assumtion that both free method are called when I call:

osmtpd_filter_disconnect(ctx, "Internal server error");

am I right with that assumtion?

--
wbr, Kirill

Re: Too many open files from fiter leads to smtpd death

[gilles]

June 11, 2024 6:38 PM, "Kirill A. Korinsky"  wrote:

> misc@,
> 
> I just discovered that smtpd dies becuase of filter hit "too many open
> files".
> 
> Last logs from smtpd:
> 
> Jun 11 13:06:03 mx1 smtpd[80363]: 1825a196e20867b3 mta disconnected 
> reason=quit messages=1
> Jun 11 13:07:06 mx1 smtpd[80363]: 1825a197ad6634d4 smtp connected 
> address=198.2.134.32
> host=mail134-32.atl141.mandrillapp.com
> Jun 11 13:07:08 mx1 smtpd[80363]: 1825a197ad6634d4 smtp tls
> ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
> Jun 11 13:07:08 mx1 smtpd[82182]: auth: 1825a197ad6634d4 Can't open tempfile: 
> Too many open files
> Jun 11 13:07:08 mx1 smtpd[80363]: dispatcher: tree_xpop(0xfae2ce35960, 
> 0x1825a197ad6634d4)
> Jun 11 13:07:08 mx1 smtpd[61396]: smtpd: process dispatcher socket closed
> 
> [...]
> 
> I expect that it clsoes connection, but not kills smtpd.
> 
> Am I wrong?
> 

I'm unsure what the filter really did and it is a bit harsh to read,
but the rules are as follow:

1- filters are allowed to fail as long as they do so properly
2- filters are not allowed to misbehave

If Too many open files is handled properly, you fall into 1- and it should
translate to a session close.

If it's not handled properly and smtpd detects any problem with the filter
then it'll abort because it won't run with a buggy filter.

I may be wrong about your bug but with just a quick glance I saw mem leaks
and the error message you have seems to imply a leak of descriptor as well
so I'd be tempted to assume that the filter is misbehaving and that it did
not report the fd exhaustion properly to smtpd leading to termination.

How I'd go about debugging that:

- figuring out why smtpd detects misbehaviour, maybe with tracing filters,
  in my experience its often a print of an error message on the wrong fd.

- when this is understood, tracking the leak and fixing it.

Cheers,
Gilles

Re: Network error on destination MXs on MX that starts with "_"

[Jesper Wallin]

Hi Giovanni,

This is indeed an invalid hostname.  A hostname must begin with a digit 
or letter. (https://www.rfc-editor.org/rfc/rfc1123#page-13)



Jesper Wallin

On 6/11/24 2:57 PM, Giovanni Bechis wrote:

Hi,
recently I've found this error on my server:
Jun 11 10:46:33 mx smtpd[97386]:  mta delivery 
evpid=aa1ddab63539175b from= to= 
rcpt=<-> source="-" relay="example.com" delay=22h31m25s 
result="TempFail" stat="Network error on destination MXs"


The destination domain MX record is:
_dc-mx.140697ab0ac1.example.com which I am not sure is valid but it's 
present on the wild.

Is it correct that OpenSMTPD fails to deliver in this case ?
OpenSMTPD version is 7.5.0 running on OpenBSD 7.5.

  Cheers
   Giovanni

Re: OpenSmtpd + Dovecot failed

[Omar Polo]

On 2024/06/10 18:02:51 +0200, Omar Polo  wrote:
> On 2024/06/10 07:28:37 -0700, latin...@vcn.bc.ca wrote:
> > > Well, the cause is that table-passwd dies (since it's the only proc
> > > table you use.)  Did you do anything to that host recently?  Was it
> > > just installed?  Something had to happen for it to fail.
> > >
> > > Unfortunately at the moment I can't try out on a fresh 7.5 install.
> > >
> > 
> > That is a testing VM, i can do whatever you tell me!
> > 
> > I did:
> > 
> > i installed 7.5, then i tested znc; znc did not installed the adminweb
> > module; irssi said that it has been installed; then i did a reinstallation
> > to test znc on 7.4; znc had the exact same behaviour that at 7.5! At that
> > moment i had znc, OpenSmtp, Dovecot; all the pkg_info list.
> > 
> > At that mpment everything was working correctly. Syspatch lost 2 patches,
> > i saw it yesterday when smtpd failed, that is all.
> > 
> > There is not syspatch.log and just 001 and 003 patches were installed!
> > 
> > Partitions are only a and b.
> > 
> > Please tell me what must i test.
> 
> I managed to test in a thrown-away vm with OpenBSD 7.5.  I first set it
> up, confirmed it was working, sysupgraded (patches 1 and 3), and verified
> it was still working.
> 
> What you can try testing is to:
> 
>  1. verify the syntax of the passwd file.  Start with just one entry and see
> if it works.  For reference, here's the one I've used in my vm
> 
> op:$2b$09$ts7CQdymgQeR8FrVzrY8zuVMrkqL0YI1m3yH0PowCrq1x46l.FcUO:1000:1000:Omar
> Polo:/home/op:/bin/ksh

Ops, this line got splitted when I pasted in my editor.  It's obviously
just one line:

op:$2b$09$ts7CQdymgQeR8FrVzrY8zuVMrkqL0YI1m3yH0PowCrq1x46l.FcUO:1000:1000:Omar 
Polo:/home/op:/bin/ksh

> the password is "123" (without quotes) hashed with `smtpctl encrypt 123'
> 
>  2. make sure the packages are up-do-date.  This is crucially important if
> you've updated from 7.4 to 7.5.
> 
>  3. run smtpd as `smtpd -dvvv -Tall' and attach what it prints 

Re: OpenSmtpd + Dovecot failed

[Omar Polo]

On 2024/06/10 07:28:37 -0700, latin...@vcn.bc.ca wrote:
> > Well, the cause is that table-passwd dies (since it's the only proc
> > table you use.)  Did you do anything to that host recently?  Was it
> > just installed?  Something had to happen for it to fail.
> >
> > Unfortunately at the moment I can't try out on a fresh 7.5 install.
> >
> 
> That is a testing VM, i can do whatever you tell me!
> 
> I did:
> 
> i installed 7.5, then i tested znc; znc did not installed the adminweb
> module; irssi said that it has been installed; then i did a reinstallation
> to test znc on 7.4; znc had the exact same behaviour that at 7.5! At that
> moment i had znc, OpenSmtp, Dovecot; all the pkg_info list.
> 
> At that mpment everything was working correctly. Syspatch lost 2 patches,
> i saw it yesterday when smtpd failed, that is all.
> 
> There is not syspatch.log and just 001 and 003 patches were installed!
> 
> Partitions are only a and b.
> 
> Please tell me what must i test.

I managed to test in a thrown-away vm with OpenBSD 7.5.  I first set it
up, confirmed it was working, sysupgraded (patches 1 and 3), and verified
it was still working.

What you can try testing is to:

 1. verify the syntax of the passwd file.  Start with just one entry and see
if it works.  For reference, here's the one I've used in my vm

op:$2b$09$ts7CQdymgQeR8FrVzrY8zuVMrkqL0YI1m3yH0PowCrq1x46l.FcUO:1000:1000:Omar
Polo:/home/op:/bin/ksh

the password is "123" (without quotes) hashed with `smtpctl encrypt 123'

 2. make sure the packages are up-do-date.  This is crucially important if
you've updated from 7.4 to 7.5.

 3. run smtpd as `smtpd -dvvv -Tall' and attach what it prints 

Re: OpenSmtpd + Dovecot failed

[latincom]

> On 2024/06/10 03:22:54 -0700, latin...@vcn.bc.ca wrote:
>> > On 2024/06/10 02:25:26 -0700, latin...@vcn.bc.ca wrote:
>> >> > On 2024/06/09 20:53:53 -0700, latin...@vcn.bc.ca wrote:
>> >> >> Hello
>> >> >>
>> >> >> I am having this log lines and i am not able to find the error,
>> could
>> >> >> someone help please?:
>> >> >> Jun  9 19:57:24 hawk smtpd[37247]: info: OpenSMTPD 7.5.0 starting
>> >> >> Jun  9 19:57:24 hawk smtpd[97671]: warn: table-proc: pipe closed
>> >> >> Jun  9 19:57:24 hawk smtpd[97671]: lookup: table-proc: exiting
>> >> >
>> >> > smtpd dies because of this: an external table died.
>> >> >
>> >> >> [...]
>> >> >> # tables setup
>> >> >> table domains file:/etc/mail/domains
>> >> >> table passwd passwd:/etc/mail/passwd
>>
>> No, because i am not using current!
>> >> OpenBSD 7.5 (GENERIC) #79: Wed Mar 20 15:33:49 MDT 2024
>
> Ops, sorry, I misread the previous mail.
>
> Well, the cause is that table-passwd dies (since it's the only proc
> table you use.)  Did you do anything to that host recently?  Was it
> just installed?  Something had to happen for it to fail.
>
> Unfortunately at the moment I can't try out on a fresh 7.5 install.
>

That is a testing VM, i can do whatever you tell me!

I did:

i installed 7.5, then i tested znc; znc did not installed the adminweb
module; irssi said that it has been installed; then i did a reinstallation
to test znc on 7.4; znc had the exact same behaviour that at 7.5! At that
moment i had znc, OpenSmtp, Dovecot; all the pkg_info list.

At that mpment everything was working correctly. Syspatch lost 2 patches,
i saw it yesterday when smtpd failed, that is all.

There is not syspatch.log and just 001 and 003 patches were installed!

Partitions are only a and b.

Please tell me what must i test.

Re: OpenSmtpd + Dovecot failed

[Omar Polo]

On 2024/06/10 03:22:54 -0700, latin...@vcn.bc.ca wrote:
> > On 2024/06/10 02:25:26 -0700, latin...@vcn.bc.ca wrote:
> >> > On 2024/06/09 20:53:53 -0700, latin...@vcn.bc.ca wrote:
> >> >> Hello
> >> >>
> >> >> I am having this log lines and i am not able to find the error, could
> >> >> someone help please?:
> >> >> Jun  9 19:57:24 hawk smtpd[37247]: info: OpenSMTPD 7.5.0 starting
> >> >> Jun  9 19:57:24 hawk smtpd[97671]: warn: table-proc: pipe closed
> >> >> Jun  9 19:57:24 hawk smtpd[97671]: lookup: table-proc: exiting
> >> >
> >> > smtpd dies because of this: an external table died.
> >> >
> >> >> [...]
> >> >> # tables setup
> >> >> table domains file:/etc/mail/domains
> >> >> table passwd passwd:/etc/mail/passwd
> 
> No, because i am not using current!
> >> OpenBSD 7.5 (GENERIC) #79: Wed Mar 20 15:33:49 MDT 2024

Ops, sorry, I misread the previous mail.

Well, the cause is that table-passwd dies (since it's the only proc
table you use.)  Did you do anything to that host recently?  Was it
just installed?  Something had to happen for it to fail.

Unfortunately at the moment I can't try out on a fresh 7.5 install.

Re: OpenSmtpd + Dovecot failed

[latincom]

> On 2024/06/10 02:25:26 -0700, latin...@vcn.bc.ca wrote:
>> > On 2024/06/09 20:53:53 -0700, latin...@vcn.bc.ca wrote:
>> >> Hello
>> >>
>> >> I am having this log lines and i am not able to find the error, could
>> >> someone help please?:
>> >> Jun  9 19:57:24 hawk smtpd[37247]: info: OpenSMTPD 7.5.0 starting
>> >> Jun  9 19:57:24 hawk smtpd[97671]: warn: table-proc: pipe closed
>> >> Jun  9 19:57:24 hawk smtpd[97671]: lookup: table-proc: exiting
>> >
>> > smtpd dies because of this: an external table died.
>> >
>> >> [...]
>> >> # tables setup
>> >> table domains file:/etc/mail/domains
>> >> table passwd passwd:/etc/mail/passwd

No, because i am not using current!
>> OpenBSD 7.5 (GENERIC) #79: Wed Mar 20 15:33:49 MDT 2024

Re: OpenSmtpd + Dovecot failed

[Omar Polo]

On 2024/06/10 02:25:26 -0700, latin...@vcn.bc.ca wrote:
> > On 2024/06/09 20:53:53 -0700, latin...@vcn.bc.ca wrote:
> >> Hello
> >>
> >> I am having this log lines and i am not able to find the error, could
> >> someone help please?:
> >> Jun  9 19:57:24 hawk smtpd[37247]: info: OpenSMTPD 7.5.0 starting
> >> Jun  9 19:57:24 hawk smtpd[97671]: warn: table-proc: pipe closed
> >> Jun  9 19:57:24 hawk smtpd[97671]: lookup: table-proc: exiting
> >
> > smtpd dies because of this: an external table died.
> >
> >> [...]
> >> # tables setup
> >> table domains file:/etc/mail/domains
> >> table passwd passwd:/etc/mail/passwd
> >
> > I guess it's table passwd.
> 
> yes, i changed passwd: to file: and smtpd started but is nor reachable
> from outside. the patches 1 and 3 are not installed!
> opensmtpd-extras-6.7.1p0v0 deleted.

Sorry, maybe I explained myself poorly.  You don't need to change the
table type, this should remain `table passwd passwd:/etc/mail/passwd`,

Rather, you should just replace a package.

> OpenBSD 7.5 (GENERIC) #79: Wed Mar 20 15:33:49 MDT 2024
> # pkg_info
> [...]
> opensmtpd-extras-6.7.1p0v0 extras for smtpd

this one to be precise.

# pkg_delete opensmtpd-extras
# pkg_add opensmtpd-table-passwd

Then "passwd" tables will work again.  Restart smtpd and it should be
back working.

Re: OpenSmtpd + Dovecot failed

[latincom]

> On 2024/06/09 20:53:53 -0700, latin...@vcn.bc.ca wrote:
>> Hello
>>
>> I am having this log lines and i am not able to find the error, could
>> someone help please?:
>> Jun  9 19:57:24 hawk smtpd[37247]: info: OpenSMTPD 7.5.0 starting
>> Jun  9 19:57:24 hawk smtpd[97671]: warn: table-proc: pipe closed
>> Jun  9 19:57:24 hawk smtpd[97671]: lookup: table-proc: exiting
>
> smtpd dies because of this: an external table died.
>
>> [...]
>> # tables setup
>> table domains file:/etc/mail/domains
>> table passwd passwd:/etc/mail/passwd
>
> I guess it's table passwd.

yes, i changed passwd: to file: and smtpd started but is nor reachable
from outside. the patches 1 and 3 are not installed!
opensmtpd-extras-6.7.1p0v0 deleted.

OpenBSD 7.5 (GENERIC) #79: Wed Mar 20 15:33:49 MDT 2024
# pkg_info
bzip2-1.0.8p0   block-sorting file compressor, unencumbered
dovecot-2.3.21v0compact IMAP/POP3 server
gettext-runtime-0.22.5 GNU gettext runtime libraries and programs
icu4c-74.2v0International Components for Unicode
intel-firmware-20240514v0 microcode update binaries for Intel CPUs
libexttextcat-3.4.6 UTF-8 aware language guessing library
libiconv-1.17   character set conversion library
libopensmtpd-0.7library for writing opensmtpd filters
libsodium-1.0.19library for network communications and cryptography
libstemmer-2.2.0stemming algorithms for text processing
lz4-1.9.4   fast BSD-licensed data compression
nano-7.2simple editor, inspired by Pico
opensmtpd-extras-6.7.1p0v0 extras for smtpd
opensmtpd-filter-dkimsign-0.5p2 dkim signer integration to the OpenSMTPD
daemon
quirks-7.14 exceptions to pkg_add rules
sqlite3-3.44.2  embedded SQL implementation
updatedb-0p0pkg_add speed up cache
xz-5.4.5library and tools for XZ and LZMA compressed files
znc-1.8.2p6 advanced IRC bouncer
zstd-1.5.5  zstandard fast real-time compression algorithm

>
> Recently the protocol for table was changed.  If you're running
> OpenBSD-CURRENT, remove opensmtpd-extra, install opensmtpd-table-passwd
> and restart smtpd.  No further changes are needed.
>
> (pkg_add -u should warn that opensmtpd-extra is deprecated and show a
> message that suggests to install the right opensmtpd-table-* package.
> It's also in the "following -current" FAQ page, will become part of the
> next OpenBSD release note.)
>
> If you're running a self-built opensmtpd from the github repo on other
> systems, you have to do the same except that you need to grab
> table-passwd from https://github.com/opensmtpd/table-passwd

Thanks man
>

Re: OpenSmtpd + Dovecot failed

[Omar Polo]

On 2024/06/09 20:53:53 -0700, latin...@vcn.bc.ca wrote:
> Hello
> 
> I am having this log lines and i am not able to find the error, could
> someone help please?:
> Jun  9 19:57:24 hawk smtpd[37247]: info: OpenSMTPD 7.5.0 starting
> Jun  9 19:57:24 hawk smtpd[97671]: warn: table-proc: pipe closed
> Jun  9 19:57:24 hawk smtpd[97671]: lookup: table-proc: exiting

smtpd dies because of this: an external table died.

> [...]
> # tables setup
> table domains file:/etc/mail/domains
> table passwd passwd:/etc/mail/passwd

I guess it's table passwd.

Recently the protocol for table was changed.  If you're running
OpenBSD-CURRENT, remove opensmtpd-extra, install opensmtpd-table-passwd
and restart smtpd.  No further changes are needed.

(pkg_add -u should warn that opensmtpd-extra is deprecated and show a
message that suggests to install the right opensmtpd-table-* package.
It's also in the "following -current" FAQ page, will become part of the
next OpenBSD release note.)

If you're running a self-built opensmtpd from the github repo on other
systems, you have to do the same except that you need to grab
table-passwd from https://github.com/opensmtpd/table-passwd

Re: Table C API

[Philipp]

[2024-05-30 21:54] Philipp 
> I have also implement some fallback handler for the old api. They are
> primary for simpler testing and development. Patcher are tested with
> table-ldap and attached. The patches are currenty seperated by query
> type. For the push I would put them togetter in one commit.

I noticed some missing frees in the code. Fixes are attached.

Philipp
From f1492ea87f501c0949ff410ede064b9431842f82 Mon Sep 17 00:00:00 2001
From: Philipp Takacs 
Date: Fri, 31 May 2024 15:10:12 +0200
Subject: [PATCH 10/11] fixup! add error result function

---
 table_api.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/table_api.c b/table_api.c
index 694be68..9f0fe9c 100644
--- a/table_api.c
+++ b/table_api.c
@@ -288,6 +288,7 @@ table_api_error(const char *id, const char *error)
 #endif
 	if (fflush(stdout) == EOF)
 		err(1, "fflush");
+	free(req);
 }
 
 void
-- 
2.39.2

From ff1bf8dfe89dbf6a01e5a32c6530ca04b7287866 Mon Sep 17 00:00:00 2001
From: Philipp Takacs 
Date: Fri, 31 May 2024 15:11:09 +0200
Subject: [PATCH 11/11] fixup! implement async lookup

---
 table_api.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/table_api.c b/table_api.c
index 9f0fe9c..b5cce42 100644
--- a/table_api.c
+++ b/table_api.c
@@ -252,6 +252,7 @@ void
 table_api_error(const char *id, const char *error)
 {
 	struct request  *req;
+	struct evbuffer	*res;
 
 	req = dict_pop(, id);
 
@@ -289,6 +290,9 @@ table_api_error(const char *id, const char *error)
 	if (fflush(stdout) == EOF)
 		err(1, "fflush");
 	free(req);
+	res = dict_pop(_entries, id);
+	if (res)
+		evbuffer_free(res);
 }
 
 void
-- 
2.39.2

Re: filter-dnsbl: feature request and bug report

[Kirill A . Korinsky]

On Sat, 01 Jun 2024 17:50:53 +0100,
Kirill A. Korinsky  wrote:
> 
> Here the quote from updated man page which summirizes changes:
> 

And quoted text had one missed feature. This filter supports -e argument for
each list to specified expected IP which means match. That allows, for
example, use hostkarma.junkemailfilter.com like this:

   -e 127.0.0.2 hostkarma.junkemailfilter.com \
   -w -e 127.0.0.1 hostkarma.junkemailfilter.com \

So, here response 127.0.0.2 means bad, and 127.0.0.1 good.

-- 
wbr, Kirill

Re: filter-dnsbl: feature request and bug report

[Kirill A . Korinsky]

Greetings,

It was a while in this thread, but I don't forget.

I put all my ideas to filter-dnsbl as a fork which is available on GitHub:
https://github.com/catap/opensmtpd-filter-dnsbl

Here the quote from updated man page which summirizes changes:

 filter-dnsbl looks up the IP address of the sender in the blacklist (a
 domain name) and, by default drops the connection if it is found.  If the
 -m flag is specified, it will allow the message to continue, but such a
 message will be marked with X-Spam header with value Yes, and
 X-Spam-DNSBL header containing a list, and any existing headers starting
 with X-Spam will be stripped. If the -w flag is specified before
 blacklist, this list is treated as white list and X-Spam header isn't
 added, but X-Spam-DNSWL header is added instead X-Spam-DNSBL.
 Additionally, if the -d flag is specified before blacklist, it will use
 reverse DNS hostname instead of IP address for loopkup. For more verbose
 logging, the -v flag can be used.

 When DNS error happened it drops the connection, or adds X-Spam header
 with value Unknown and X-Spam-DNS with a list with cause an error if the
 -m flag is specified.

I've attached to this email port file for OpenBSD to to use it.

Additionally, you may grab build version for 7.5 from
https://mx0.catap.net/pub/ where I also keep filter-sign and filter-auth.

Any feedback and testing welcome.

Martijn, do you think this changes can be backported back?

--
wbr, Kirill


filter.tgz
Description: Binary data

Re: New filters auth and sign

[Kirill A . Korinsky]

On Sat, 01 Jun 2024 08:45:00 +0100,
"Corey Hickman"  wrote:
> 
> does it have policy server included? for instance, when DKIM fails, the 
> policy can be set up to deny the message.
> 

Right now it ignores DMARC as if it doesn't exist.

Doing a DMARC lookup for domain and inserting it's results into the header
is possible and not a big deal, but it has some issues.

The first is parsing the From header. It is durable, but different MUA may
follow different logic and parser for this can be quite complicated. And
complicated means bugs.

The second is more ideological. DMARC needs something that aggregates the
results and sends out reports. It shouldn't be a filter for smtpd. But a
filter can write it's decision to log, and something should harvest it to
process and create reports that need to be sent. Anyway, forensic reports,
which should be close to real-time and include a lot of things from the
original email, is a much more complicated story.

All this brings up the question of personal data / GDPR and DMARC. I know of
a very good analysis of DMARC and GDPR in the case of German law [1], which
can be summarized as a quote:

  The reports are fundamentally permitted and justified under data
  protection law. However, the principle of proportionality is to be
  complied with at all times.

Based on this analysis, I assume that only aggregated reports can be used
without legal headaches in the EU.

But implementing only a part of DMARC seems as much worse than not
implementing it at all, and implementing it in its entirety requires a lot
of pieces in place, much more than just a filter.

Thus, DMARC was discussed on the OpenBSD mailing lists a few months ago [2].

As a conclusion, I personally use the p=none policy, because I assume that
my mail should be delivered, and To is not the final destination, it's a
kind of starting direction of the mail's way to the recipient.

Footnotes:
[1]  
https://certified-senders.org/wp-content/uploads/2018/08/Report_DMARC_and_GDPR.pdf

[2]  https://marc.info/?l=openbsd-misc=171015367409290=2

-- 
wbr, Kirill

Re: Rejected recipients

[Paul M Foster]

On Mon, May 27, 2024 at 01:28:28AM -0400, Paul M Foster wrote:

> Folks:
> 
> I'm running OpenSMTPD 6.8.0p2-4+b4 on Debian 12. Here's my config:
> 
> ---
> # $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
> table secrets file:/etc/secrets
> 
> listen on localhost
> 
> # action "relay" relay host smtp+notls://pa...@yosemite.mars.lan:25 auth 
> 
> 
> match from local for any action "relay"
> ---
> 
> The machine's name is buckaroo. My desktop's name is yosemite. For any
> recipient on buckaroo (root, paulf), I get a 550 rejection on that
> recipient. Both those recipients are in the /etc/passwd file. The
> /etc/aliases file contains a forward from root to paulf. By the way,
> variations don't work either: root, root@localhost, r...@buckaroo.mars.lan.
> 
> Any help would be appreciated.

Problem solved. Contents of /home/paulf/.forward:

pa...@yosemite.mars.lan

This would translate paulf into pa...@yosemite.mars.lan, which would *not*
be local, and thus would fail.


-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: apply fcrdns filter but with exemption? SOLVED

[Ian Darwin]

On 5/27/24 4:59 AM, gil...@poolp.org wrote:

May 27, 2024 2:53 AM, "Ian Darwin"  wrote:


On 5/26/24 8:45 PM, gil...@poolp.org wrote:


May 27, 2024 12:41 AM, "Ian Darwin"  wrote:

On 5/26/24 5:40 PM, gil...@poolp.org wrote:

May 26, 2024 9:46 PM, "Ian Darwin"  wrote:

I'd like to use the fcrdns filter but one of my users has a non-negotiable need 
to get mail from a
site with inept administration. Is there a way to let this one site bypass this 
one filter?
I have two fairly standard 'listen' clauses and the corresponding matches. I 
had fcrdns on the
first one for a day or two until the flames started.

...



so basically here's how builtin filters work:
filter check_fcrdns phase connect match !fcrdns \
disconnect "550 no FCrDNS is so 80s"
they hook to a specific phase of the session and match session parameters,
then apply an action if the criterias are matched.
in this case, you hook the connect phase and match !fcrdns, so you will be
killing any client that doesn't have fcrdns immediately.
there are multiple ways to tackle your problem, depending on what info you
have about the clients you want to allow:
a- if you know their IP address, you can keep your check at connect phase,
and add a bypass filter for these specific addresses:

filter check_fcrdns_bypass phase connect match src  bypass
filter check_fcrdns phase connect match !fcrdns \
disconnect "550 no FCrDNS is so 80s"


Woot - that one worked, thanks!

And, I went with the simplest config, not combining them, so it'll be 
easier to remove the bypass when it's no longer needed (you never know, 
the inept admin might take my advice and configure their dns correctly 
:-)).


Thanks

Ian

Re: apply fcrdns filter but with exemption?

[gilles]

May 27, 2024 2:53 AM, "Ian Darwin"  wrote:

> On 5/26/24 8:45 PM, gil...@poolp.org wrote:
> 
>> May 27, 2024 12:41 AM, "Ian Darwin"  wrote:
>>> On 5/26/24 5:40 PM, gil...@poolp.org wrote:
 May 26, 2024 9:46 PM, "Ian Darwin"  wrote:
> I'd like to use the fcrdns filter but one of my users has a 
> non-negotiable need to get mail from a
> site with inept administration. Is there a way to let this one site 
> bypass this one filter?
> I have two fairly standard 'listen' clauses and the corresponding 
> matches. I had fcrdns on the
> first one for a day or two until the flames started.
 listen on egress inet4 port 25 \
 tls pki darwinsys.com \
 filter { check_dyndns, check_rdns, rspamd } \
 tag INCOMING
 listen on egress port submission \
 filter { check_dyndns, check_rdns, rspamd } \
 tls-require pki darwinsys.com \
 auth tag AUTH
> TIA if anyone can help.
 You need to share more than the listen lines.
 You have omitted the check_rdns filter definition which is where we could 
 plug a bypass...
>>> Ah, my bad. Here are all the filter def'ns, right out of somebody's blog :-)
>>> filter check_dyndns phase connect match rdns regex { '.*\.dyn\..*', 
>>> '*\.dsl\..*' } \
>>> disconnect "550 no residential connections"
>>> filter check_rdns phase connect match !rdns \
>>> disconnect "550 no rDNS is so 80s"
>>> filter check_fcrdns phase connect match !fcrdns \
>>> disconnect "550 no FCrDNS is so 80s"
>>> filter "rspamd" proc-exec "filter-rspamd"
>> so basically here's how builtin filters work:
>> filter check_fcrdns phase connect match !fcrdns \
>> disconnect "550 no FCrDNS is so 80s"
>> they hook to a specific phase of the session and match session parameters,
>> then apply an action if the criterias are matched.
>> in this case, you hook the connect phase and match !fcrdns, so you will be
>> killing any client that doesn't have fcrdns immediately.
>> there are multiple ways to tackle your problem, depending on what info you
>> have about the clients you want to allow:
>> a- if you know their IP address, you can keep your check at connect phase,
>> and add a bypass filter for these specific addresses:
>> filter check_fcrdns_bypass phase connect match src  bypass
>> filter check_fcrdns phase connect match !fcrdns \
>> disconnect "550 no FCrDNS is so 80s"
>> b- if you don't know their IP address, you can use the same logic but you
>> hook a later phase so the session has more informations:
>> filter check_fcrdns_bypass phase mail-from match mail-from  bypass
>> filter check_fcrdns phase mail-from match !fcrdns \
>> disconnect "550 no FCrDNS is so 80s"
>> maybe you can compact them in a single rule with multiple criterias, along
>> the lines of:
>> filter check_fcrdns phase mail-from match !mail-from  !fcrdns \
>> disconnect "550 no FCrDNS is so 80s"
>> it probably works but it's late and I'm tired so maybe not.
> Great, thanks for the reply! I'll try it in the morning :-)
> 
> And just to clarify, in "match !mail-from  !fcrdns" i.e., any match with 
> multiple conditions,
> are they ANDed or ORed? The man page is vague:
> 
> match options action name If at least one mail envelope matches the options 
> of one match action
> directive,
> 

They are ANDed, like match rules, it is the only way rules can be unambiguous.

Re: apply fcrdns filter but with exemption?

[Ian Darwin]

On 5/26/24 8:45 PM, gil...@poolp.org wrote:

May 27, 2024 12:41 AM, "Ian Darwin"  wrote:


On 5/26/24 5:40 PM,gil...@poolp.org  wrote:


May 26, 2024 9:46 PM, "Ian Darwin"  wrote:


I'd like to use the fcrdns filter but one of my users has a non-negotiable need 
to get mail from a
site with inept administration. Is there a way to let this one site bypass this 
one filter?

I have two fairly standard 'listen' clauses and the corresponding matches. I 
had fcrdns on the
first one for a day or two until the flames started.

listen on egress inet4 port 25 \
tls pki darwinsys.com \
filter { check_dyndns, check_rdns, rspamd } \
tag INCOMING
listen on egress port submission \
filter { check_dyndns, check_rdns, rspamd } \
tls-require pki darwinsys.com \
auth tag AUTH

TIA if anyone can help.

You need to share more than the listen lines.

You have omitted the check_rdns filter definition which is where we could plug 
a bypass...

Ah, my bad. Here are all the filter def'ns, right out of somebody's blog :-)

filter check_dyndns phase connect match rdns regex { '.*\.dyn\..*', 
'.*\.dsl\..*' } \
disconnect "550 no residential connections"

filter check_rdns phase connect match !rdns \
disconnect "550 no rDNS is so 80s"

filter check_fcrdns phase connect match !fcrdns \
disconnect "550 no FCrDNS is so 80s"

filter "rspamd" proc-exec "filter-rspamd"


so basically here's how builtin filters work:

 filter check_fcrdns phase connect match !fcrdns \
 disconnect "550 no FCrDNS is so 80s"

they hook to a specific phase of the session and match session parameters,
then apply an action if the criterias are matched.

in this case, you hook the connect phase and match !fcrdns, so you will be
killing any client that doesn't have fcrdns immediately.

there are multiple ways to tackle your problem, depending on what info you
have about the clients you want to allow:

a- if you know their IP address, you can keep your check at connect phase,
and add a bypass filter for these specific addresses:

filter check_fcrdns_bypass phase connect match src  bypass
filter check_fcrdns phase connect match !fcrdns \
 disconnect "550 no FCrDNS is so 80s"

b- if you don't know their IP address, you can use the same logic but you
hook a later phase so the session has more informations:

filter check_fcrdns_bypass phase mail-from match mail-from  
bypass
filter check_fcrdns phase mail-from match !fcrdns \
 disconnect "550 no FCrDNS is so 80s"


maybe you can compact them in a single rule with multiple criterias, along
the lines of:

filter check_fcrdns phase mail-from match !mail-from  !fcrdns \
 disconnect "550 no FCrDNS is so 80s"

it probably works but it's late and I'm tired so maybe not.


Great, thanks for the reply! I'll try it in the morning :-)

And just to clarify, in "match !mail-from  !fcrdns" i.e., any match 
with multiple conditions, are they ANDed or ORed? The man page is vague:


match options action name If at least one mail envelope matches the 
options of one match action directive,


Thanks again!

--ian

Re: apply fcrdns filter but with exemption?

[gilles]

May 27, 2024 12:41 AM, "Ian Darwin"  wrote:

> On 5/26/24 5:40 PM, gil...@poolp.org wrote:
> 
>> May 26, 2024 9:46 PM, "Ian Darwin"  wrote:
>> 
>>> I'd like to use the fcrdns filter but one of my users has a non-negotiable 
>>> need to get mail from a
>>> site with inept administration. Is there a way to let this one site bypass 
>>> this one filter?
>>> 
>>> I have two fairly standard 'listen' clauses and the corresponding matches. 
>>> I had fcrdns on the
>>> first one for a day or two until the flames started.
>> 
>> listen on egress inet4 port 25 \
>> tls pki darwinsys.com \
>> filter { check_dyndns, check_rdns, rspamd } \
>> tag INCOMING
>> listen on egress port submission \
>> filter { check_dyndns, check_rdns, rspamd } \
>> tls-require pki darwinsys.com \
>> auth tag AUTH
>>> TIA if anyone can help.
>> 
>> You need to share more than the listen lines.
>> 
>> You have omitted the check_rdns filter definition which is where we could 
>> plug a bypass...
> 
> Ah, my bad. Here are all the filter def'ns, right out of somebody's blog :-)
> 
> filter check_dyndns phase connect match rdns regex { '.*\.dyn\..*', 
> '*\.dsl\..*' } \
> disconnect "550 no residential connections"
> 
> filter check_rdns phase connect match !rdns \
> disconnect "550 no rDNS is so 80s"
> 
> filter check_fcrdns phase connect match !fcrdns \
> disconnect "550 no FCrDNS is so 80s"
> 
> filter "rspamd" proc-exec "filter-rspamd"
> 

so basically here's how builtin filters work:

filter check_fcrdns phase connect match !fcrdns \
disconnect "550 no FCrDNS is so 80s"

they hook to a specific phase of the session and match session parameters,
then apply an action if the criterias are matched.

in this case, you hook the connect phase and match !fcrdns, so you will be
killing any client that doesn't have fcrdns immediately.

there are multiple ways to tackle your problem, depending on what info you
have about the clients you want to allow:

a- if you know their IP address, you can keep your check at connect phase,
   and add a bypass filter for these specific addresses:

   filter check_fcrdns_bypass phase connect match src  bypass
   filter check_fcrdns phase connect match !fcrdns \
disconnect "550 no FCrDNS is so 80s"

b- if you don't know their IP address, you can use the same logic but you
   hook a later phase so the session has more informations:

   filter check_fcrdns_bypass phase mail-from match mail-from  bypass
   filter check_fcrdns phase mail-from match !fcrdns \
disconnect "550 no FCrDNS is so 80s"


maybe you can compact them in a single rule with multiple criterias, along
the lines of:

   filter check_fcrdns phase mail-from match !mail-from  !fcrdns \
disconnect "550 no FCrDNS is so 80s"

it probably works but it's late and I'm tired so maybe not.

Re: apply fcrdns filter but with exemption?

[Ian Darwin]

On 5/26/24 5:40 PM, gil...@poolp.org wrote:

May 26, 2024 9:46 PM, "Ian Darwin"  wrote:


I'd like to use the fcrdns filter but one of my users has a non-negotiable need 
to get mail from a
site with inept administration. Is there a way to let this one site bypass this 
one filter?

I have two fairly standard 'listen' clauses and the corresponding matches. I 
had fcrdns on the
first one for a day or two until the flames started.


listen on egress inet4 port 25 \
tls pki darwinsys.com \
filter { check_dyndns, check_rdns, rspamd } \
tag INCOMING
listen on egress port submission \
filter { check_dyndns, check_rdns, rspamd } \
tls-require pki darwinsys.com \
auth tag AUTH

TIA if anyone can help.

You need to share more than the listen lines.

You have omitted the check_rdns filter definition which is where we could plug 
a bypass...


Ah, my bad. Here are all the filter def'ns, right out of somebody's blog :-)

filter check_dyndns phase connect match rdns regex { '.*\.dyn\..*', 
'.*\.dsl\..*' } \

    disconnect "550 no residential connections"

filter check_rdns phase connect match !rdns \
    disconnect "550 no rDNS is so 80s"

filter check_fcrdns phase connect match !fcrdns \
    disconnect "550 no FCrDNS is so 80s"

filter "rspamd" proc-exec "filter-rspamd"

Thanks

Re: apply fcrdns filter but with exemption?

[gilles]

May 26, 2024 9:46 PM, "Ian Darwin"  wrote:

> I'd like to use the fcrdns filter but one of my users has a non-negotiable 
> need to get mail from a
> site with inept administration. Is there a way to let this one site bypass 
> this one filter?
> 
> I have two fairly standard 'listen' clauses and the corresponding matches. I 
> had fcrdns on the
> first one for a day or two until the flames started.
> 
>> listen on egress inet4 port 25 \
>> tls pki darwinsys.com \
>> filter { check_dyndns, check_rdns, rspamd } \
>> tag INCOMING
>> listen on egress port submission \
>> filter { check_dyndns, check_rdns, rspamd } \
>> tls-require pki darwinsys.com \
>> auth tag AUTH
> 
> TIA if anyone can help.

You need to share more than the listen lines.

You have omitted the check_rdns filter definition which is where we could plug 
a bypass...

Re: Change "524 5.2.4 Mailing list expansion problem" to "550 Invalid recipient"?

[Kirill A . Korinsky]

On Tue, 14 May 2024 11:41:54 +0100,
Jesper Wallin  wrote:
> 
> ps, while writing this mail, satanist on IRC suggested the workaround
> of adding 'rcpt-to ', which might invalidate my
> suggestion/patch... Still, I find the mailing list expansion error more
> confusing than helpful.

I use rcpt-to virtual  in my mail server and it replies to spammer
with invlaid emails like this:

May 14 10:16:58 mx2 smtpd[5018]: 112db6ee6676ecb6 smtp failed-command 
command="RCPT TO:" result="524 5.2.4 Mailing list expansion 
problem: "

From my point of view your patch is the right move.

-- 
wbr, Kirill

Re: OpenSMTPd Denial-of-Service with table-mysql (using default configuration)

[Omar Polo]

On 2024/05/13 09:38:40 +0200, Philipp  wrote:
> Hi
> 
> Sorry, this mail was overseen.

Yeah, sorry.

> [2022-08-30 13:23] "Tobias Fiebig" 
> > I just started to see some DoS issue on my OpenSMTPd with table-mysql as 
> > the backend. Specifically, my server ran into the user lookup process 
> > eating a full core and torturing the mysql
> > server after some funny brute-force attempts came in. (writeup with graphs 
> > here: 
> > https://doing-stupid-things.as59645.net/mail/opensmtpd/mysql/2022/08/30/receiving-an-email.html
> >  )
> >
> > After some amateur debugging on my side, it seems like the issue occurs if 
> > the mysql table is latin1 (happens if following defaults and table-mysql 
> > man) and something is shipped to
> > opensmtpd which does not cleanly cast to latin1 (i.e., is not plain ascii), 
> > as opensmtpd speaks UTF8 with mysql (again, my amateur analysis).
> 
> I hope this doesn't sounds to harsh, but this sounds more like a configuration
> issue on your MySQL database, ...

(seconded)

> > The query then fails/mysql kills the connection, and table-mysql retries 
> > the connection with the same data leading to mysql... you get the idea, and 
> > this then happens at 350+ queries/s. 
> 
> ..., but table-mysql (and table-postgres) should handle this better.

completely agree.

> > Would it make sense to have the db-table backends return a tempfailure (for 
> > lookups for domain/forward/deliver we'd probably not want to reject mail 
> > due to a DB failure) or error
> > (auth etc.) if the same query fails like N (5 as default?) times in a row?
> 
> A patch limit it to one retry is attached. I don't think it's necesary to
> do more then one retry.

At the moment one retry seems the most sensible to me too.   (even if I
think table_mysql should try to differentiate between failure codes.)

philipp: in any case, I've applied your diff and then landed a tweak on
top.  your diff (except for one case) had an issue where it won't retry
the query (reply_times is 1 but gets immediately decremented to zero at
the start, so after the first goto retry it becomes -1 and fails)


Thanks!

Re: OpenSMTPD 7.5.0 fails to start?

[Omar Polo]

On 2024/05/11 14:35:09 +0200, Thomas Bohl  wrote:
> > I am on OpenBSD 7.5-current playing around a bit and noticed that
> > smtpd fails to start.
> 
> > I then ran smtpd -d and I get:
> > credentials[40067]: warn: table-api: imsg_get: Result too large
> > lookup: table-proc: no services registered
> > smtpd: process lka socket closed
> 
> Probably the beginning of API changes:
> https://www.mail-archive.com/misc@opensmtpd.org/msg06266.html

Exactly.

The tables in opensmtpd-extras were changed to use the new
smtpd-tables(7) protocol and were splitted in different repos.  The
configuration doesn't need any change, but you have to remove the table
you're using and install the right one from the opensmtpd-table-* set of
packages.

See also https://www.openbsd.org/faq/current.html#r20240507

Re: OpenSMTPd Denial-of-Service with table-mysql (using default configuration)

[Philipp]

Hi

Sorry, this mail was overseen.

[2022-08-30 13:23] "Tobias Fiebig" 
> I just started to see some DoS issue on my OpenSMTPd with table-mysql as the 
> backend. Specifically, my server ran into the user lookup process eating a 
> full core and torturing the mysql
> server after some funny brute-force attempts came in. (writeup with graphs 
> here: 
> https://doing-stupid-things.as59645.net/mail/opensmtpd/mysql/2022/08/30/receiving-an-email.html
>  )
>
> After some amateur debugging on my side, it seems like the issue occurs if 
> the mysql table is latin1 (happens if following defaults and table-mysql man) 
> and something is shipped to
> opensmtpd which does not cleanly cast to latin1 (i.e., is not plain ascii), 
> as opensmtpd speaks UTF8 with mysql (again, my amateur analysis).

I hope this doesn't sounds to harsh, but this sounds more like a configuration
issue on your MySQL database, ...

> The query then fails/mysql kills the connection, and table-mysql retries the 
> connection with the same data leading to mysql... you get the idea, and this 
> then happens at 350+ queries/s. 

..., but table-mysql (and table-postgres) should handle this better.

> Would it make sense to have the db-table backends return a tempfailure (for 
> lookups for domain/forward/deliver we'd probably not want to reject mail due 
> to a DB failure) or error
> (auth etc.) if the same query fails like N (5 as default?) times in a row?

A patch limit it to one retry is attached. I don't think it's necesary to
do more then one retry.

Philipp
From b3c7fa2346ea48c4c6737bcbbc999f0c48b8556d Mon Sep 17 00:00:00 2001
From: Philipp Takacs 
Date: Mon, 13 May 2024 08:55:35 +0200
Subject: [PATCH] limit retries

---
 table_mysql.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/table_mysql.c b/table_mysql.c
index 0de7f78..2631d6c 100644
--- a/table_mysql.c
+++ b/table_mysql.c
@@ -344,9 +344,14 @@ table_mysql_query(const char *key, int service)
 	MYSQL_BIND	 param[1];
 	unsigned long	 keylen;
 	char		 buffer[LINE_MAX];
-	int		 i;
+	int		 i, retry_times = 1;
 
 retry:
+	retry_times--;
+	if (retry_times < 0) {
+		log_warnx("warn: to many retries");
+		return NULL;
+	}
 	stmt = NULL;
 	for (i = 0; i < SQL_MAX; i++) {
 		if (service == 1 << i) {
@@ -508,12 +513,17 @@ table_mysql_fetch(int service, struct dict *params, char *dst, size_t sz)
 {
 	MYSQL_STMT	*stmt;
 	const char	*k;
-	int		 s;
+	int		 s, retry_times = 1;
 
 	if (config->db == NULL && config_connect(config) == 0)
 		return -1;
 
 retry:
+	retry_times--;
+	if (retry_times < 0) {
+		log_warnx("warn: to many retries");
+		return -1;
+	}
 	if (service != K_SOURCE)
 		return -1;
 
-- 
2.39.2

From 7181583fb615a0b0ffbb75c3816baf58e5c4fdc6 Mon Sep 17 00:00:00 2001
From: Philipp Takacs 
Date: Mon, 13 May 2024 00:50:53 +0200
Subject: [PATCH] limit retries

---
 table_postgres.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/table_postgres.c b/table_postgres.c
index d9f3303..715fad1 100644
--- a/table_postgres.c
+++ b/table_postgres.c
@@ -311,9 +311,14 @@ table_postgres_query(const char *key, int service)
 	PGresult	*res;
 	const char	*errfld;
 	char		*stmt;
-	int		 i;
+	int		 i, retry_times = 2;
 
 retry:
+	retry_times--;
+	if (retry_times < 0) {
+		log_warnx("warn: table-postgres: to many retries");
+		return NULL;
+	}
 	stmt = NULL;
 	for (i = 0; i < SQL_MAX; i++) {
 		if (service == 1 << i) {
@@ -444,12 +449,17 @@ table_postgres_fetch(int service, struct dict *params, char *dst, size_t sz)
 	char		*stmt;
 	PGresult	*res;
 	const char	*k, *errfld;
-	int		 i;
+	int		 i, retry_times = 1;
 
 	if (config->db == NULL && config_connect(config) == 0)
 		return -1;
 
 retry:
+	retry_times--;
+	if (retry_times < 0) {
+		log_warnx("warn: table-postgres: to many retries");
+		return -1;
+	}
 	if (service != K_SOURCE)
 		return -1;
 
-- 
2.39.2

Re: OpenSMTPD 7.5.0 fails to start?

[Thomas Bohl]

I am on OpenBSD 7.5-current playing around a bit and noticed that
smtpd fails to start.



I then ran smtpd -d and I get:
credentials[40067]: warn: table-api: imsg_get: Result too large
lookup: table-proc: no services registered
smtpd: process lka socket closed


Probably the beginning of API changes:
https://www.mail-archive.com/misc@opensmtpd.org/msg06266.html

Re: dual stack and secondary relays -- how to do?

[James J. Lippard]

I've found a workaround and narrowed down the source of the problem by using
tables for src and helo-src (the latter of which proved unnecessary and
irrelevant).  It turns out that in this line:

  action "relayext" relay host  src smtp-ext.domain.com helo 
smtp.domain.com pki "smtp.domain.com" ca "my-ca"

it fails using a DNS name for src, but works just fine with a table
in its place that contains two entries, one for the IPv4 address from that
DNS name's A record and one for the IPv6 address from that DNS name's
 record.

I'm not sure why it fails with the DNS name--I would have thought my
table setup was equivalent--unless it's looking instead for a
(nonexistent) MX record.

BTW, the documentation for helo-src says:

"Use the mapping table to look up a hostname matching the
source address, to advertise during the HELO phase."

It is unclear from this whether "source address" means the local mail
server address or the remote one, but from playing with it it seems that
it means the remote mail server's IP address (i.e., the relay being
connected to in my case).

On Sun, May 05, 2024 at 05:42:58PM -0700, James J. Lippard wrote:
> On Thu, Apr 18, 2024 at 12:18:04PM +0200, Philipp wrote:
> > Hi
> 
> Hi, sorry about the delay.
> 
> > [2024-04-16 16:44] "James J. Lippard" 
> > > I run dual-stack IPv6/IPv4 networks, including mail servers. On occasion
> > > I may not have IPv6 connectivity, but have IPv4 connectivity. When that
> > > happens, I find that my mail queue accumulates mail that arrives over
> > > IPv6, but cannot be sent out on an IPv6 interface.
> > 
> > Which IP version was used to enqueue a mail is indipendent from the
> > IP version used to relay a mail. Also for most cases dual stack just
> > works(tm) when using hostnames with A and  records and use "listen on"
> > with interface name.
> 
> It is likely I've created some dependency with overcomplication -- I'm
> doing split horizon DNS as well as dual-stack IPv4/v6 , and am also
> listening on IPv6 unique local addresses rather than the public
> addresses that correspond to the public DNS names.  I'll have to see
> if I can simplify it and still run into issues.
> 
> I attempted to change the "src" on my outbound relay actions to use a
> single DNS name with the correct outbound IPv4 and IPv6 addresses:
> 
> action "relayext" relay host  src smtp-ext.domain.com helo 
> smtp.domain.com pki "smtp.domain.com" ca "my-ca"
> 
> which led to the error:
> 
> smtpd[60955]: warn: Failed to get source address for 
> [relay:[mx.domain.com],port=587,smtp+tls,pki_name=smtp.domain.com,mx,sourcetable=,heloname=smtp.domain.com]
> 
> This then leads to stat="No valid route to destination" and
> result="TempFail" on the mta delivery.
> 
> All works fine if I continue to have separate v4/v6 actions to relay
> using IP address instead of DNS name.  This is still with separate
> listens for v4 and v6.
> 
> It looks like the issue here may be caused by smtp.domain.com--the
> name used for helo and pki but not for the IP address to send
> from--not being in internal DNS?  But if that's the case, why does it work 
> fine
> if I use an IP address instead of an FQDN for "src"?  Is the logic that
> it is picking address family for the outbound connection on the src address,
> if evident, but then using helo or pki if src is a FQDN with both  and A
> records?
> 
> > > (1) How to relay both IPv4/IPv6 outbound mail, regardless of whether it
> > > came to the mail server via IPv4 or IPv6?
> > >
> > > Is it possible to set up a relay action that works with either IPv6 or
> > > IPv4, perhaps with a preference for one or the other?  I've tried
> > > using "src |" on my relay action, but this
> > > results in "No valid route to destination" errors (apparently due to
> > > the name resolution on the smtp+tls:// URL returning the address from
> > > the family opposite the selected src interface?).
> > >
> > > I'd like inbound mail to come in via IPv4 or IPv6 and go out with a
> > > preference for IPv6 but still work with IPv4 if IPv6 is unavailable.
> > 
> > I don't understand what what exactly is the problem. Can you share your
> > config and a short explanation what you want to achive? Some logs
> > showing the problem could also help.
> > 
> > > (2) How to set up a secondary relay to use if a destination relay is
> > > unavailable?
> > >
> > > Is it possible to define multiple relay hosts in one action, or to
> > > specify that a second relay action is to occur in the event of failure
> > > of the first using match rules?
> > 
> > The host option of action relay takes a table. So you can simply specify
> > multible relay-urls with something like:
> > 
> > > { smtp+tls://hosta.example.com , smtp+tls://hostb.example.com }
> 
> This works great, thank you.
> 
> -- 
> Jim Lippardlippard-opensm...@discord.org   http://www.discord.org/
> GPG Key ID: 0x99FD5CD6
> 
> 
> 

-- 
Jim Lippardlippard-opensm...@discord.org   http://www.discord.org/
GPG 

Re: Negative Senderscore ?

[J Doe]

On 2024-05-06 10:39, gil...@poolp.org wrote:


May 5, 2024 11:34 PM, "J Doe"  wrote:


On 2024-05-05 17:26, gil...@poolp.org wrote:


May 5, 2024 11:18 PM, "J Doe"  wrote:


Hello,


Hello,


I am using the Senderscore OpenSMTPD filter from packages on OpenBSD
7.5. All packages installed are up-to-date.

In my mail server logs I noticed:

May 4 20:12:44 server smtpd[58189]: check_senderscore:
link-connect addr=115.231.78.9 score=-1

This is the first time I have seen a negative score. According to the
Senderscore website[0] scores should be between zero and one hundred.

What does a negative result mean ?


In most cases, -1 means that the IP address is not known to senderscore,
implying a neutral reputation.


Hi Gilles,

Thank you for your reply.

Ok, if a negative number means the address is not known (and has neither
a good or bad reputation), does the argument: -blockBelow take this into
account ?

For example, on my server I use

filter check_senderscore proc-exec "filter-senderscore
-scoreHeader -blockBelow 11" ...

.. so I want scores of 10 and lower to be blocked, but I wouldn't want
a negative score blocked as there is no reputation data.

Does the filter take that into account or will a negative score lead to
a block based on how I have configured it ?



Yes, the filter takes that into account.
-1 is a filter specific-value to determine if... it should take the value into 
account.


Hi Gilles,

Ok, great - thanks for clearing that up for me!

- J

Re: Negative Senderscore ?

[gilles]

May 5, 2024 11:34 PM, "J Doe"  wrote:

> On 2024-05-05 17:26, gil...@poolp.org wrote:
> 
>> May 5, 2024 11:18 PM, "J Doe"  wrote:
>> 
>>> Hello,
>> 
>> Hello,
>> 
>>> I am using the Senderscore OpenSMTPD filter from packages on OpenBSD
>>> 7.5. All packages installed are up-to-date.
>>> 
>>> In my mail server logs I noticed:
>>> 
>>> May 4 20:12:44 server smtpd[58189]: check_senderscore:
>>> link-connect addr=115.231.78.9 score=-1
>>> 
>>> This is the first time I have seen a negative score. According to the
>>> Senderscore website[0] scores should be between zero and one hundred.
>>> 
>>> What does a negative result mean ?
>> 
>> In most cases, -1 means that the IP address is not known to senderscore,
>> implying a neutral reputation.
> 
> Hi Gilles,
> 
> Thank you for your reply.
> 
> Ok, if a negative number means the address is not known (and has neither
> a good or bad reputation), does the argument: -blockBelow take this into
> account ?
> 
> For example, on my server I use
> 
> filter check_senderscore proc-exec "filter-senderscore
> -scoreHeader -blockBelow 11" ...
> 
> .. so I want scores of 10 and lower to be blocked, but I wouldn't want
> a negative score blocked as there is no reputation data.
> 
> Does the filter take that into account or will a negative score lead to
> a block based on how I have configured it ?
> 

Yes, the filter takes that into account.
-1 is a filter specific-value to determine if... it should take the value into 
account.

Re: dual stack and secondary relays -- how to do?

[James J. Lippard]

On Thu, Apr 18, 2024 at 12:18:04PM +0200, Philipp wrote:
> Hi

Hi, sorry about the delay.

> [2024-04-16 16:44] "James J. Lippard" 
> > I run dual-stack IPv6/IPv4 networks, including mail servers. On occasion
> > I may not have IPv6 connectivity, but have IPv4 connectivity. When that
> > happens, I find that my mail queue accumulates mail that arrives over
> > IPv6, but cannot be sent out on an IPv6 interface.
> 
> Which IP version was used to enqueue a mail is indipendent from the
> IP version used to relay a mail. Also for most cases dual stack just
> works(tm) when using hostnames with A and  records and use "listen on"
> with interface name.

It is likely I've created some dependency with overcomplication -- I'm
doing split horizon DNS as well as dual-stack IPv4/v6 , and am also
listening on IPv6 unique local addresses rather than the public
addresses that correspond to the public DNS names.  I'll have to see
if I can simplify it and still run into issues.

I attempted to change the "src" on my outbound relay actions to use a
single DNS name with the correct outbound IPv4 and IPv6 addresses:

action "relayext" relay host  src smtp-ext.domain.com helo 
smtp.domain.com pki "smtp.domain.com" ca "my-ca"

which led to the error:

smtpd[60955]: warn: Failed to get source address for 
[relay:[mx.domain.com],port=587,smtp+tls,pki_name=smtp.domain.com,mx,sourcetable=,heloname=smtp.domain.com]

This then leads to stat="No valid route to destination" and
result="TempFail" on the mta delivery.

All works fine if I continue to have separate v4/v6 actions to relay
using IP address instead of DNS name.  This is still with separate
listens for v4 and v6.

It looks like the issue here may be caused by smtp.domain.com--the
name used for helo and pki but not for the IP address to send
from--not being in internal DNS?  But if that's the case, why does it work fine
if I use an IP address instead of an FQDN for "src"?  Is the logic that
it is picking address family for the outbound connection on the src address,
if evident, but then using helo or pki if src is a FQDN with both  and A
records?

> > (1) How to relay both IPv4/IPv6 outbound mail, regardless of whether it
> > came to the mail server via IPv4 or IPv6?
> >
> > Is it possible to set up a relay action that works with either IPv6 or
> > IPv4, perhaps with a preference for one or the other?  I've tried
> > using "src |" on my relay action, but this
> > results in "No valid route to destination" errors (apparently due to
> > the name resolution on the smtp+tls:// URL returning the address from
> > the family opposite the selected src interface?).
> >
> > I'd like inbound mail to come in via IPv4 or IPv6 and go out with a
> > preference for IPv6 but still work with IPv4 if IPv6 is unavailable.
> 
> I don't understand what what exactly is the problem. Can you share your
> config and a short explanation what you want to achive? Some logs
> showing the problem could also help.
> 
> > (2) How to set up a secondary relay to use if a destination relay is
> > unavailable?
> >
> > Is it possible to define multiple relay hosts in one action, or to
> > specify that a second relay action is to occur in the event of failure
> > of the first using match rules?
> 
> The host option of action relay takes a table. So you can simply specify
> multible relay-urls with something like:
> 
> > { smtp+tls://hosta.example.com , smtp+tls://hostb.example.com }

This works great, thank you.

-- 
Jim Lippardlipp...@discord.org   http://www.discord.org/
GPG Key ID: 0x99FD5CD6

Re: Negative Senderscore ?

[J Doe]

On 2024-05-05 17:26, gil...@poolp.org wrote:


May 5, 2024 11:18 PM, "J Doe"  wrote:


Hello,



Hello,



I am using the Senderscore OpenSMTPD filter from packages on OpenBSD
7.5. All packages installed are up-to-date.

In my mail server logs I noticed:

May 4 20:12:44 server smtpd[58189]: check_senderscore:
link-connect addr=115.231.78.9 score=-1

This is the first time I have seen a negative score. According to the
Senderscore website[0] scores should be between zero and one hundred.

What does a negative result mean ?



In most cases, -1 means that the IP address is not known to senderscore,
implying a neutral reputation.


Hi Gilles,

Thank you for your reply.

Ok, if a negative number means the address is not known (and has neither
a good or bad reputation), does the argument: -blockBelow take this into
account ?

For example, on my server I use

filter check_senderscore proc-exec "filter-senderscore
-scoreHeader -blockBelow 11" ...

.. so I want scores of 10 and lower to be blocked, but I wouldn't want
a negative score blocked as there is no reputation data.

Does the filter take that into account or will a negative score lead to
a block based on how I have configured it ?

Thanks,

- J

Re: Negative Senderscore ?

[gilles]

May 5, 2024 11:18 PM, "J Doe"  wrote:

> Hello,
> 

Hello,


> I am using the Senderscore OpenSMTPD filter from packages on OpenBSD
> 7.5. All packages installed are up-to-date.
> 
> In my mail server logs I noticed:
> 
> May 4 20:12:44 server smtpd[58189]: check_senderscore:
> link-connect addr=115.231.78.9 score=-1
> 
> This is the first time I have seen a negative score. According to the
> Senderscore website[0] scores should be between zero and one hundred.
> 
> What does a negative result mean ?
> 

In most cases, -1 means that the IP address is not known to senderscore,
implying a neutral reputation.

Re: mlmmj upgrade

[epektasis]

Thanks for all your work on this project.
e.

On Thu, May 02, 2024 at 02:38:16PM +, gil...@poolp.org wrote:

Hello misc@,

The mailing list software, mlmmj, has been upgraded to its latest version.

I'd appreciate a couple answers to this mail to make sure it does not introduce 
a regression ;-)

Gilles

Re: mlmmj upgrade

[gilles]

And I received yours which got propagated through the list, upgrade successful.

Sorry for the noise !

May 2, 2024 4:50 PM, "Chris Brannon"  wrote:

> gil...@poolp.org writes:
> 
>> I'd appreciate a couple answers to this mail to make sure it does not
>> introduce a regression ;-)
> 
> I received your message.
> 
> -- Chris

Re: mlmmj upgrade

[Hagen Bauer]

Looks good

02.05.2024 16:38:51 gil...@poolp.org:

> Hello misc@,
> 
> The mailing list software, mlmmj, has been upgraded to its latest version.
> 
> I'd appreciate a couple answers to this mail to make sure it does not 
> introduce a regression ;-)
> 
> Gilles

Re: mlmmj upgrade

[Chris Brannon]

gil...@poolp.org writes:

> I'd appreciate a couple answers to this mail to make sure it does not
> introduce a regression ;-)

I received your message.

-- Chris

Whoops [was Re: OpenBSD Installation Doesn't Detect NVMe SSD, but Detects My USB Drives]

[Stuart Longland]

On 19/4/24 08:54, Stuart Longland wrote:

stuff not relevant to the OpenSMTPD list


Apologies for the noise… auto-complete in the email client picked out 
the wrong email address and I blindly trusted it without checking the 
address properly.


Problem Exists Between Keyboard And Chair.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Re: OpenBSD Installation Doesn't Detect NVMe SSD, but Detects My USB Drives

[Stuart Longland]

On 16/4/24 04:45, Wolfgang Pfeiffer wrote:

On Mon, Apr 15, 2024 at 08:38:51PM +0200, Wolfgang Pfeiffer wrote:

On Mon, Apr 15, 2024 at 08:29:21AM +0200, aliyu...@tutanota.com wrote:

Hello,

I'm currently trying to install OpenBSD on my laptop, and I'm coming
across a problem. The installation only detects my installation drive
and my other USB flash drive that I use for data storage, but not my
NVMe SSD I want to do an installation on.



SATA settings in your BIOS might be worth a try: if sata mode is
set to RAID it might help to switch to ACPI [ .. ]


Wrong: Not ACPI, but AHCI.


Not sure there's any such animal when the device is NVMe.  NVMe directly 
connects to the PCI Express bus, not to a SATA controller.

--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Re: dual stack and secondary relays -- how to do?

[Philipp]

Hi

[2024-04-16 16:44] "James J. Lippard" 
> I run dual-stack IPv6/IPv4 networks, including mail servers. On occasion
> I may not have IPv6 connectivity, but have IPv4 connectivity. When that
> happens, I find that my mail queue accumulates mail that arrives over
> IPv6, but cannot be sent out on an IPv6 interface.

Which IP version was used to enqueue a mail is indipendent from the
IP version used to relay a mail. Also for most cases dual stack just
works(tm) when using hostnames with A and  records and use "listen on"
with interface name.

> (1) How to relay both IPv4/IPv6 outbound mail, regardless of whether it
> came to the mail server via IPv4 or IPv6?
>
> Is it possible to set up a relay action that works with either IPv6 or
> IPv4, perhaps with a preference for one or the other?  I've tried
> using "src |" on my relay action, but this
> results in "No valid route to destination" errors (apparently due to
> the name resolution on the smtp+tls:// URL returning the address from
> the family opposite the selected src interface?).
>
> I'd like inbound mail to come in via IPv4 or IPv6 and go out with a
> preference for IPv6 but still work with IPv4 if IPv6 is unavailable.

I don't understand what what exactly is the problem. Can you share your
config and a short explanation what you want to achive? Some logs
showing the problem could also help.

> (2) How to set up a secondary relay to use if a destination relay is
> unavailable?
>
> Is it possible to define multiple relay hosts in one action, or to
> specify that a second relay action is to occur in the event of failure
> of the first using match rules?

The host option of action relay takes a table. So you can simply specify
multible relay-urls with something like:

> { smtp+tls://hosta.example.com , smtp+tls://hostb.example.com }

Philipp

Re: Samsung printer stopped working w/ opensmtpd - Message is not RFC 2822 compliant"

[Lévai , Dániel]

On Wednesday, April 17th, 2024 at 11:51, Philipp  wrote:
[...]
>
> Looking at the new trace I see the reason[0] for the error. Other then
> I supected it's the body seperator, which does in your case start with
> a WSP. A wild guess is that the boundery parameter of the working mails
> contain ':'.
>
> A workaround for your problem would be a filter which detects these
> mails and remove the WSP from the body seperator. But be carefull with
> such a filter, because it might break other mails quite easy. So make
> sure you only make changes to mails from your scanner.

Thank Philipp for looking into this!
At this point I think I'm just going to live with this and retry rather than 
trying bend space-time around the printer's broken output :)

Daniel

Re: Inject Date and Message-Id

[Kirill A . Korinsky]

Hi,

On Wed, 17 Apr 2024 13:18:47 +0200,
Philipp wrote:
> 
> There was a bug in the code which mixed the byteorder of the port. This
> is fixed in 7.4. So an update might help.
> 

Confirmed, that upgrade to OpenBSD 7.5 fixes an issue.

-- 
wbr, Kirill

Re: Inject Date and Message-Id

[Philipp]

Hi

[2024-04-17 11:34] Kirill A. Korinsky 
> On Wed, 17 Apr 2024 09:48:14 +0200,
> Kirill A. Korinsky wrote:
> > 
> > As simpler solution I see the behaviour for OpenSMTPd to inject MessageId
> > (when it missed) or date.
> > 
> > Or it's bad idea?
> > 
>
> After reading the code I see that it should insert Date and MessageId if
> client is connected to 587 port[1], in my case it uses 587 port and doesn't
> inserted Message-Id nor Date header.

There was a bug in the code which mixed the byteorder of the port. This
is fixed in 7.4. So an update might help.

Philipp

Re: Samsung printer stopped working w/ opensmtpd - Message is not RFC 2822 compliant"

[Philipp]

[2024-04-16 14:49] Lévai, Dániel 
> On Tuesday, April 16th, 2024 at 13:52, Philipp  wrote:
> > [2024-04-15 10:11] Lévai, Dániel l...@ecentrum.hu
> > 
> > > I've been using this Samsung C480FW printer/scanner forever with 
> > > OpenSMTPD and suddenly (no upgrades to OpenSMTPD or changes in the
> > > configuration) it started to complain (it's trying to send scanned 
> > > documents via e-mail):
> > 
> > 
> > Has something on the scanner changed? Like a firmwareupdate or changed
> > settings. Something must have changed, when it has worked and now it
> > doesn't work anymore.
>
> Yeah I know it's always suspicious when someone says "nothing changed" :)
> Really nothing changed on the smtpd server or the printer.
> The last successful scan was from the 12th of April and the next time I tried 
> on the 15th it failed. Today, all of them succeeded ag
> ain.
>
> I suspect it depends on the content of the message, somehow - as the only 
> variable is the actual document I'm scanning. 
> Idk, probably some weird characters, spacing or weird lines - I know, at this 
> point it just sounds sorcery.
>
> Anyway, I was just wondering if there was an option to somehow relax some 
> checks, but I can live with retrying until it succeeds.

As said in the other mail no there is no such option. Such an option
would cause problems in other programms when they try to parse the mail.

> > > It's somewhere after DATA smtpd doesn't like what it's seeing.
> > 
> > Actually I don't see why this message is not accepted. Only think I can
> > imagen is that the Content-features field is not properly folded. So that
> > the character used to indent is not WSP (space or horizontal tab). But
> > this is only a guess.
>
> I have the same suspicion (or let's call it feeling), but can't reproduce 
> this willingly, unfortunately.
>
> > The attached patch adds a few more tracing information for the parser. Can
> > you apply this patch and try again?
>
> I've applied it to OpenBSD 7.4. The only thing I can reproduce this with 
> reliably is the SMTP test function on the printer admin page - so this is not 
> an actual scanned document e-mail that is sometimes failing:

Looking at the new trace I see the reason[0] for the error. Other then
I supected it's the body seperator, which does in your case start with
a WSP. A wild guess is that the boundery parameter of the working mails
contain ':'.

A workaround for your problem would be a filter which detects these
mails and remove the WSP from the body seperator. But be carefull with
such a filter, because it might break other mails quite easy. So make
sure you only make changes to mails from your scanner.

Philipp

[0] besides my inability to copy paste variables

Re: Inject Date and Message-Id

[Kirill A . Korinsky]

On Wed, 17 Apr 2024 09:48:14 +0200,
Kirill A. Korinsky wrote:
> 
> As simpler solution I see the behaviour for OpenSMTPd to inject MessageId
> (when it missed) or date.
> 
> Or it's bad idea?
> 

After reading the code I see that it should insert Date and MessageId if
client is connected to 587 port[1], in my case it uses 587 port and doesn't
inserted Message-Id nor Date header.

The listers looks like:

  listen on egress port smtps \
 smtps pki mx.catap.net auth  mask-src filter dkimsign
  listen on egress port submission \
 tls-require pki mx.catap.net auth  mask-src filter 
dkimsign

and that it uses 587 was just confirmed by tcpdump.

Footnotes:
[1]  
https://github.com/OpenSMTPD/OpenSMTPD/blob/v6.8.0p2/usr.sbin/smtpd/smtp_session.c#L2739-L2757

-- 
wbr, Kirill

Re: Samsung printer stopped working w/ opensmtpd - Message is not RFC 2822 compliant"

[Lévai , Dániel]

On Tuesday, April 16th, 2024 at 13:52, Philipp  wrote:
> 
> 
> Hi
> 
> [2024-04-15 10:11] Lévai, Dániel l...@ecentrum.hu
> 
> > I've been using this Samsung C480FW printer/scanner forever with OpenSMTPD 
> > and suddenly (no upgrades to OpenSMTPD or changes in the
> > configuration) it started to complain (it's trying to send scanned 
> > documents via e-mail):
> 
> 
> Has something on the scanner changed? Like a firmwareupdate or changed
> settings. Something must have changed, when it has worked and now it
> doesn't work anymore.

Yeah I know it's always suspicious when someone says "nothing changed" :)
Really nothing changed on the smtpd server or the printer.
The last successful scan was from the 12th of April and the next time I tried 
on the 15th it failed. Today, all of them succeeded again.

I suspect it depends on the content of the message, somehow - as the only 
variable is the actual document I'm scanning. 
Idk, probably some weird characters, spacing or weird lines - I know, at this 
point it just sounds sorcery.

Anyway, I was just wondering if there was an option to somehow relax some 
checks, but I can live with retrying until it succeeds.

> > It's somewhere after DATA smtpd doesn't like what it's seeing.
> 
> Actually I don't see why this message is not accepted. Only think I can
> imagen is that the Content-features field is not properly folded. So that
> the character used to indent is not WSP (space or horizontal tab). But
> this is only a guess.

I have the same suspicion (or let's call it feeling), but can't reproduce this 
willingly, unfortunately.

> The attached patch adds a few more tracing information for the parser. Can
> you apply this patch and try again?

I've applied it to OpenBSD 7.4. The only thing I can reproduce this with 
reliably is the SMTP test function on the printer admin page - so this is not 
an actual scanned document e-mail that is sometimes failing:

smtp: 0x59783b55000: connected to listener 0x598059cd000 [hostname=xxx, 
port=xxx, tag=INSECURE]
mproc: dispatcher -> lka: realloc 0 -> 128
mproc: dispatcher -> lka : 28 IMSG_GETNAMEINFO
mproc: dispatcher -> control: realloc 0 -> 128
mproc: dispatcher -> control : 46 IMSG_STAT_INCREMENT
mproc: dispatcher -> control : 52 IMSG_STAT_INCREMENT
imsg: control <- dispatcher: IMSG_STAT_INCREMENT (len=46)
imsg: lka <- dispatcher: IMSG_GETNAMEINFO (len=28)
ramstat: increment: smtp.session
ramstat: smtp.session (0x8c602729211): 0 -> 1
imsg: control <- dispatcher: IMSG_STAT_INCREMENT (len=52)
ramstat: increment: smtp.session.inet4
ramstat: smtp.session.inet4 (0x8c5a23055c1): 0 -> 1
mproc: lka -> dispatcher: realloc 0 -> 128
mproc: lka -> dispatcher : 49 IMSG_GETNAMEINFO
imsg: dispatcher <- lka: IMSG_GETNAMEINFO (len=49)
mproc: dispatcher -> lka : 51 IMSG_GETADDRINFO
imsg: lka <- dispatcher: IMSG_GETADDRINFO (len=51)
mproc: lka -> dispatcher : 41 IMSG_GETADDRINFO
mproc: lka -> dispatcher : 8 IMSG_GETADDRINFO_END
imsg: dispatcher <- lka: IMSG_GETADDRINFO (len=41)
imsg: dispatcher <- lka: IMSG_GETADDRINFO_END (len=8)
smtp: 0x59783b55000: STATE_NEW -> STATE_CONNECTED
6a2027eee3c2a5c4 smtp connected address=xxx.xxx.xxx.xxx host=xxx.xxx.xxx.xxx.hu
mproc: dispatcher -> ca: realloc 0 -> 128
mproc: dispatcher -> ca: realloc 128 -> 256
mproc: dispatcher -> ca : 188 IMSG_CA_RSA_PRIVENC (flush)
imsg: ca <- dispatcher: IMSG_CA_RSA_PRIVENC (len=188)
mproc: ca -> dispatcher: realloc 0 -> 128
mproc: ca -> dispatcher: realloc 128 -> 1024
mproc: ca -> dispatcher : 532 IMSG_CA_RSA_PRIVENC
imsg: dispatcher <- ca: IMSG_CA_RSA_PRIVENC (len=532)
smtp: 0x59783b55000: IO_TLSREADY 
6a2027eee3c2a5c4 smtp tls ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
mproc: dispatcher -> control : 44 IMSG_STAT_INCREMENT
smtp: 0x59783b55000: >>> 220 xxx ESMTP OpenSMTPD
imsg: control <- dispatcher: IMSG_STAT_INCREMENT (len=44)
ramstat: increment: smtp.smtps
ramstat: smtp.smtps (0x8c5879cd151): 0 -> 1
smtp: 0x59783b55000: IO_LOWAT 
smtp: 0x59783b55000: IO_DATAIN 
smtp: 0x59783b55000: <<< EHLO SEC84251976C2A5
smtp: 0x59783b55000: STATE_CONNECTED -> STATE_HELO
smtp: 0x59783b55000: >>> 250-xxx Hello SEC84251976C2A5 [xxx.xxx.xxx.xxx], 
pleased to meet you
smtp: 0x59783b55000: >>> 250-8BITMIME
smtp: 0x59783b55000: >>> 250-ENHANCEDSTATUSCODES
smtp: 0x59783b55000: >>> 250-SIZE 36700160
smtp: 0x59783b55000: >>> 250-DSN
smtp: 0x59783b55000: >>> 250-AUTH PLAIN LOGIN
smtp: 0x59783b55000: >>> 250 HELP
smtp: 0x59783b55000: IO_LOWAT 
smtp: 0x59783b55000: IO_DATAIN 
smtp: 0x59783b55000: <<< AUTH LOGIN
smtp: 0x59783b55000: STATE_HELO -> STATE_AUTH_USERNAME
smtp: 0x59783b55000: >>> 334 XXX
smtp: 0x59783b55000: IO_LOWAT 
smtp: 0x59783b55000: IO_DATAIN 
smtp: 0x59783b55000: <<< XXX
smtp: 0x59783b55000: STATE_AUTH_USERNAME -> STATE_AUTH_PASSWORD
smtp: 0x59783b55000: >>> 334 XXX
smtp: 0x59783b55000: IO_LOWAT 
smtp: 0x59783b55000: IO_DATAIN 
smtp: 0x59783b55000: <<< XXX
mproc: dispatcher -> lka : 57 IMSG_SMTP_AUTHENTICATE
imsg: lka <- dispatcher: IMSG_SMTP_AUTHENTICATE (len=57)
lookup: 

Re: Samsung printer stopped working w/ opensmtpd - Message is not RFC 2822 compliant"

[Philipp]

Hi

[2024-04-15 10:11] Lévai, Dániel 
> I've been using this Samsung C480FW printer/scanner forever with OpenSMTPD 
> and suddenly (no upgrades to OpenSMTPD or changes in the 
> configuration) it started to complain (it's trying to send scanned documents 
> via e-mail):

Has something on the scanner changed? Like a firmwareupdate or changed
settings. Something must have changed, when it has worked and now it
doesn't work anymore.

>
> [...]
>
> When I issue an SMTP test on the printer admin page, this is what happens in 
> smtpd:
> # smtpd -d -Tall
> [...]
> smtp: 0xa146908b000: >>> 354 Enter mail, end with "." on a line by itself
> smtp: 0xa146908b000: STATE_HELO -> STATE_BODY
> smtp: 0xa146908b000: IO_LOWAT  tls=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 ib=0 ob=0>
> smtp: 0xa146908b000: IO_DATAIN  tls=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 ib=360 ob=0>
> <<< [MSG] From:"Device Administrator"
> <<< [MSG] To: "Device Administrator"
> <<< [MSG] Subject:=?utf-8?B?VGVzdCBNZXNzYWdl?=
> <<< [MSG] MIME-Version: 1.0
> <<< [MSG] Content-Type: MULTIPART/MIXED; 
> BOUNDARY="=_NextPart_2948fd8e_345963ff_126832f6.29a9d5e8"
> <<< [MSG] Content-features:
> <<< [MSG]   (& (dpi=100) (dpi-xyratio=[100/200]))
> <<< [MSG]
> <<< [MSG] --=_NextPart_2948fd8e_345963ff_126832f6.29a9d5e8
> smtp: 0xa146908b000: IO_DATAIN  tls=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 ib=46 ob=0>
> <<< [MSG] Content-Type: TEXT/PLAIN; charset=US-ASCII
> <<< [MSG]
> smtp: 0xa146908b000: IO_DATAIN  tls=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 ib=17 ob=0>
> smtp: 0xa146908b000: IO_DATAIN  tls=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 ib=75 ob=0>
> <<< [MSG] Test mail sending
> <<< [MSG] --=_NextPart_2948fd8e_345963ff_126832f6.29a9d5e8--
> smtp: 0xa146908b000: IO_DATAIN  tls=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 ib=3 ob=0>
> <<< [MSG] .
> <<< [EOM]
> smtp: 0xa146908b000: >>> 550 5.7.1 Delivery not authorized, message refused: 
> Message is not RFC 2822 compliant
> 1d1e5bc4223e33ab smtp failed-command command="DATA" result="550 5.7.1 
> Delivery not authorized, message refused: Message is not RFC 2822 compliant"

Thanks for the full debug log. I would say this is the intresting part.

> It's somewhere after DATA smtpd doesn't like what it's seeing.

Actually I don't see why this message is not accepted. Only think I can
imagen is that the Content-features field is not properly folded. So that
the character used to indent is not WSP (space or horizontal tab). But
this is only a guess.

The attached patch adds a few more tracing information for the parser. Can
you apply this patch and try again?

> Can I somehow relax some checks in smtpd.conf to allow - a possible broken - 
> SMTP implementation to work reliably?

No, the parser is quite basic and only checks for the bare minimum to be
considderd a mail. A Message failing this parser probaly causing problems
in other programms handling the mail.

Philipp
diff --git a/usr.sbin/smtpd/rfc5322.c b/usr.sbin/smtpd/rfc5322.c
index e009ba77..00a3271d 100644
--- a/usr.sbin/smtpd/rfc5322.c
+++ b/usr.sbin/smtpd/rfc5322.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#include "smtpd.h"
 #include "rfc5322.h"
 
 struct buf {
@@ -136,8 +137,10 @@ _rfc5322_next(struct rfc5322_parser *parser, struct rfc5322_result *res)
 			parser->next = 1;
 			if (parser->unfold) {
 if (buf_cat(>val, "\n") == -1 ||
-buf_cat(>val, line) == -1)
+buf_cat(>val, line) == -1) {
+	log_trace(TRACE_SMTP, "rfc5322 parser: buf_cat failed");
 	return -1;
+}
 			}
 			res->value = line;
 			return RFC5322_HEADER_CONT;
@@ -155,8 +158,10 @@ _rfc5322_next(struct rfc5322_parser *parser, struct rfc5322_result *res)
 		if (line && line[0] != ' ' && line[0] != '\t' &&
 		(pos = strchr(line, ':'))) {
 			len = pos - line;
-			if (buf_grow(>hdr, len + 1) == -1)
+			if (buf_grow(>hdr, len + 1) == -1) {
+log_trace(TRACE_SMTP, "rfc5322 parser: buf_grow failed");
 return -1;
+			}
 			(void)memcpy(parser->hdr.buf, line, len);
 			parser->hdr.buf[len] = '\0';
 			parser->hdr.buflen = len + 1;
@@ -181,6 +186,7 @@ _rfc5322_next(struct rfc5322_parser *parser, struct rfc5322_result *res)
 			return RFC5322_BODY_START;
 		}
 
+		log_trace(TRACE_SMTP, "rfc5322 parser: invalide BODY seperator");
 		errno = EINVAL;
 		return -1;
 
@@ -195,10 +201,12 @@ _rfc5322_next(struct rfc5322_parser *parser, struct rfc5322_result *res)
 		return RFC5322_BODY;
 
 	case RFC5322_END_OF_MESSAGE:
+		log_trace(TRACE_SMTP, "rfc5322 parser: line after EOM (bug)");
 		errno = ENOMSG;
 		return -1;
 
 	default:
+		log_trace(TRACE_SMTP, "rfc5322 parser: unknown state %i", parser->state);
 		errno = EINVAL;
 		return -1;
 	}
diff --git a/usr.sbin/smtpd/rfc5322.h b/usr.sbin/smtpd/rfc5322.h
index 0979bd4c..e0f79009 100644
--- a/usr.sbin/smtpd/rfc5322.h
+++ b/usr.sbin/smtpd/rfc5322.h
@@ -31,6 +31,31 @@ struct rfc5322_result {
 #define	RFC5322_BODY		6
 #define	RFC5322_END_OF_MESSAGE	7
 
+static const char *
+rfc5322_state_string(int s)
+{
+	switch (s) {
+	case 

Re: list server maintenance

[gilles]

April 12, 2024 5:18 PM, "Gilles Chehade"  wrote:

> PONG !
> 
> On Fri, Apr 12, 2024 at 5:14 PM  wrote:
> 
>> April 12, 2024 4:38 PM, gil...@poolp.org wrote:
>> 
>>> Helo,
>>> 
>>> The list server will be upgraded to OpenBSD 7.5 shortly,
>>> there may be minor disruptions and I'll send a mail when it's back to 
>>> verify it is dispatched.
>>> 
>>> Sorry for the noise.
>> 
>> PING ?

The maintenance is over, thanks for your patience.

Re: list server maintenance

[Gilles Chehade]

PONG !

On Fri, Apr 12, 2024 at 5:14 PM  wrote:

> April 12, 2024 4:38 PM, gil...@poolp.org wrote:
>
> > Helo,
> >
> > The list server will be upgraded to OpenBSD 7.5 shortly,
> > there may be minor disruptions and I'll send a mail when it's back to
> verify it is dispatched.
> >
> > Sorry for the noise.
>
> PING ?
>
>

Re: list server maintenance

[gilles]

April 12, 2024 4:38 PM, gil...@poolp.org wrote:

> Helo,
> 
> The list server will be upgraded to OpenBSD 7.5 shortly,
> there may be minor disruptions and I'll send a mail when it's back to verify 
> it is dispatched.
> 
> Sorry for the noise.

PING ?

Re: Disabling incoming SMTP connections: Client limit reached

[Kirill A . Korinsky]

ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
Apr 10 23:33:04 mx1 smtpd[84358]: 6ccf080432179b7a smtp authentication 
user=shipp...@catap.net result=permfail
Apr 10 23:33:05 mx1 smtpd[84358]: 6ccf080432179b7a smtp failed-command 
command="AUTH LOGIN (password)" result="535 Authentication failed"
Apr 10 23:33:09 mx1 smtpd[84358]: 6ccf080432179b7a smtp disconnected 
reason=disconnect
Apr 10 23:33:29 mx1 smtpd[84358]: 6ccf0805d4222851 smtp connected 
address=194.169.175.10 host=
Apr 10 23:33:43 mx1 smtpd[84358]: 6ccf0805d4222851 smtp tls 
ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
Apr 10 23:34:17 mx1 smtpd[84358]: 6ccf0805d4222851 smtp authentication 
user=t...@catap.net result=permfail
Apr 10 23:34:17 mx1 smtpd[84358]: 6ccf0805d4222851 smtp failed-command 
command="AUTH LOGIN (password)" result="535 Authentication failed"
Apr 10 23:34:23 mx1 smtpd[84358]: 6ccf0805d4222851 smtp disconnected 
reason=disconnect
Apr 10 23:34:34 mx1 smtpd[84358]: 6ccf0806a1883889 smtp connected 
address=194.169.175.10 host=
Apr 10 23:34:50 mx1 smtpd[84358]: 6ccf0806a1883889 smtp tls 
ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
Apr 10 23:34:51 mx1 smtpd[84358]: warn: Disabling incoming SMTP 
connections: Client limit reached
Apr 10 23:35:21 mx1 smtpd[84358]: 6ccf0806a1883889 smtp authentication 
user=te...@catap.net result=permfail
Apr 10 23:35:21 mx1 smtpd[84358]: 6ccf0806a1883889 smtp failed-command 
command="AUTH LOGIN (password)" result="535 Authentication failed"
Apr 10 23:35:26 mx1 smtpd[84358]: 6ccf0806a1883889 smtp disconnected 
reason=disconnect
Apr 10 23:35:26 mx1 smtpd[84358]: warn: smtp: fd exhaustion over, 
re-enabling incoming connections
Apr 10 23:35:26 mx1 smtpd[84358]: warn: Disabling incoming SMTP 
connections: Client limit reached
Apr 10 23:35:26 mx1 smtpd[84358]: 6ccf0807ee9b507b smtp connected 
address=91.235.247.80 host=
Apr 10 23:35:26 mx1 smtpd[84358]: 6ccf0807ee9b507b smtp disconnected 
reason=disconnect
Apr 10 23:35:26 mx1 smtpd[84358]: warn: smtp: fd exhaustion over, 
re-enabling incoming connections
Apr 10 23:35:28 mx1 smtpd[84358]: 6ccf0808881acbea smtp connected 
address=221.155.66.205 host=
Apr 10 23:35:28 mx1 smtpd[84358]: 6ccf0808881acbea smtp disconnected 
reason=disconnect
Apr 10 23:35:39 mx1 smtpd[84358]: 6ccf08091d72be29 smtp connected 
address=194.169.175.10 host=
Apr 10 23:35:53 mx1 smtpd[84358]: 6ccf08091d72be29 smtp tls 
ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
Apr 10 23:36:20 mx1 smtpd[84358]: 6ccf08091d72be29 smtp authentication 
user=testm...@catap.net result=permfail
Apr 10 23:36:20 mx1 smtpd[84358]: 6ccf08091d72be29 smtp failed-command 
command="AUTH LOGIN (password)" result="535 Authentication failed"
Apr 10 23:36:28 mx1 smtpd[84358]: 6ccf08091d72be29 smtp disconnected 
reason=disconnect
Apr 10 23:36:44 mx1 smtpd[84358]: 6ccf080a4596f230 smtp connected 
address=194.169.175.10 host=
Apr 10 23:36:53 mx1 smtpd[84358]: 6ccf080a4596f230 smtp tls 
ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
Apr 10 23:37:10 mx1 smtpd[84358]: warn: Disabling incoming SMTP 
connections: Client limit reached
Apr 10 23:37:21 mx1 smtpd[84358]: 6ccf080a4596f230 smtp authentication 
user=testu...@catap.net result=permfail
Apr 10 23:37:22 mx1 smtpd[84358]: 6ccf080a4596f230 smtp failed-command 
command="AUTH LOGIN (password)" result="535 Authentication failed"
Apr 10 23:37:25 mx1 smtpd[84358]: 6ccf080a4596f230 smtp disconnected 
reason=disconnect
Apr 10 23:37:25 mx1 smtpd[84358]: warn: smtp: fd exhaustion over, 
re-enabling incoming connections
Apr 10 23:37:25 mx1 smtpd[84358]: 6ccf080baa2709a1 smtp connected 
address=157.90.134.25 host=www1.wmdd.de
Apr 10 23:37:25 mx1 smtpd[69523]: auth: 6ccf080baa2709a1 spf_record_new: 
Apr 10 23:37:43 mx1 smtpd[84358]: warn: Disabling incoming SMTP 
connections: Client limit reached

mx2:

Apr 11 05:05:19 mx2 smtpd[35705]: 3f9f81f4ed6ea8ec smtp failed-command 
command="AUTH LOGIN (password)" result="535 Authentication failed"
Apr 11 05:05:26 mx2 smtpd[35705]: 3f9f81f4ed6ea8ec smtp disconnected 
reason=disconnect
Apr 11 05:05:40 mx2 smtpd[35705]: 3f9f81f6fd08763a smtp connected 
address=194.169.175.10 host=
Apr 11 05:05:51 mx2 smtpd[35705]: 3f9f81f6fd08763a smtp tls 
ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
Apr 11 05:06:17 mx2 smtpd[35705]: 3f9f81f6fd08763a smtp authentication 
user=servi...@catap.net result=permfail
Apr 11 05:06:18 mx2 smtpd[35705]: 3f9f81f6fd08763a smtp failed-command 
command="AUTH LOGIN (password)" result="535 Authentication failed"
Apr 11 05:06:25 mx2 smtpd[35705]: 3f9f81f6fd08763a smtp disconnected 
reason=disconnect
Apr 11 05:06:45 mx2 smtpd[35705]: 3f9f81f7cba65bbf smtp connected 
address=194.169.175.10 host=
Apr

Re: Disabling incoming SMTP connections: Client limit reached

[gilles]

April 11, 2024 11:37 PM, "Kirill A. Korinsky"  wrote:

> Greetings,
> 

Hello,


> I've noticed that my personal mail stop to working. After some digging in
> the log I discovered the magic line:
> 
> Apr 10 23:37:43 mx1 smtpd[84358]: warn: Disabling incoming SMTP connections: 
> Client limit reached
> 

This looks like clients hogging connections and not releasing them, or a leak
within a filter.

- what do you see with the `fstat` command when the issue happens ?
- do you see unusual trafic in your logs and/or `netstat` ?
- any local script gone wrong in you `ps` output ?
- and more importantly what's your configuration file like ?


> which leads to this issue https://github.com/OpenSMTPD/OpenSMTPD/issues/698
> 
> After reading it and some context, like
> https://www.mail-archive.com/misc@opensmtpd.org/msg03171.html I confuse.
> 
> What is current status of filters and this issue?
> 

Both the issue and the mail you linked date from 2016 and refer to an API that 
was
reverted a few months later because it was overly complex and caused any bug to 
be
a nightmare to fix.

The API in use today was introduced late 2019, three years later, after a 
complete
redesign and rewrite from scratch sharing nothing with the previous attempt. It 
is
working in a radically different way that's much simpler and also easier to fix 
if
a bug is reported.

The status of filters API is that it was part of snapshots since 2018 for 
testing,
released late 2019 as an experimental feature and considered stable since 2020. 
It
has been part of the last 9 OpenBSD releases and OpenSMTPD portable releases 
since
6.6.0p1. Considering that it's the only way to interface DKIM or spam filters, 
the
API is used by a significant amount of users and while bugs can still exist, 
we're
at a point where it's more likely the issue is not with the API itself.


> I'm running OpenSMTPD on OpenBSD 7.4, which I plan to upgrade in few days to
> 7.5, does this upgrade helps with this issue?
> 

The code that caused the issue you mentioned was removed and replaced before 
6.6,
so that's 8 releases before 7.4.

Without understanding what is causing the issue I can't tell you if upgrading 
can
fix but if it does it's not due to a fix in OpenSMTPD.


> BTW it works without any question for month, I guess.
> 

That's another hint that something unusual is happening, I don't see the API
working for month then suddenly leaking descriptors.

Give more details please

Re: DKIM Verification Failures

[Robert B. Carleton]

Lucas Gabriel Vuotto  writes:

> On Fri, Apr 05, 2024 at 08:29:20PM -0500, Robert B. Carleton wrote:
>> ---cut here---
>> 600 IN  TXT "v=spf1 ip4:155.138.244.69 
>> ip6:2001:19f0:6402:39e:5400:4ff:fe49:8b44 a mx -all"
>> _dmarc   600   IN  TXT 
>> "v=DMARC1;p=none;sp=none;pct=100;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dm...@rbcarleton.net;
>> 
>> dk-rsa-20240404._domainkey  600 IN  TXT 
>> v=DKIM1;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzqZNKQgFO2yTVwVmDr+t2w3ez+q1NOEcSSRmHEwK9PnD+grQYHgJeKNpUi3E4xHBDR/HVWxC4aRsZqOIj71SVzRY6GmDV7y2qRZWk4eNOT16u/dedjQFJO7H9lP221zbgGzCI2Kbut1ZVCYttr5qi6L1zuIQvbPJrlwgZpyK+x3wpqvdBmDwdrBFOpLKsODrXsIflsE7NK2TQFJsy4EnVn2FACjiq+X1ut1DMT/If3wzA9q2yjT6kRCwT0z28icAUtF6JHXGmrmWAcLYiLX/ARnVaC7wrZnZ5462AWRXi/hqvfhPHoH7tdMzmmwHBQUsK7I3VkCasVm7VBNKza/0twIDAQAB
>> dk-ed25519-20240404._domainkey  600 IN  TXT 
>> v=DKIM1;k=ed25519;p=xWqw3KWGhpEmIw5M0/eNi3SKcA6euhAmPh3Xs/vhPxs=
>> 
>> dk-metis-rsa-20240404._domainkey600 IN  TXT 
>> v=DKIM1;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzqZNKQgFO2yTVwVmDr+t2w3ez+q1NOEcSSRmHEwK9PnD+grQYHgJeKNpUi3E4xHBDR/HVWxC4aRsZqOIj71SVzRY6GmDV7y2qRZWk4eNOT16u/dedjQFJO7H9lP221zbgGzCI2Kbut1ZVCYttr5qi6L1zuIQvbPJrlwgZpyK+x3wpqvdBmDwdrBFOpLKsODrXsIflsE7NK2TQFJsy4EnVn2FACjiq+X1ut1DMT/If3wzA9q2yjT6kRCwT0z28icAUtF6JHXGmrmWAcLYiLX/ARnVaC7wrZnZ5462AWRXi/hqvfhPHoH7tdMzmmwHBQUsK7I3VkCasVm7VBNKza/0twIDAQAB
>> dk-metis-ed25519-20240404._domainkey600 IN  TXT 
>> v=DKIM1;k=ed25519;p=Ro41ZKYFrQ8n3wlyDnj2wARjTc5VVrePBawtMNy83GE=
>> ---cut here---
>> 
>> Then metis.rbcarleton.net:
>> 
>> ---cut here---
>> 600 IN  TXT "v=spf1 ip4:155.138.244.69 
>> ip6:2001:19f0:6402:39e:5400:4ff:fe49:8b44 a mx -all"
>> _dmarc.metis   600   IN  TXT 
>> "v=DMARC1;p=none;sp=none;pct=100;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dm...@rbcarleton.net;
>> dk-metis-rsa-20240404._domainkey600 IN  TXT 
>> v=DKIM1;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzqZNKQgFO2yTVwVmDr+t2w3ez+q1NOEcSSRmHEwK9PnD+grQYHgJeKNpUi3E4xHBDR/HVWxC4aRsZqOIj71SVzRY6GmDV7y2qRZWk4eNOT16u/dedjQFJO7H9lP221zbgGzCI2Kbut1ZVCYttr5qi6L1zuIQvbPJrlwgZpyK+x3wpqvdBmDwdrBFOpLKsODrXsIflsE7NK2TQFJsy4EnVn2FACjiq+X1ut1DMT/If3wzA9q2yjT6kRCwT0z28icAUtF6JHXGmrmWAcLYiLX/ARnVaC7wrZnZ5462AWRXi/hqvfhPHoH7tdMzmmwHBQUsK7I3VkCasVm7VBNKza/0twIDAQAB
>> dk-metis-ed25519-20240404._domainkey600 IN  TXT 
>> v=DKIM1;k=ed25519;p=Ro41ZKYFrQ8n3wlyDnj2wARjTc5VVrePBawtMNy83GE=
>> ---cut here---
>
> As said in other reply, your record is only "v=DKIM1". Asuming the text
> you shared is part of your zonefile, you should surround the value with
> double-quotes or escape the ";", as it's interpreted as a comment. Also
> remember to split the value every 255 characters. You can achieve that
> so with this small script:
>
>   echo "v=DKIM1;..." | perl -nE 'say join(" ", map {qq{"$_"}} 
> unpack("(A255)*", $_))'
>
> hth,
>   Lucas

Thanks for everone's help. TXT record strings that were too long, and
not using quotes were the issues. Thanks again for pushing me over the
finish line.

Best,

--Bruce

Re: DKIM Verification Failures

[Lucas Gabriel Vuotto]

On Fri, Apr 05, 2024 at 08:29:20PM -0500, Robert B. Carleton wrote:
> ---cut here---
> 600 IN  TXT "v=spf1 ip4:155.138.244.69 
> ip6:2001:19f0:6402:39e:5400:4ff:fe49:8b44 a mx -all"
> _dmarc   600   IN  TXT 
> "v=DMARC1;p=none;sp=none;pct=100;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dm...@rbcarleton.net;
> 
> dk-rsa-20240404._domainkey  600 IN  TXT 
> v=DKIM1;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzqZNKQgFO2yTVwVmDr+t2w3ez+q1NOEcSSRmHEwK9PnD+grQYHgJeKNpUi3E4xHBDR/HVWxC4aRsZqOIj71SVzRY6GmDV7y2qRZWk4eNOT16u/dedjQFJO7H9lP221zbgGzCI2Kbut1ZVCYttr5qi6L1zuIQvbPJrlwgZpyK+x3wpqvdBmDwdrBFOpLKsODrXsIflsE7NK2TQFJsy4EnVn2FACjiq+X1ut1DMT/If3wzA9q2yjT6kRCwT0z28icAUtF6JHXGmrmWAcLYiLX/ARnVaC7wrZnZ5462AWRXi/hqvfhPHoH7tdMzmmwHBQUsK7I3VkCasVm7VBNKza/0twIDAQAB
> dk-ed25519-20240404._domainkey  600 IN  TXT 
> v=DKIM1;k=ed25519;p=xWqw3KWGhpEmIw5M0/eNi3SKcA6euhAmPh3Xs/vhPxs=
> 
> dk-metis-rsa-20240404._domainkey600 IN  TXT 
> v=DKIM1;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzqZNKQgFO2yTVwVmDr+t2w3ez+q1NOEcSSRmHEwK9PnD+grQYHgJeKNpUi3E4xHBDR/HVWxC4aRsZqOIj71SVzRY6GmDV7y2qRZWk4eNOT16u/dedjQFJO7H9lP221zbgGzCI2Kbut1ZVCYttr5qi6L1zuIQvbPJrlwgZpyK+x3wpqvdBmDwdrBFOpLKsODrXsIflsE7NK2TQFJsy4EnVn2FACjiq+X1ut1DMT/If3wzA9q2yjT6kRCwT0z28icAUtF6JHXGmrmWAcLYiLX/ARnVaC7wrZnZ5462AWRXi/hqvfhPHoH7tdMzmmwHBQUsK7I3VkCasVm7VBNKza/0twIDAQAB
> dk-metis-ed25519-20240404._domainkey600 IN  TXT 
> v=DKIM1;k=ed25519;p=Ro41ZKYFrQ8n3wlyDnj2wARjTc5VVrePBawtMNy83GE=
> ---cut here---
> 
> Then metis.rbcarleton.net:
> 
> ---cut here---
> 600 IN  TXT "v=spf1 ip4:155.138.244.69 
> ip6:2001:19f0:6402:39e:5400:4ff:fe49:8b44 a mx -all"
> _dmarc.metis   600   IN  TXT 
> "v=DMARC1;p=none;sp=none;pct=100;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dm...@rbcarleton.net;
> dk-metis-rsa-20240404._domainkey600 IN  TXT 
> v=DKIM1;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzqZNKQgFO2yTVwVmDr+t2w3ez+q1NOEcSSRmHEwK9PnD+grQYHgJeKNpUi3E4xHBDR/HVWxC4aRsZqOIj71SVzRY6GmDV7y2qRZWk4eNOT16u/dedjQFJO7H9lP221zbgGzCI2Kbut1ZVCYttr5qi6L1zuIQvbPJrlwgZpyK+x3wpqvdBmDwdrBFOpLKsODrXsIflsE7NK2TQFJsy4EnVn2FACjiq+X1ut1DMT/If3wzA9q2yjT6kRCwT0z28icAUtF6JHXGmrmWAcLYiLX/ARnVaC7wrZnZ5462AWRXi/hqvfhPHoH7tdMzmmwHBQUsK7I3VkCasVm7VBNKza/0twIDAQAB
> dk-metis-ed25519-20240404._domainkey600 IN  TXT 
> v=DKIM1;k=ed25519;p=Ro41ZKYFrQ8n3wlyDnj2wARjTc5VVrePBawtMNy83GE=
> ---cut here---

As said in other reply, your record is only "v=DKIM1". Asuming the text
you shared is part of your zonefile, you should surround the value with
double-quotes or escape the ";", as it's interpreted as a comment. Also
remember to split the value every 255 characters. You can achieve that
so with this small script:

echo "v=DKIM1;..." | perl -nE 'say join(" ", map {qq{"$_"}} 
unpack("(A255)*", $_))'

hth,
Lucas

Re: DKIM Verification Failures

[Thomas Bohl]

Hi,


DKIM verfication of my emails has been failing for outbound email when
received by other systems. This email contains those signatures. I don't
check DKIM inbound so that's not a concern.

I created DNS entries for both rsa and ed25519 keys.


The public TXT DNS record of dk-rsa-20240404._domainkey and 
dk-metis-rsa-20240404._domainkey only contain "v=DKIM1".


$ dig +short txt dk-rsa-20240404._domainkey.rbcarleton.net
"v=DKIM1"

$ dig +short txt dk-metis-rsa-20240404._domainkey.rbcarleton.net
"v=DKIM1"


In regards to metis.rbcarleton.net no TXT records show up at all.

$ dig +short txt dk-metis-rsa-20240404._domainkey.metis.rbcarleton.net

$ dig +short txt dk-metis-ed25519-20240404._domainkey.metis.rbcarleton.net



I've also done some
reading to sanity check my DNS. Any suggestions. I'm kind of
stumped.


It has to be a problem with your DNS. The public doesn't see what you 
see/think you have put in.


https://mxtoolbox.com/SuperTool.aspx?action=dkim%3arbcarleton.net%3adk-rsa-20240404
https://mxtoolbox.com/SuperTool.aspx?action=dkim%3arbcarleton.net%3adk-metis-rsa-20240404
https://mxtoolbox.com/SuperTool.aspx?action=dkim%3ametis.rbcarleton.net%3adk-metis-rsa-20240404


For when you have fixed your DNS: https://dkimvalidator.com is a nice test.

RE: DKIM Verification Failures

[Andrew Stuart]

Something appears to be wrong with your DNS records. Using mxtoolbox and
easydmarc's dkim validators with your selectors, the response is only
v=DKIM1 and is missing the public key p= portion.
I would start with wrapping the text portion with quotes. Otherwise your DNS
server may need the key split up into chunks. 

Regards,
-Andrew

-Original Message-
From: Robert B. Carleton  
Sent: Friday, April 5, 2024 6:29 PM
To: misc@opensmtpd.org
Subject: DKIM Verification Failures

DKIM verfication of my emails has been failing for outbound email when
received by other systems. This email contains those signatures. I don't
check DKIM inbound so that's not a concern.

I created DNS entries for both rsa and ed25519 keys. The subject hosts are
metis.rbcarleton.net (internal) and terminus.rbcarleton.net (external). I
use smtpd for my MTAs, and use the
opensmtpd-filter-dkimsign-0.5p2 package to sign my outbound emails. I'm
running OpenBSD 7.4.

Here's the SPF/DMARC/DKIM DNS for rbcarleton.net:

---cut here---
600 IN  TXT "v=spf1 ip4:155.138.244.69
ip6:2001:19f0:6402:39e:5400:4ff:fe49:8b44 a mx -all"
_dmarc   600   IN  TXT
"v=DMARC1;p=none;sp=none;pct=100;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dma
r...@rbcarleton.net"

dk-rsa-20240404._domainkey  600 IN  TXT
v=DKIM1;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzqZNKQgFO2yTVwVmDr+t2w
3ez+q1NOEcSSRmHEwK9PnD+grQYHgJeKNpUi3E4xHBDR/HVWxC4aRsZqOIj71SVzRY6GmDV7y2qR
ZWk4eNOT16u/dedjQFJO7H9lP221zbgGzCI2Kbut1ZVCYttr5qi6L1zuIQvbPJrlwgZpyK+x3wpq
vdBmDwdrBFOpLKsODrXsIflsE7NK2TQFJsy4EnVn2FACjiq+X1ut1DMT/If3wzA9q2yjT6kRCwT0
z28icAUtF6JHXGmrmWAcLYiLX/ARnVaC7wrZnZ5462AWRXi/hqvfhPHoH7tdMzmmwHBQUsK7I3Vk
CasVm7VBNKza/0twIDAQAB
dk-ed25519-20240404._domainkey  600 IN  TXT
v=DKIM1;k=ed25519;p=xWqw3KWGhpEmIw5M0/eNi3SKcA6euhAmPh3Xs/vhPxs=

dk-metis-rsa-20240404._domainkey600 IN  TXT
v=DKIM1;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzqZNKQgFO2yTVwVmDr+t2w
3ez+q1NOEcSSRmHEwK9PnD+grQYHgJeKNpUi3E4xHBDR/HVWxC4aRsZqOIj71SVzRY6GmDV7y2qR
ZWk4eNOT16u/dedjQFJO7H9lP221zbgGzCI2Kbut1ZVCYttr5qi6L1zuIQvbPJrlwgZpyK+x3wpq
vdBmDwdrBFOpLKsODrXsIflsE7NK2TQFJsy4EnVn2FACjiq+X1ut1DMT/If3wzA9q2yjT6kRCwT0
z28icAUtF6JHXGmrmWAcLYiLX/ARnVaC7wrZnZ5462AWRXi/hqvfhPHoH7tdMzmmwHBQUsK7I3Vk
CasVm7VBNKza/0twIDAQAB
dk-metis-ed25519-20240404._domainkey600 IN  TXT
v=DKIM1;k=ed25519;p=Ro41ZKYFrQ8n3wlyDnj2wARjTc5VVrePBawtMNy83GE=
---cut here---

Then metis.rbcarleton.net:

---cut here---
600 IN  TXT "v=spf1 ip4:155.138.244.69
ip6:2001:19f0:6402:39e:5400:4ff:fe49:8b44 a mx -all"
_dmarc.metis   600   IN  TXT
"v=DMARC1;p=none;sp=none;pct=100;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dma
r...@rbcarleton.net"
dk-metis-rsa-20240404._domainkey600 IN  TXT
v=DKIM1;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzqZNKQgFO2yTVwVmDr+t2w
3ez+q1NOEcSSRmHEwK9PnD+grQYHgJeKNpUi3E4xHBDR/HVWxC4aRsZqOIj71SVzRY6GmDV7y2qR
ZWk4eNOT16u/dedjQFJO7H9lP221zbgGzCI2Kbut1ZVCYttr5qi6L1zuIQvbPJrlwgZpyK+x3wpq
vdBmDwdrBFOpLKsODrXsIflsE7NK2TQFJsy4EnVn2FACjiq+X1ut1DMT/If3wzA9q2yjT6kRCwT0
z28icAUtF6JHXGmrmWAcLYiLX/ARnVaC7wrZnZ5462AWRXi/hqvfhPHoH7tdMzmmwHBQUsK7I3Vk
CasVm7VBNKza/0twIDAQAB
dk-metis-ed25519-20240404._domainkey600 IN  TXT
v=DKIM1;k=ed25519;p=Ro41ZKYFrQ8n3wlyDnj2wARjTc5VVrePBawtMNy83GE=
---cut here---

I was selective in what I included in the email for the sake of brevity. I
figured dig would be used to see the rest.

I followed the opensmtpd-filter-dkimsign pkg-readme. I've also done some
reading to sanity check my DNS. Any suggestions. I'm kind of stumped. It's
probably something silly, but managing MTAs isn't my day job, so I have less
wisdom for this than I should.

TIA,

--Bruce

RE: How to terminate smtpd filters?

[andrew]

I should have included more information. OS is FreeBSD 13.2. smtpd is 7.3.0 
which is the latest in the pkg collection.
Originally, the only change I made to the filter, was add 
#!/usr/local/bin/python3.9 and made afilter.py executable.
All other filters terminate correctly when smtpd exits.

filter afilter proc-exec "/data/afilter.py"
listen on bridge20 port smtp tls pki mail.tekrealm.net auth-optional 
 filter { afilter, trusted, check_dyndns, check_rdns, 
check_fcrdns, senderscore, rspamd }
listen on bridge20 port smtps smtps pki mail.tekrealm.net auth  
mask-src filter { afilter, rspamd }
action "outbound" relay helo mail.tekrealm.net filter "afilter"

Ultimately, I was able to get it to exit correctly after the confirmation that 
it should exit when stdin closes.
I will submit a patch to the github repo after I beat on this for a few days or 
so.

Thank you for your assistance.
-Andrew

-Original Message-
From: Tassilo Philipp  
Sent: Tuesday, April 2, 2024 1:22 AM
To: gil...@poolp.org
Cc: and...@tekrealm.net; misc@opensmtpd.org
Subject: Re: How to terminate smtpd filters?

I agree with Gilles, your filter should react on stdin closing, but not sure 
how your filter is set up.

Also, just a guess... are you running smtpd on Linux?

Linux doesn't kill children when the parent process dies, maybe that's related? 
(To make it do that prctl(2) would need to be used w/
PR_SET_PDEATHSIG.)


On Tue, Apr 02, 2024 at 06:53:39AM +, gil...@poolp.org wrote:
> April 2, 2024 4:47 AM, and...@tekrealm.net wrote:
>
>> What signals a termination for smtpd filters?
>>
>> I'm using the code at
>> https://github.com/Beutlin/howto-opensmtpd-filters-and-reports,
>> Which works great, except for when smtpd gets shutdown. The script 
>> continues to run and consumes up to 100% cpu time, while keeping the 
>> smtpd parent? process running.
>>
>> I've tried adding a SIGTERM handler to the code which didn't work, as 
>> well as I saw mentioned that the filter should exit on EOF, so I 
>> tried wrapping
>> parser.dispatch() in
>> a try/except EOFError and using sys.exit. That didn't work either.
>>
>> I've read smtpd-filters, and looked at various other filters and I am 
>> not understanding what tells the filter to shutdown.
>>
>
> The filter is connected to smtpd through its stdin, so it can 
> terminate when there's an EOF on stdin.
>
> This is the proper way to do it and how all filters I wrote work but 
> maybe a bug has crawled in the handling of filter termination and it 
> went unnoticed, I don´t think I ever terminated smtpd in years besides system 
> restarts.
>
> What system are you running on ?
>

Re: [PATCH] DSNs to follow more closely RFCs

[gilles]

April 2, 2024 6:00 PM, "Tassilo Philipp"  wrote:

> Hi,
> 
> Find attached the first stab at a final patch making generated bounce mails 
> follow more closely the
> RFCs 3461, 3464 and 6522. The attached file includes the patch from my 
> previous mail in this
> thread.
> 
> The patch is based on opensmtp 7.5.0rc1 (w/ the additional patch in the rc1 
> announcement thread on
> this ml).
> 
> It does, in short:
> 
> - uses the correct content type(s) for DSNs, as specified in RFC3464 and
> RFC6522
> 
> - adds xtext_decode() utility func (following the style/interface of the
> base64_decode() utility func)
> 
> - extends the data structures of the bounce message and envelope, as
> necesary, to write the required fields outlined by RFC3461 and RFC3464
> into the machine readable sub mime part, namely, per-message field:
> 
> * Original-Envelope-Id: (required if ENVID= was used, see RFC3461)
> 
> and per recipiend fields:
> 
> * Original-Recipient: (required if ORCPT= was used, see RFC3461)
> * Arrival-Date: (optional, but added it while at it...)
> * Diagnostic-Code: (optional, but added it while at it...)
> 
> - adds a check whether the SMTP ENVID= param is valid xtext (RFC3461)
> 
> - minor: removes a space in already set Final-Recipient: field
> (following more closely the example layout from RFC3464)
> 
> One thing I wasn't sure about what to do is *where* to handle the xtext 
> decoding of the ENVID= and
> ORCPT= SMTP params. Right now the SMTP handling part just considers them 
> "opaque text", as they are
> just handed down the relays, unmodified. When copying those into a DSN, they 
> must be decoded,
> though, and the decoded result is considered being printable US-ASCII. >From 
> RFC3461 4.2 about
> ORCPT:
> 
> `Due to limitations in the Delivery Status Notification format, the
> value of the original recipient address prior to encoding as "xtext"
> MUST consist entirely of printable (graphic and white space)
> characters from the US-ASCII repertoire.`
> 
> A functional identical wording is used in 4.4 for the ENVID= param.
> 
> The attached patch keeps the SMTP behaviour to just treat those params as 
> opaque strings, but
> checks if the decoded part is US-ASCII when generating a bounce - and if it's 
> not, doesn't write it
> to the respective DSN field(s).
> 
> I think the SMTP handling might be the better place to check for that, and 
> refuse such SMTP params
> outright, maybe?
> 
> Thanks
> 

Can you please inline the diff to your mail ?

Re: How to terminate smtpd filters?

[Tassilo Philipp]

I agree with Gilles, your filter should react on stdin closing, but not 
sure how your filter is set up.


Also, just a guess... are you running smtpd on Linux?

Linux doesn't kill children when the parent process dies, maybe that's
related? (To make it do that prctl(2) would need to be used w/
PR_SET_PDEATHSIG.)


On Tue, Apr 02, 2024 at 06:53:39AM +, gil...@poolp.org wrote:

April 2, 2024 4:47 AM, and...@tekrealm.net wrote:


What signals a termination for smtpd filters?

I'm using the code at 
https://github.com/Beutlin/howto-opensmtpd-filters-and-reports, 
Which works great, except for when smtpd gets shutdown. The script continues 
to run and
consumes up to 100% cpu time, while keeping the smtpd parent? process 
running.


I've tried adding a SIGTERM handler to the code which didn't work, as well 
as I saw
mentioned that the filter should exit on EOF, so I tried wrapping 
parser.dispatch() in

a try/except EOFError and using sys.exit. That didn't work either.

I've read smtpd-filters, and looked at various other filters and I am not 
understanding

what tells the filter to shutdown.



The filter is connected to smtpd through its stdin, so it can terminate when 
there's an EOF on stdin.


This is the proper way to do it and how all filters I wrote work but maybe a 
bug has crawled in the handling of filter termination and it went unnoticed, 
I don´t think I ever terminated smtpd in years besides system restarts.


What system are you running on ?

Re: How to terminate smtpd filters?

[gilles]

April 2, 2024 4:47 AM, and...@tekrealm.net wrote:

> What signals a termination for smtpd filters?
> 
> I'm using the code at
> https://github.com/Beutlin/howto-opensmtpd-filters-and-reports,
> Which works great, except for when smtpd gets shutdown. The script continues
> to run and 
> consumes up to 100% cpu time, while keeping the smtpd parent? process
> running.
> 
> I've tried adding a SIGTERM handler to the code which didn't work, as well
> as I saw 
> mentioned that the filter should exit on EOF, so I tried wrapping
> parser.dispatch() in
> a try/except EOFError and using sys.exit. That didn't work either.
> 
> I've read smtpd-filters, and looked at various other filters and I am not
> understanding 
> what tells the filter to shutdown.
> 

The filter is connected to smtpd through its stdin, so it can terminate when
there's an EOF on stdin.

This is the proper way to do it and how all filters I wrote work but maybe a
bug has crawled in the handling of filter termination and it went unnoticed,
I don´t think I ever terminated smtpd in years besides system restarts.

What system are you running on ?

Re: [PATCH] Re: OpenSMTPD 7.5.0 RC1

[Tassilo Philipp]

Perfect, thanks! You are right, this didn't copy anything. I just 
noticed it now, b/c I need that param for the DSN work I'm currently 
working on.


And sorry for not spotting this earlier, when I tested that final 
version of the ORCPT patch, a while ago.


:)


On Wed, Mar 20, 2024 at 07:08:40PM +0100, Omar Polo wrote:

On 2024/03/20 17:36:01 +0100, Tassilo Philipp  
wrote:

Hi,

while working on the DSN patches mentioned in another thread, I came 
across an oversight in the final ORCPT patch that will be part of 7.5.0.


Find the patch attached - IMHO, this patch should make it into 7.5.0, as 
it's fixing an error writing to a wrong buffer, which could be abused 
(from a cursory review it looks safe as that wrong destination buffer 
big enough, but I haven't checked it thoroughly).


Thanks for spotting!  This has been committed and will be included in 
7.5 (both OpenBSD and -portable.)


I don't think this can be abused since the dsn_orcpt buffer is zeroed, 
so we're just going to truncate `opt', that we won't look at it again. 
In any case, this had to be fixed.

Re: [PATCH] Re: OpenSMTPD 7.5.0 RC1

[Omar Polo]

On 2024/03/20 17:36:01 +0100, Tassilo Philipp  
wrote:
> Hi,
> 
> while working on the DSN patches mentioned in another thread, I came 
> across an oversight in the final ORCPT patch that will be part of 7.5.0.
> 
> Find the patch attached - IMHO, this patch should make it into 7.5.0, as 
> it's fixing an error writing to a wrong buffer, which could be abused 
> (from a cursory review it looks safe as that wrong destination buffer 
> big enough, but I haven't checked it thoroughly).

Thanks for spotting!  This has been committed and will be included in
7.5 (both OpenBSD and -portable.)

I don't think this can be abused since the dsn_orcpt buffer is zeroed,
so we're just going to truncate `opt', that we won't look at it again.
In any case, this had to be fixed.

[PATCH] Re: OpenSMTPD 7.5.0 RC1

[Tassilo Philipp]

Hi,

while working on the DSN patches mentioned in another thread, I came 
across an oversight in the final ORCPT patch that will be part of 7.5.0.


Find the patch attached - IMHO, this patch should make it into 7.5.0, as 
it's fixing an error writing to a wrong buffer, which could be abused 
(from a cursory review it looks safe as that wrong destination buffer 
big enough, but I haven't checked it thoroughly).



On Fri, Mar 08, 2024 at 11:14:54AM +0100, Omar Polo wrote:
Today we're happy to announce the first release candidate for 
OpenSMTPD 7.5.0 that includes the latest developments on OpenBSD, 
briefly summarized below.  The 7.5.0 stable release will follow the 
OpenBSD release schedule and so will be available in around a month. 
It is our hope that the community will help testing this first 
release candidate and report any issue found.


Tarballs are available on the official mirror or on GitHub:

   https://opensmtpd.org/archives/opensmtpd-7.5.0rc1.tar.gz
   https://github.com/OpenSMTPD/OpenSMTPD/releases/tag/7.5.0rc1

Verify the tarball with signify(1) and the usual public key:

   https://opensmtpd.org/archives/opensmtpd-7.5.0rc1.sum.sig
   https://opensmtpd.org/archives/opensmtpd-20181026.pub


Changelog:

- run LMTP deliveires as the recipient user (again).
- do not execute commands from root's .forward file, nor allow expanding. 
- when an alternate delivery user is provided for a dispatcher, skip
 other users forward files. 
- reject invalid headers that start with blanks.

- relax ORCPT syntax validation.
- use smtpd' table parser in makemap(8) too.
- fix and improve the table(5) file format documentation.
- fixed handling of escaping inside quotes in From, To and Cc headers. 
- fix table lookups of IPv6 address.

- allow to use a key-pair table on various match constraints where only
 list tables were previously allowed. 
- allow inline tables and filter to span over multiple lines.
- enable DSN (Delivery Status Notification) for the implicit socket too. 
- add the `no-dsn' option to `listen on socket' too.


OpenSMTPD-portable specific changes:

- re-add ASR_IPV4_BEFORE_IPV6 compile-time knob to prefer connecting
 to IPv6 instead of IPv4. 
- update asr(3) and imsg with OpenBSD.

- configure: readd -R usage on NetBSD mistakenly dropped in previous
 release.



Thanks,

Omar Polo

--- ./usr.sbin/smtpd/smtp_session.c.orig2024-03-20 17:27:12.280717000 
+0100
+++ ./usr.sbin/smtpd/smtp_session.c 2024-03-20 17:27:18.240157000 +0100
@@ -2496,7 +2496,7 @@
 
if ((p = strchr(opt, ';')) == NULL ||
!valid_xtext(p + 1) ||
-   strlcpy(opt, tx->evp.dsn_orcpt, len) >= len) {
+   strlcpy(tx->evp.dsn_orcpt, opt, len) >= len) {
smtp_reply(tx->session,
"553 ORCPT address syntax error");
return;

Re: DSN message format: shouldn't this use multipart/report (as of RFC3464)

[Tassilo Philipp]

Alright, find attached a first patch, fixing up some content-type 
headers, as outlined by RFC3464 and RFC6522 - in detail:


The patch's first hunk follows RFC3464, which specifies that a DSN 
should have a top-level type of "multipart/report" with a parameter 
"report-type=delivery-status"; the actual format is described in 
RFC6522, and is specified having two or three sub mime parts, a human 
readable message, a machine parsable part with content-type 
"message/delivery-status" and an optional 3rd part of either 
"text/rfc822-headers" or "message/rfc822".


The latter is part of the second hunk of the patch, b/c 
"text/rfc822-headers" was used in any case, even if the full message was 
returned in the DSN.


Also, the end of the second hunk removes a check, which I think is 
unintuitive to begin with, but unsure. Basically, it only returned the 
headers for NOTIFY=SUCCESS DSNs when RET=HDRS was also set (explicitly 
or implicitly).

Here's the section from RFC3461:

When the value of the RET parameter is FULL, the full
message SHOULD be returned for any DSN which conveys notification of
delivery failure.  (However, if the length of the message is greater
than some implementation-specified length, the MTA MAY return only
the headers even if the RET parameter specified FULL.)  If a DSN
contains no notifications of delivery failure, the MTA SHOULD return
only the headers.

The original code does what the last line implies, but only when 
RET=HDRS is set, meaning it ignores it for anything but NOTIFY=SUCCESS, 
and returns always the full message.


I'm not sure what would be best to do here, all in all the RFC says 
'SHOULD'... either way, the check there should reflect the same logic 
used in the if...else... block of the second hunk, which is what the 
patch shoots for. I chose to keep it simple and simply do what RET= asks 
for.  So, if the original logic is kept, the second hunk's if...else... 
block would need an additional "s->msg->bounce.type == B_DELIVERED" 
check.


I tested the patch with different combinations of the RET= and NOTIFY= 
parameters, and so far it seems to work fine.


PS: I'm working on related other patches, at the moment, which I'll mail 
when they are done, namely adding a "Original-Envelope-ID" header in the 
DSN when the ENVID= param was present, as well as "Original-Recipient" 
for any ORCPT= param. Those are specified in RFC3461 section 6.3., but 
they are a bit more involved as the params need to be decoded and 
recoded, and I just haven't found the time, yet.


Thanks!




On Wed, Mar 13, 2024 at 12:04:24PM +0100, Tassilo Philipp wrote:
Ok, will get busy... I also noticed two other issues, one related to 
ENVID= (should be generated for DSNs), and some data in the DSN's 
message/delivery-status parts, that must be generated according to eh 
RFC, when ENVID= or ORCPT= are present, which are not, currently. Will 
look at those, as well. Might take a few days, though... will keep you 
posted.


Cheers

On Wed, Mar 13, 2024 at 11:00:51AM +, gil...@poolp.org wrote:

March 13, 2024 10:31 AM, "Tassilo Philipp"  wrote:


Hello,

I noticed that DSNs generated by OpenSMTPd use "Content-Type: 
multipart/mixed", instead of "Content-Type: multipart/report", as 
defined by RFC3461 (and described in RFC3464 and RFC3462). I 
wonder if there's a reason for that?


I haven only done a cursory review of the actual multiparts 
themselves, but they seem to (mostly) follow the mentioned RFCs 
with for example "Content-Type: text/rfc822-headers". However, if 
RET=FULL, the content type should be IMHO only "message/rfc822" 
and not "text/rfc822-headers", the latter seems to be currently 
used for both, RET=HDRS and RET=FULL. Need to read up on it more 
to get a clearer picture, though, I just started digging into it.


Either way... I think the RFCs should be followed, want me to prepare a patch?



Yes please, patch and RFC reference so this can be checked too

Thanks,


--- ./usr.sbin/smtpd/bounce.c
+++ ./usr.sbin/smtpd/bounce.c
@@ -452,7 +452,8 @@
 		"To: %s\r\n"
 		"Date: %s\r\n"
 		"MIME-Version: 1.0\r\n"
-		"Content-Type: multipart/mixed;"
+		"Content-Type: multipart/report;"
+			"report-type=delivery-status;"
 		"boundary=\"%16" PRIu64 "/%s\"\r\n"
 		"\r\n"
 		"This is a MIME-encapsulated message.\r\n"
@@ -534,19 +535,27 @@
 		break;
 
 	case BOUNCE_DATA_MESSAGE:
-		io_xprintf(s->io,
-		"--%16" PRIu64 "/%s\r\n"
-		"Content-Description: Message headers\r\n"
-		"Content-Type: text/rfc822-headers\r\n"
-		"\r\n",
-		s->boundary, s->smtpname);
+		if(s->msg->bounce.dsn_ret == DSN_RETHDRS) {
+			io_xprintf(s->io,
+			"--%16" PRIu64 "/%s\r\n"
+			"Content-Description: Message headers\r\n"
+			"Content-Type: text/rfc822-headers\r\n"
+			"\r\n",
+			s->boundary, s->smtpname);
+		} else {
+			io_xprintf(s->io,
+			"--%16" PRIu64 "/%s\r\n"
+			"Content-Description: Full message\r\n"
+			

Re: OpenSMTPD 7.5.0 RC1

[Richard Narron]

   The new OpenSMTPD 7.5.0rc1 works well with LibreSSL on Slackware64
Linux.

   My compile script uses CFLAGS and LDFLAGS like this:

   CFLAGS="...  -I/usr/include/libressl" \
   LDFLAGS="-L/usr/lib64/libressl -lcrypto -lssl \
-Wl,-rpath=/usr/lib64/libressl" \
   ./configure \
 ...

   It solves the git problem 1188,
"configure: error: Your LibreSSL headers do not match your library".

   And it works even when I don't have LibreSSL installed and just have
OpenSSL 1 installed.

   This version works on 32-bit Slackware:

   CFLAGS="...  -I/usr/include/libressl" \
   LDFLAGS="-L/usr/lib/libressl -lcrypto -lssl \
-Wl,-rpath=/usr/lib/libressl" \
   ./configure \
 ...


Richard Narron

Re: Wrote a blogpost on OpenSMTPD mailrelay - feedback appreciated

[Bruno Flückiger]

On 11.03.2024 09:03, Gilles CHEHADE wrote:
Since people are sharing posts / articles, if others have written such 
articles feel free to share in this thread, I’m curious :-)





You can find mine here: https://www.bsdhowto.ch/mxpop3.html

I update it every now and then, mostly when I figure out an improvement 
or find a solution to a new task.


Cheers,
Bruno

Re: DSN message format: shouldn't this use multipart/report (as of RFC3464)

[Tassilo Philipp]

Ok, will get busy... I also noticed two other issues, one related to 
ENVID= (should be generated for DSNs), and some data in the DSN's 
message/delivery-status parts, that must be generated according to eh 
RFC, when ENVID= or ORCPT= are present, which are not, currently. Will 
look at those, as well. Might take a few days, though... will keep you 
posted.


Cheers

On Wed, Mar 13, 2024 at 11:00:51AM +, gil...@poolp.org wrote:

March 13, 2024 10:31 AM, "Tassilo Philipp"  wrote:


Hello,

I noticed that DSNs generated by OpenSMTPd use "Content-Type: multipart/mixed", instead of 
"Content-Type: multipart/report", as defined by RFC3461 (and described in RFC3464 and RFC3462). I 
wonder if there's a reason for that?


I haven only done a cursory review of the actual multiparts themselves, but they seem to (mostly) 
follow the mentioned RFCs with for example "Content-Type: text/rfc822-headers". However, if 
RET=FULL, the content type should be IMHO only "message/rfc822" and not "text/rfc822-headers", the 
latter seems to be currently used for both, RET=HDRS and RET=FULL. 
Need to read up on it more to get a clearer picture, though, I just started digging into it.


Either way... I think the RFCs should be followed, want me to prepare a patch?



Yes please, patch and RFC reference so this can be checked too

Thanks,

Re: DSN message format: shouldn't this use multipart/report (as of RFC3464)

[gilles]

March 13, 2024 10:31 AM, "Tassilo Philipp"  wrote:

> Hello,
> 
> I noticed that DSNs generated by OpenSMTPd use "Content-Type: 
> multipart/mixed", instead of
> "Content-Type: multipart/report", as defined by RFC3461 (and described in 
> RFC3464 and RFC3462). I
> wonder if there's a reason for that?
> 
> I haven only done a cursory review of the actual multiparts themselves, but 
> they seem to (mostly)
> follow the mentioned RFCs with for example "Content-Type: 
> text/rfc822-headers". However, if
> RET=FULL, the content type should be IMHO only "message/rfc822" and not 
> "text/rfc822-headers", the
> latter seems to be currently used for both, RET=HDRS and RET=FULL. 
> Need to read up on it more to get a clearer picture, though, I just started 
> digging into it.
> 
> Either way... I think the RFCs should be followed, want me to prepare a patch?
> 

Yes please, patch and RFC reference so this can be checked too

Thanks,

Re: Restricting submission username to match authenticated username

[Rodolphe Bréard]

Hi!

On 13/03/2024 08:37, SeraphJACK wrote:
I am wondering is there any solution to reject submissions whose sender 
name does not match the authenticated username?




I think you are looking for this:
listen on [...] senders  masquerade

As stated in smtpd.conf:
  Look up the authenticated user in the users mapping table to find
  the email addresses that user is allowed to submit mail as. In
  addition, if the masquerade option is provided, the From header is
  rewritten to match the sender provided in the SMTP session.

https://man.archlinux.org/man/smtpd.conf.5#senders

--
Rodolphe Bréard
https://rodolphe.breard.tf/
B229 CCD5 6900 91E7 D5D6  189F 09BC 23A1 D556 2635

Re: match from mail-from reject not working

[Simon Hoffmann]

Thomas Bohl wrote:

> > 
> > match from mail-from  reject
> 
> That line doesn't have a for option, so "for local" is implied.
> 
> match from any for any mail-from  reject
> 
> should do the trick.


Yes it did! Thank you very much. I completely forgot that not specifying for 
means
for local instead of for any.

Sometimes it's just the simple things... :)
> 
> 
> > However, if i use telnet/openssl s_client to connect to the server, I get 
> > an OK in
> > response to MAIL FROM: and can state RCPT TO and 
> > DATA without
> > any problems.
> 
> The reject (550 Invalid recipient) will happen after RCPT TO. (Earlier is
> only possible with a filter.) That is good and bad. The bad side is that the
> error message is "wrong", which makes stuff harder to debug. The good side
> of this behaviour is that it signals "Invalid recipient" to an adversary.

yeah, w/ regards to the spammers, this might actually not be as bad. :)
If I don't like it like that I can still use the filter approach.

Thanks!

Cheers, 

Simon



signature.asc
Description: PGP signature

Re: match from mail-from reject not working

[Simon Hoffmann]

Otto Retter wrote:

> Simon,
> 
> I have similar functionality working with a filter. Have you tried
> using a filter for this?

No, I have not yet tried that. I wanted to try the "simpler" solution first. :)

> 
> Here are some anonymized snippets from my smtpd.conf:
> 
> ```
> table bad_guys file:/etc/mail/bad_guys
> filter "bad_guys" phase mail-from match mail-from regex  reject
> "550 Bad Guys"
> listen on ... filter { ..., "bad_guys", ... } tag PORT_25
> ```

Thanks for the example! The filter might actually be nice to send the spammers a
message back :)

I have found the solution now, but I will keep your filter example in mind. 

Thanks!


Cheers, 

Simon


signature.asc
Description: PGP signature

Re: Wrote a blogpost on OpenSMTPD mailrelay - feedback appreciated

[Jarod G.]

No, for a lot of reasons. (ethical and legals ones)

If you want something to translate the page, you can always use a 
browser extension. (DeepL, Google Translate, etc...)


PS : Your DMARC policy wants a valid DKIM, however i don't see DKIM 
signatures in your emails.


- Jarod

Le 11/03/2024 à 19:32, Peter Thurner | Blunix GmbH a écrit :

Can you add a google translation button?



On Mon, Mar 11, 2024 at 06:34:04PM +0100, Jarod G. wrote:

Hey!

I got this one i wrote in 2021 and kept updated ever since : 
https://blog.gamindustri.fr/setup-un-serveur-mail-avec-opensmtpd-dovecot-rspamd-et-postgresql-sur-openbsd/

- Jarod

Le 11/03/2024 à 09:03, Gilles CHEHADE a écrit :

Since people are sharing posts / articles, if others have written such articles 
feel free to share in this thread, I’m curious :-)



On 8 Mar 2024, at 22:53, Peter Thurner | Blunix GmbH  
wrote:

Hello misc@opensmtpd.org,

I just wrote a blogpost that explains how to configure OpenSMTPD as a mailrelay 
for (Debian based) servers.

I wanted to link it here in the hopes that somebody could find any mistakes I 
might have possibly made. Any feedback would be highly appreciated :)

Here is the link: 
https://www.blunix.com/blog/secure-smtp-email-relay-on-debian-and-ubuntu-with-opensmtpd-instead-of-postfix.html


with kind regards,

Peter Thurner

CEO Blunix GmbH

--

Blunix GmbH
Glogauer Straße 21
10999 Berlin
Germany

Web: https://www.blunix.com


with kind regards,

Peter Thurner

CEO Blunix GmbH

--

Blunix GmbH
Glogauer Straße 21
10999 Berlin
Germany

Web: https://www.blunix.com

Re: match from mail-from reject not working

[Thomas Bohl]

match from mail-from  reject


That line doesn't have a for option, so "for local" is implied.

match from any for any mail-from  reject

should do the trick.



However, if i use telnet/openssl s_client to connect to the server, I get an OK 
in
response to MAIL FROM: and can state RCPT TO and DATA 
without
any problems.


The reject (550 Invalid recipient) will happen after RCPT TO. (Earlier 
is only possible with a filter.) That is good and bad. The bad side is 
that the error message is "wrong", which makes stuff harder to debug. 
The good side of this behaviour is that it signals "Invalid recipient" 
to an adversary.


hth

Re: Wrote a blogpost on OpenSMTPD mailrelay - feedback appreciated

[Peter Thurner | Blunix GmbH]

Love it! Will write another blogposts soon :))


On Mon, Mar 11, 2024 at 09:20:04PM +, Simon Harrison wrote:
> On Mon, 11 Mar 2024 13:59:17 +
> gil...@poolp.org wrote:
> 
> > I created a Wiki page on the public repository for OpenSMTPD:
> > 
> > https://github.com/OpenSMTPD/OpenSMTPD/wiki/OpenSMTPD-articles-and-posts
> > 
> > List to be completed ;-)
> > 
> 
> Great idea! Might even inspire users to create their own to be added to
> the list. Just a suggestion: maybe we could collect some configs with
> comments for achieving certain goals:
> 
> 1. How do I setup opensmtpd for outgoing mail only?

Thats excatly what my post 
(https://www.blunix.com/blog/secure-smtp-email-relay-on-debian-and-ubuntu-with-opensmtpd-instead-of-postfix.html)
 was written for - it focuses on servers running webapps that send out booking 
confirmations, password resets, and so on. works for your local raspberry pi 
too.


> 2. What is a backup MX server and how do I set one up?
> 3. How do I connect opensmtpd to my IMAP/POP3 server?

:thumbsup:


> 
> etc.
> 
> The now neglected FAQ page that many software sites used to have...
> 
> 

Re: Wrote a blogpost on OpenSMTPD mailrelay - feedback appreciated

[Simon Harrison]

On Mon, 11 Mar 2024 13:59:17 +
gil...@poolp.org wrote:

> I created a Wiki page on the public repository for OpenSMTPD:
> 
> https://github.com/OpenSMTPD/OpenSMTPD/wiki/OpenSMTPD-articles-and-posts
> 
> List to be completed ;-)
> 

Great idea! Might even inspire users to create their own to be added to
the list. Just a suggestion: maybe we could collect some configs with
comments for achieving certain goals:

1. How do I setup opensmtpd for outgoing mail only?
2. What is a backup MX server and how do I set one up?
3. How do I connect opensmtpd to my IMAP/POP3 server?

etc.

The now neglected FAQ page that many software sites used to have...

Re: Wrote a blogpost on OpenSMTPD mailrelay - feedback appreciated

[Peter Thurner | Blunix GmbH]

Can you add a google translation button?



On Mon, Mar 11, 2024 at 06:34:04PM +0100, Jarod G. wrote:
> Hey!
> 
> I got this one i wrote in 2021 and kept updated ever since : 
> https://blog.gamindustri.fr/setup-un-serveur-mail-avec-opensmtpd-dovecot-rspamd-et-postgresql-sur-openbsd/
> 
> - Jarod
> 
> Le 11/03/2024 à 09:03, Gilles CHEHADE a écrit :
> > Since people are sharing posts / articles, if others have written such 
> > articles feel free to share in this thread, I’m curious :-)
> > 
> > 
> > > On 8 Mar 2024, at 22:53, Peter Thurner | Blunix GmbH 
> > >  wrote:
> > > 
> > > Hello misc@opensmtpd.org,
> > > 
> > > I just wrote a blogpost that explains how to configure OpenSMTPD as a 
> > > mailrelay for (Debian based) servers.
> > > 
> > > I wanted to link it here in the hopes that somebody could find any 
> > > mistakes I might have possibly made. Any feedback would be highly 
> > > appreciated :)
> > > 
> > > Here is the link: 
> > > https://www.blunix.com/blog/secure-smtp-email-relay-on-debian-and-ubuntu-with-opensmtpd-instead-of-postfix.html
> > > 
> > > 
> > > with kind regards,
> > > 
> > > Peter Thurner
> > > 
> > > CEO Blunix GmbH
> > > 
> > > --
> > > 
> > > Blunix GmbH
> > > Glogauer Straße 21
> > > 10999 Berlin
> > > Germany
> > > 
> > > Web: https://www.blunix.com
> > > 
> > 
> 

with kind regards,

Peter Thurner

CEO Blunix GmbH

--

Blunix GmbH
Glogauer Straße 21
10999 Berlin
Germany

Web: https://www.blunix.com