Re: [diff] selectable curves in smtpd ?

2023-08-12 Thread gilles
August 12, 2023 4:34 PM, "Theo Buehler" wrote: > On Sat, Aug 12, 2023 at 02:29:45PM +, gil...@poolp.org wrote: > >> Hello, >> >> Someone asked about selectable curves in the OpenSMTPD portable tracker, >> and it turns out I had a diff for that among a few others. > > Why do they need

[diff] selectable curves in smtpd ?

2023-08-12 Thread gilles
Hello, Someone asked about selectable curves in the OpenSMTPD portable tracker, and it turns out I had a diff for that among a few others. The diff below adds support for the curves keyword in listener and relay directives, allowing to specify a curve string suitable for

Re: smtpd: allow arguments on NOOP

2023-06-23 Thread gilles
June 23, 2023 11:58 AM, "Omar Polo" wrote: > another diff from the -portable repo: > > https://github.com/OpenSMTPD/OpenSMTPD/pull/1150 > > per rfc-5321 § 4.1.1.9 the NOOP command allows optionally one argument > that we SHOULD ignore. > > The original diff set the check function in the

Re: smtpd-filters: swap link-auth fields

2023-06-14 Thread Gilles Chehade
nce this is triggered by the `auth login' command, anyone could > send a user with a '|' and, depending on the filter used, make smtpd > exit. (if the filter dies, smtpd does too) > > This was reported on the OpenSMTPD-portable github repository with > Gilles' opensmtpd-filter-rspamd:

Re: smtpd: nits to reduce the diff with -portable

2023-05-15 Thread gilles
May 15, 2023 3:34 PM, "Todd C. Miller" wrote: > On Mon, 15 May 2023 13:54:35 +0200, Omar Polo wrote: > >> almost always (cast)var. I've adjusted the spacing in the line I was >> touching, grepping for common types I could only find one instance of >> a '(long long) src' in envelope.c which I'm

Re: smtpd: move authentication to table backends

2021-10-11 Thread gilles
nst char *value) K_SOURCE match on a list, key is not set: table_match(table, K_SOURCE, NULL, "192.168.0.1"); K_CREDENTIALS match on a mapping, key is used to resolve: table_match(table, K_CREDENTIALS, "gilles", "ilovecandies"); This is just an idea, but I still think this should be done after proc-exec :-)

Re: smtpd: move authentication to table backends

2021-10-11 Thread gilles
October 8, 2021 11:34 PM, "aisha" wrote: > Hi all, > I am still working on the table-procexec for opensmtpd > and while there, I was thinking of how to do authentication > using LDAP, which the current table-ldap from ports does not > support. > The primary reason for that, I believe, is that

Re: smtpd: srs and ruleset evaluation

2021-09-22 Thread Gilles CHEHADE
Hello, As discussed, this looks correct to me > On 22 Sep 2021, at 15:46, Eric Faurot wrote: > > Hi. > > A user reported that decoded SRS addresses are not correctly evaluated > against the ruleset. That's because the ruleset always matches against > the expanded address ("dest") and not the

Re: [diff] src/usr.sbin/smtpd: table_diff lacks some lookup kinds

2021-09-01 Thread gilles
August 29, 2021 10:16 PM, gil...@poolp.org wrote: > Hellow, > > The K_STRING and K_REGEX lookup kinds are missing from table_db even though > nothing prevents > them from working technically. The following diff is enough to allow db > tables to be used on > regex or string contexts. > >

[diff] src/usr.sbin/smtpd: table_diff lacks some lookup kinds

2021-08-29 Thread gilles
Hellow, The K_STRING and K_REGEX lookup kinds are missing from table_db even though nothing prevents them from working technically. The following diff is enough to allow db tables to be used on regex or string contexts. Index: table_db.c

Re: DANE in libressl?

2021-08-29 Thread Gilles CHEHADE
> On 29 Aug 2021, at 16:14, Peter J. Philipp wrote: > > On Sun, Aug 29, 2021 at 07:16:20AM -0600, Theo de Raadt wrote: >> Is there a strong reason why this has to be in that specific library? > > Not really. I did see gnutls has dane functions and openssl has them too. > I can stick to just

Re: add table_procexec in smtpd

2021-06-22 Thread gilles
June 22, 2021 11:14 PM, "Aisha Tammy" wrote: >> [...] >> >> WRT to handshake, it has multiple uses ranging from ensuring the addons get >> their configuration >> from the daemon to synchronising the daemon start with addons readiness. >> Remember, we didn’t have this with filters and realised

Re: add table_procexec in smtpd

2021-06-12 Thread Gilles CHEHADE
Re-sending, I forgot to cc: aisha & tech: > On 12 Jun 2021, at 22:47, Gilles CHEHADE wrote: > >> >> On 12 Jun 2021, at 15:15, Eric Faurot wrote: >> >> On Wed, Jun 09, 2021 at 05:41:36PM -0400, Aisha Tammy wrote: >>> Hi, >>> Here is

Re: add table_procexec in smtpd

2021-06-12 Thread Gilles CHEHADE
> On 12 Jun 2021, at 18:57, Aisha Tammy wrote: > > On 6/12/21 9:15 AM, Eric Faurot wrote: >> On Wed, Jun 09, 2021 at 05:41:36PM -0400, Aisha Tammy wrote: >>> Hi, >>> Here is the updated diff, which removes table_proc and adds >>> table_procexec as the default backend when no backend name

Re: add table_procexec in smtpd

2021-06-09 Thread Gilles CHEHADE
> On 9 Jun 2021, at 17:13, Aisha Tammy wrote: > > > > On 6/9/21 10:34 AM, Gilles CHEHADE wrote: >> >>> On 9 Jun 2021, at 15:47, Aisha Tammy wrote: >>> >>> On 6/9/21 5:19 AM, Gilles CHEHADE wrote: >>>> Hi, >>>>

Re: add table_procexec in smtpd

2021-06-09 Thread Gilles CHEHADE
> On 9 Jun 2021, at 15:47, Aisha Tammy wrote: > > On 6/9/21 5:19 AM, Gilles CHEHADE wrote: >> Hi, >> >> I wrote table_procexec (despite the copyright which I copy-pasted and forgot >> to replace author) so just providing a bit of insight: > Ah, I did

Re: add table_procexec in smtpd

2021-06-09 Thread Gilles CHEHADE
” table, which means that you have no way to provide the new table with a configuration for itself. Gilles > On 8 Jun 2021, at 23:04, Aisha Tammy wrote: > > Hi, > I've attached a slightly updated patch for the procexec. > Ping for someone to take a look :) > > Chee

Re: smtpd: use libtls

2021-02-05 Thread Gilles CHEHADE
Been running it for a few days, no regressions so far > On 5 Feb 2021, at 09:35, Eric Faurot wrote: > > No much report so far. > Anybody had a chance to test this? > Here is the same diff again with manpage update this time. > > Eric. > > Index: ca.c >

Re: smtpd: use libtls

2021-01-27 Thread gilles
January 27, 2021 9:47 AM, "Lauri Tirkkonen" wrote: > On Wed, Jan 27 2021 09:36:31 +0100, Eric Faurot wrote: > >> There has been a plan for some time now to make smtpd use libtls >> instead of openssl. Recent changes in libtls allow to move forward >> with this. Here is a diff to start the

Re: vacation.1: correct .forward file example

2021-01-21 Thread gilles
January 21, 2021 11:45 AM, gil...@poolp.org wrote: > January 21, 2021 11:25 AM, "Claus Assmann" wrote: > >> On Thu, Jan 21, 2021, Martin Vahlensieck wrote: >> >>> I think the backslash at the beginning of the line is an error. >> >> Why? Does it fail when used as described? >> >>> -\eeric,

Re: vacation.1: correct .forward file example

2021-01-21 Thread gilles
January 21, 2021 11:25 AM, "Claus Assmann" wrote: > On Thu, Jan 21, 2021, Martin Vahlensieck wrote: > >> I think the backslash at the beginning of the line is an error. > > Why? Does it fail when used as described? > >> -\eeric, "|/usr/bin/vacation -a allman eric" > > Originally this was to

Re: [diff] src/usr.sbin/smtpd: change process names

2020-12-27 Thread gilles
it's slightly different: ca is for "crypto agent" unsure if there's really an interest in renaming internally, furthermore there's a separate crypto API for encrypted queue so not distinguishing between crypto api and crypto agent might be confusing. Gilles December 27, 20

[diff] src/usr.sbin/smtpd: plug a memory leak in regex lookups

2020-12-23 Thread Gilles CHEHADE
Hello, The following diff plugs a memory leak in regex lookups. Cheers, diff --git a/usr.sbin/smtpd/table.c b/usr.sbin/smtpd/table.c index 4691..d1578403 100644 --- a/usr.sbin/smtpd/table.c +++ b/usr.sbin/smtpd/table.c @@ -470,6 +470,7 @@ table_regex_match(const char *string, const char

Re: [diff] src/usr.sbin/smtpd: add a forward-file option

2020-12-20 Thread Gilles CHEHADE
> On 20 Dec 2020, at 18:15, Chris Bennett > wrote: > > On Sun, Dec 20, 2020 at 09:51:35AM +0100, Gilles CHEHADE wrote: >> >> >>> On 20 Dec 2020, at 07:13, Sebastien Marie wrote: >>> >>> On Sat, Dec 19, 2020 at 10:36:32PM +, gil.

Re: [diff] usr.sbin/smtpd: fix event handling upon exit

2020-12-20 Thread Gilles CHEHADE
Ping ? > On 14 Dec 2020, at 11:34, Gilles Chehade wrote: > > Hello, > > Upon termination, the parent process will call parent_shutdown() which will > in turn call mproc_clear() to properly terminate IPC with child processes. > > In mproc_clear(), event_del() is calle

Re: [diff] src/usr.sbin/smtpd: add a forward-file option

2020-12-20 Thread Gilles CHEHADE
handling it is complex. I really want to emphasise that I don’t suggest off-by-default on OpenBSD but just making the feature explicit. The default smtpd.conf could still have the option to retain the default behaviour. > Regarding the option itself, if I recall correctly some descriptions &

Re: [diff] src/usr.sbin/smtpd: add a forward-file option

2020-12-20 Thread Gilles CHEHADE
> On 20 Dec 2020, at 10:03, Gilles CHEHADE wrote: > > >> On 20 Dec 2020, at 07:19, Theo de Raadt wrote: >> >> There are thousands of people with smtpd configurations, and sysmerge >> is not going to handle this. >> >> We cannot expect the

Re: [diff] src/usr.sbin/smtpd: add a forward-file option

2020-12-20 Thread Gilles CHEHADE
> On 20 Dec 2020, at 03:21, Theo de Raadt wrote: > > Todd C. Miller wrote: > >> I like this direction but I worry about breaking existing configs. >> How are we going to alert existing users that they need to update >> their configs if the behavior silently changes? > > I think the

Re: [diff] src/usr.sbin/smtpd: add a forward-file option

2020-12-20 Thread Gilles CHEHADE
> On 20 Dec 2020, at 07:19, Theo de Raadt wrote: > > There are thousands of people with smtpd configurations, and sysmerge > is not going to handle this. > > We cannot expect them all to change their files. This is madness. > > Gilles, I think you should be addi

Re: [diff] src/usr.sbin/smtpd: add a forward-file option

2020-12-20 Thread Gilles CHEHADE
> On 20 Dec 2020, at 07:13, Sebastien Marie wrote: > > On Sat, Dec 19, 2020 at 10:36:32PM +, gil...@poolp.org wrote: >> Hello, >> >> Whenever a rule with a local action (mbox, maildir, lmtp or mda) is matched, >> smtpd will >> attempt to search for a ~/.forward file in the recipient

Re: [diff] src/usr.sbin/smtpd: add a forward-file option

2020-12-20 Thread Gilles CHEHADE
> On 20 Dec 2020, at 02:09, Todd C. Miller wrote: > > I like this direction but I worry about breaking existing configs. > How are we going to alert existing users that they need to update > their configs if the behavior silently changes? > > - todd I agree and this diff was more to suggest

Re: [diff] src/usr.sbin/smtpd: change process names

2020-12-19 Thread gilles
December 19, 2020 11:26 PM, "Martijn van Duren" wrote: > Personally I'd rather wait to keep the names in sync, especially since > it's an easy 2 line diff that can easily be incorperated in the bigger > thing. But it's not something I'm going to loose sleep over if others > thing it can go in

[diff] src/usr.sbin/smtpd: add allow-exec to explicitly allow commands from aliases

2020-12-19 Thread gilles
Last diff of the series: This introduces the same logic as forward-file for executing commands. Executing commands from aliases should be discouraged as you can always achieve the same through a forward file and benefit from the privilege separation of running a command as a separate user

[diff] src/usr.sbin/smtpd: add allow-exec to explicitly allow custom mda

2020-12-19 Thread gilles
Hello, As is done in other MTA, smtpd allows execution of a custom command in forward files so users can plug their procmail, fdm and other. It is currently not possible to allow the users to forward their mail through a .forward file without also allowing them to run a custom mda. This diff

[diff] src/usr.sbin/smtpd: add a forward-file option

2020-12-19 Thread gilles
Hello, Whenever a rule with a local action (mbox, maildir, lmtp or mda) is matched, smtpd will attempt to search for a ~/.forward file in the recipient directory and process it. This may be convenient for some setups but it is an implicit behavior that's not overridable and not always wanted.

Re: [diff] src/usr.sbin/smtpd: change process names

2020-12-19 Thread gilles
I agree but I thought this should be done in a second time as it is quite invasive and not required for the change to be visible outside the daemon December 19, 2020 11:13 PM, "Martijn van Duren" wrote: > I'm in favour of this change, since I like proper nomenclature. > But I think you should

[diff] src/usr.sbin/smtpd: change process names

2020-12-19 Thread gilles
Hello, A very long time ago, smtpd had several more processes which then got factored into a single one. We couldn't find a decent name back then but since a hacker had requested a pony from me I temporarily named the process "pony express" as it was in charge of delivering mail. Later, reyk

Re: [diff] src/usr.sbin/smtpd: plug two memory leaks

2020-12-17 Thread gilles
December 17, 2020 4:02 PM, gil...@poolp.org wrote: > Hello, > > The following diffs plug two memory leaks in smtpd: > > a- in lka_filter.c, the name of the filter chain for a session is strdup()-ed > upon session allocation but not released upon session release. free() it > in lka_filter_end().

[diff] src/usr.sbin/smtpd: plug two memory leaks

2020-12-17 Thread gilles
a tx is over, but it isn't. call io_free() on the channel in smtp_tx_free() if we do have a channel ready. Gilles diff --git a/usr.sbin/smtpd/lka_filter.c b/usr.sbin/smtpd/lka_filter.c index 9891e6140a3..6eb0829efca 100644 --- a/usr.sbin/smtpd/lka_filter.c +++ b/usr.sbin/smtpd/lka_filter.c

[diff] usr.sbin/smtpd: fix event handling upon exit

2020-12-14 Thread GILLES CHEHADE
seem to cause any issue but on other systems with a different libevent, calling event_del() without a matching event_add() either causes a runtime warning or a crash upon exit. Gilles diff --git a/usr.sbin/smtpd/mproc.c b/usr.sbin/smtpd/mproc.c index bde229e1..dac38af2 100644 --- a/usr.sbin

Re: smtpd: relax ORCPT check again

2020-11-18 Thread gilles
November 18, 2020 10:17 PM, "Joerg Jung" wrote: > On Wed, Nov 18, 2020 at 08:57:48PM +, gil...@poolp.org wrote: > >> November 18, 2020 9:54 PM, "Joerg Jung" wrote: >> >> Hi, >> >> in my opinion revision 1.423 of smtp_session.c went a bit too far. >> Enforcing that ORCPT has to have

smtpd stricter forkmda()

2020-05-04 Thread Gilles Chehade
er called from forkmda()"); log_debug("debug: smtpd: forking mda for session %016"PRIx64 ": %s as %s", id, deliver->userinfo.username, -- Gilles Chehade @poolpOrg https://www.poolp.org patreon: https://www.patreon.com/gilles

Re: smtpd: fix catch-all in virtual aliases

2020-04-28 Thread gilles
April 28, 2020 11:02 AM, "Joerg Jung" mailto:m...@umaxx.net?to=%22Joerg%20Jung%22%20)> wrote: On 28. Apr 2020, at 10:10, gil...@poolp.org (mailto:gil...@poolp.org) wrote: April 28, 2020 8:55 AM, "Joerg Jung" mailto:m...@umaxx.net)> wrote: Also this change might break existing valid setups

Re: smtpd: fix catch-all in virtual aliases

2020-04-28 Thread gilles
gt; *@domain @ => * and this is not an aliases only thing, this is how table lookups are performed for type K_MAILADDR. This allows you to do stuff like follows: root : root gil...@poolp.org : gilles e...@faurot.net : eric @poolp.org : poolpcatchall @faurot.net

Re: OpenSMTPD: unprivileged mode - now with diff

2020-04-26 Thread gilles
April 26, 2020 10:34 AM, "Christopher Zimmermann" wrote: > Hi, > > I further developed my approach to allow running smtpd with fewer privileges. > This diff does two > things: > > - always run lmtp deliveries as SMTPD_USER. The change to mda_unpriv.c is > needed, because otherwise > all

Re: smtpd: trailing CR

2020-04-23 Thread gilles
observed no issue, still running w/ your diff April 23, 2020 1:10 PM, "Eric Faurot" wrote: > On Tue, Apr 21, 2020 at 07:08:48AM +, gil...@poolp.org wrote: > >> April 21, 2020 4:28 AM, "Todd C. Miller" wrote: >> >> On Mon, 20 Apr 2020 15:01:31 +0200, Eric Faurot wrote: >> >> There has

Re: smtpd: fix smtpctl discover

2020-04-21 Thread gilles
April 20, 2020 9:07 PM, "Eric Faurot" wrote: > Hi again, > > We had a report of a crash when running "smtpctl discover" on an > envelope that has a invalid dispatcher (action name changed in the > config). > > The issue is that the dispatcher is not checked after the envelope is > loaded as a

Re: smtpd: trailing CR

2020-04-21 Thread gilles
April 21, 2020 4:28 AM, "Todd C. Miller" wrote: > On Mon, 20 Apr 2020 15:01:31 +0200, Eric Faurot wrote: > >> There has been a discussion a while ago about the issue of trailing CR >> in smtp lines (https://marc.info/?l=openbsd-tech=156890805128121=2). >> >> It is agreed that stripping an

Re: smtpd: fix report event format

2020-04-08 Thread gilles
April 8, 2020 11:51 PM, gil...@poolp.org wrote: > April 8, 2020 6:15 PM, "Joerg Jung" wrote: > >>> On 8. Apr 2020, at 17:19, Eric Faurot wrote: >>> >>> Some users had issues with report events for MAIL FROM and RCPT TO >>> when "|" appear in the mail address (yes, it seems to happen), because

Re: smtpd: fix report event format

2020-04-08 Thread gilles
April 8, 2020 6:15 PM, "Joerg Jung" wrote: >> On 8. Apr 2020, at 17:19, Eric Faurot wrote: >> >> Some users had issues with report events for MAIL FROM and RCPT TO >> when "|" appear in the mail address (yes, it seems to happen), because >> that's also the field separator. To make parsing the

Re: bump smtpd version?

2020-01-30 Thread gilles
yes ok January 30, 2020 2:02 PM, "Solene Rapenne" wrote: > on https://opensmtpd.org the OpenBSD version file says 6.6.2 while we > currently have 6.6.1 in CVS. > > Should we bump to 6.6.2? > > Index: smtpd.h > === > RCS file:

Errata patches for OpenSMTPD have been released for OpenBSD 6.5 and 6.6.

2020-01-28 Thread gilles
about what made it possible and what plans we have so similar bugs don't lead to similar consequences, two ideas have been discussed to lock things down. But for now, it's syspatch time. Gilles

Re: .Aq in smtpd.conf(5)

2019-12-05 Thread gilles
December 5, 2019 4:34 PM, "Ingo Schwarze" wrote: > Hi Jason, > > Jason McIntyre wrote on Thu, Dec 05, 2019 at 02:54:20PM +: > >> i have reverted it, with a heavy heart. > > Do you think i should try and convince the groff folks to always > render .Aq/.Ao/.Ac as ASCII '<' and '>', even in

smtpd: remove implicit listen on socket

2019-11-25 Thread Gilles Chehade
@ table aliases file:/etc/mail/aliases +listen on socket + # To accept external mail, replace with: listen on all # listen on lo0 -- Gilles Chehade @poolpOrg https://www.poolp.orgpatreon: https://www.patreon.com/gilles

Re: smtpd remove implicit ruleset behavior

2019-11-24 Thread Gilles Chehade
On Mon, Nov 25, 2019 at 08:30:21AM +0100, Gilles Chehade wrote: > On Mon, Nov 25, 2019 at 01:09:20AM +0100, Joerg Jung wrote: > > On Sun, Nov 24, 2019 at 10:54:14AM +0100, Gilles Chehade wrote: > > > > > > Ten years ago, it seemed a very neat idea that OpenSMTPD wou

Re: smtpd remove implicit ruleset behavior

2019-11-24 Thread Gilles Chehade
On Mon, Nov 25, 2019 at 01:09:20AM +0100, Joerg Jung wrote: > On Sun, Nov 24, 2019 at 10:54:14AM +0100, Gilles Chehade wrote: > > > > Ten years ago, it seemed a very neat idea that OpenSMTPD would have some > > implicit defaults to avoid people creating open relays.

smtpd remove implicit ruleset behavior

2019-11-24 Thread Gilles Chehade
e explicit notation to default config, then put a startup warning in the next release so configurations are not broken but people spot that this is no longer encouraged and we can then later kill it. -- Gilles Chehade @poolpOrg https://www.poolp

Re: smtpd handling of \r in DATA part

2019-10-04 Thread Gilles Chehade
> diff -u -p -r1.389 smtp_session.c > --- smtp_session.c20 Feb 2019 11:56:27 - 1.389 > +++ smtp_session.c24 Apr 2019 09:33:35 - > @@ -1078,7 +1078,7 @@ smtp_io(struct io *io, int evt, void *ar > > case IO_DATAIN: > nextline: > - line = io_getline(s->io, ); > + line = io_getline_rn(s->io, ); > if ((line == NULL && io_datalen(s->io) >= SMTP_LINE_MAX) || > (line && len >= SMTP_LINE_MAX)) { > s->flags |= SF_BADINPUT; > @@ -2727,7 +2727,7 @@ filter_session_io(struct io *io, int evt > switch (evt) { > case IO_DATAIN: > nextline: > - line = io_getline(tx->filter, ); > + line = io_getline_rn(tx->filter, ); > /* No complete line received */ > if (line == NULL) > return; -- Gilles Chehade @poolpOrg https://www.poolp.orgpatreon: https://www.patreon.com/gilles

Re: smtpd handling of \r in DATA part

2019-10-04 Thread gilles
October 4, 2019 9:55 AM, "Martijn van Duren" wrote: > > This is similar to the diff I send a few months ago, but still doesn't > fix the case when someone sends a standalone '\n' as line-ending. > Unsure I understand that, can you elaborate ? > I'd prefer if we go with reverting (=my

Re: smtpd handling of \r in DATA part

2019-10-04 Thread Gilles Chehade
io_set_write(io); - return; - } - /* Message body */ eom = 0; if (s->state == STATE_BODY) { @@ -2792,7 +2783,7 @@ filter_session_io(struct io *io, int evt, void *arg) switch (evt) { case IO_DATAIN: nextline: -

Re: smtpd handling of \r in DATA part

2019-10-04 Thread Gilles Chehade
xing iobuf is not a two liner and it affects virtually all of the daemon and at this point we're looking for stability in the code, so unless eric@ or you can come up with a diff that's trivial and that will not affect any code paths beyond smtp client and filter getlines(), I'll prefer a degraded

Re: smtpd: mail.* tempfail vs permfail

2019-09-26 Thread gilles
t; This resulted in a few mails being PERMFAIL. > > I talked to gilles@ about this and he's somewhat inclined to agree with > me that this is a TEMPFAIL situation. Even if the directory where the > mail is supposed to be delivered is permanently not accessible I'd > argue that

Re: smtpd: smtpc: ssl_check_name() dead assignment

2019-09-21 Thread gilles
September 21, 2019 10:03 AM, "Sebastien Marie" wrote: > Hi, > > The current code in smtp_verify_server_cert() has a dead assignment for return > code of ssl_check_name(). > > At first stance, I was a bit unsure if return code should be checked or not to > detect certificate error. but as soon

Re: smtpd handling of \r in DATA part

2019-09-19 Thread gilles
September 19, 2019 7:26 PM, "Eric Faurot" wrote: > On Thu, Sep 19, 2019 at 05:46:47PM +0200, Gilles Chehade wrote: > >> Hello, >> >> The RFC for SMTP states the following (section 2.3.8): >> >> In addition, the appearance of "bare"

smtpd handling of \r in DATA part

2019-09-19 Thread Gilles Chehade
- do we leave '\r' in the body ? b- do we turn '\r' into '\n' c- do we keep strict behavior ? d- do we keep strict behavior + provide a knob for '\r' to work ? -- Gilles Chehade @poolpOrg https://www.poolp.orgpatreon: https://www.patreon.com/gilles

Re: PATCH: smtpd: don't strcmp() NULL in mta_relay_cmp()

2019-09-14 Thread Gilles Chehade
o I added a > similar check there. > > I'd like you to double-check whether the fix is indeed correct. > Yes, your understanding of the problem is correct and your diff also, so I committed it a minute ago, thanks ! I'm curious about what configuration allowed you to hit this though,

smtpd junk filtering action

2019-09-02 Thread gilles
The following diff introduces the junk action which allows builtin filters to junk a session or transaction. The following would junk a session if it doesn't have rdns when it reaches the helo filtering hook: match "check-rdns" phase helo match !rdns junk Currently this is not doable so

Re: [Patch] smtp(1) with proto "smtps" should default to port smtps/465

2019-09-02 Thread gilles
committed thanks ! August 31, 2019 1:57 PM, "Ross L Richardson" wrote: > ...unless I'm very mistaken! > > Ross > > > Index: smtpc.c > === > RCS file: /cvs/src/usr.sbin/smtpd/smtpc.c,v > retrieving revision 1.6 > diff -u -p

Re: smtpd: change PATH for filters

2019-09-02 Thread gilles
ember 2, 2019 5:55 PM, gil...@poolp.org wrote: >> >> September 2, 2019 5:23 PM, "Martijn van Duren" >> wrote: >> >> Gilles should probably elaborate, but the way things are now is that >> system(3) is used to start the filters, allowing us to run any arb

Re: smtpd: change PATH for filters

2019-09-02 Thread gilles
September 2, 2019 7:29 PM, "Martijn van Duren" wrote: > On 9/2/19 6:00 PM, gil...@poolp.org wrote: > >> September 2, 2019 5:55 PM, gil...@poolp.org wrote: >> >>> September 2, 2019 5:23 PM, "Martijn van Duren" >>> wrote: >> &

Re: smtpd: change PATH for filters

2019-09-02 Thread gilles
September 2, 2019 5:55 PM, gil...@poolp.org wrote: > September 2, 2019 5:23 PM, "Martijn van Duren" > wrote: > >> Gilles should probably elaborate, but the way things are now is that >> system(3) is used to start the filters, allowing us to run any arbitrary >

Re: smtpd: change PATH for filters

2019-09-02 Thread gilles
September 2, 2019 5:23 PM, "Martijn van Duren" wrote: > Gilles should probably elaborate, but the way things are now is that > system(3) is used to start the filters, allowing us to run any arbitrary > (set of) command(s) as a filter. > > Since the filters now in

Re: [Patch] smtp(1) with proto "smtps" should default to port smtps/465

2019-08-31 Thread gilles
no you're not, i'll commit this tomorrow unless eric@ beats me to it 31 août 2019 13:57 "Ross L Richardson" a écrit: > ...unless I'm very mistaken! > > Ross > > > Index: smtpc.c > === > RCS file:

Re: smtpd reports - expectation management

2019-08-29 Thread gilles
29 août 2019 07:02 "Martijn van Duren" a écrit: > Since we don't support any smtp-out events at time of writing, so we > might as well throw an error if people try to register one. This way > people won't be surprised if the registration succeeds, but no event > ever arrives. > > OK? > no

Re: smtpd filters: banner hostname

2019-08-28 Thread gilles
28 août 2019 15:10 "Martijn van Duren" a écrit: > On 8/28/19 2:52 PM, gil...@poolp.org wrote: > >> Yes sorry my bad, but this still covers the textstring argument: >> >> We need to be able to reject at banner and this is going to be implemented >> as a filter phase, so basically if we expect

Re: smtpd filters: banner hostname

2019-08-28 Thread gilles
28 août 2019 14:07 "Martijn van Duren" a écrit: >> >> So my understanding is that you'd like a filter to be able to use the >> result from an SPF lookup to reject a message in your filter and have >> the hostname that was used in the banner part of the message. > > Yes, because that's the only

Re: smtpd filters: banner hostname

2019-08-28 Thread gilles
28 août 2019 12:26 "Gilles Chehade" a écrit: > On Wed, Aug 28, 2019 at 10:33:29AM +0200, Martijn van Duren wrote: > >> On 8/28/19 9:23 AM, gil...@poolp.org wrote: >> 28 ao??t 2019 09:04 "Martijn van Duren" a >> ??crit: >> >> Currently

Re: smtpd filters: banner hostname

2019-08-28 Thread Gilles Chehade
/cvs/src/usr.sbin/smtpd/smtpd.h,v > retrieving revision 1.632 > diff -u -p -r1.632 smtpd.h > --- smtpd.h 23 Aug 2019 07:09:52 - 1.632 > +++ smtpd.h 28 Aug 2019 08:32:33 - > @@ -310,6 +310,7 @@ enum imsg_type { > > IMSG_REPORT_SMTP_LINK_CONNECT, > IMSG_REPORT_SMTP_LINK_DISCONNECT, > + IMSG_REPORT_SMTP_LINK_GREETING, > IMSG_REPORT_SMTP_LINK_IDENTIFY, > IMSG_REPORT_SMTP_LINK_TLS, > IMSG_REPORT_SMTP_LINK_AUTH, > @@ -1332,6 +1333,8 @@ void lka_report_register_hook(const char > void lka_report_smtp_link_connect(const char *, struct timeval *, uint64_t, > const char *, int, > const struct sockaddr_storage *, const struct sockaddr_storage *); > void lka_report_smtp_link_disconnect(const char *, struct timeval *, > uint64_t); > +void lka_report_smtp_link_greeting(const char *, uint64_t, struct timeval *, > const char *, > +const char *); > void lka_report_smtp_link_identify(const char *, struct timeval *, uint64_t, > const char *, const char *); > void lka_report_smtp_link_tls(const char *, struct timeval *, uint64_t, > const char *); > void lka_report_smtp_link_auth(const char *, struct timeval *, uint64_t, > const char *, const char *); > @@ -1501,6 +1504,8 @@ int queue_message_walk(struct envelope * > void report_smtp_link_connect(const char *, uint64_t, const char *, int, > const struct sockaddr_storage *, const struct sockaddr_storage *); > void report_smtp_link_disconnect(const char *, uint64_t); > +void report_smtp_link_greeting(const char *, uint64_t, const char *, > +const char *); > void report_smtp_link_identify(const char *, uint64_t, const char *, const > char *); > void report_smtp_link_tls(const char *, uint64_t, const char *); > void report_smtp_link_auth(const char *, uint64_t, const char *, const char > *); > -- Gilles Chehade @poolpOrg https://www.poolp.orgpatreon: https://www.patreon.com/gilles

Re: Make filter line handling more developer friendly

2019-08-28 Thread Gilles Chehade
struct filter_session *fs; > >> > >>(void)strlcpy(buffer, line, sizeof buffer); > >> - if ((ep = strchr(buffer, '|')) == NULL) > >> - return 0; > >> - *ep = 0; > >> + ep = strchr(buffer, '|'); > >> + ep[0] = '\0'; > > &g

Re: smtpd filters: banner hostname

2019-08-28 Thread gilles
28 août 2019 09:04 "Martijn van Duren" a écrit: > Currently looking into writing an spf filter based on libopensmtpd. > While working through the spec I found in RFC7208 section 7.3 that: > The "r" macro expands to the name of the receiving MTA. > In other words the hostname presented in the

Re: Make filter line handling more developer friendly

2019-08-26 Thread gilles
25 août 2019 07:01 "Martijn van Duren" a écrit: > Right now all we get is "Misbehaving filter", which doesn't tell the > developer a lot. > Indeed > Diff below does the following: > - Make the register_hooks actually fail on misbehaviour. > - Change some *ep = 0 to a more semantically

Re: smtpd filters: prettify proc-exec

2019-08-23 Thread Gilles Chehade
On Fri, Aug 23, 2019 at 07:33:29PM +0200, Martijn van Duren wrote: > On 8/23/19 7:06 PM, Gilles Chehade wrote: > > On Fri, Aug 23, 2019 at 09:03:51AM +0200, Martijn van Duren wrote: > >> Hello, > >> > > > > Hello, > > > > > >> When r

Re: smtpd filters: prettify proc-exec

2019-08-23 Thread Gilles Chehade
ct_set(conf->sc_filters_dict, $2, filter_config); > +} proc_params { > + dict_set(conf->sc_processors_dict, filter_config->proc, processor); > + processor = NULL; > + filter_config = NULL; > +} > +| > FILTER STRING PHASE { > if (dict_get(conf->sc_filters_dict, $2)) { > yyerror("filter already exists with that name: %s", $2); > -- Gilles Chehade @poolpOrg https://www.poolp.orgpatreon: https://www.patreon.com/gilles

fix inet6 displaying in smtpd

2019-08-11 Thread Gilles Chehade
uct sockaddr_in6 *)sa; - (void)strlcpy(buf, "IPv6:", sizeof(buf)); - p = buf + 5; + p = buf; in6_addr = >sin6_addr; - (void)bsnprintf(p, NI_MAXHOST, "%s", in6addr_t

Re: smtpd: default to standard ports in relay-host

2019-07-24 Thread Gilles Chehade
On Tue, Jul 23, 2019 at 12:15:26PM +0200, Klemens Nanni wrote: > On Tue, Jul 23, 2019 at 11:00:04AM +0200, Gilles Chehade wrote: > > there is no schema today that should default to 587, unless > > submission:// is introduced as an alias to smtp+tls AND port 587. > Alright; thi

Re: Diff to stop using reserved words for smtpd.conf(5) examples

2019-07-24 Thread Gilles Chehade
On Tue, Jul 23, 2019 at 08:51:38PM +0200, Ingo Schwarze wrote: > Hi Gilles, > > Gilles Chehade wrote on Tue, Jul 23, 2019 at 08:27:06AM +0200: > > On Mon, Jul 22, 2019 at 05:05:01PM -0400, Kurt Mosiejczuk wrote: > > >> This is a diff for that changes the example

Re: smtpd: Allow labels containing "@"

2019-07-24 Thread Gilles Chehade
On Wed, Jul 24, 2019 at 12:18:05AM +0200, Klemens Nanni wrote: > On Tue, Jul 23, 2019 at 09:06:33AM +0200, Gilles Chehade wrote: > > On Tue, Jul 23, 2019 at 08:51:54AM +0200, Sebastien Marie wrote: > > > it seems to me this url is wrong. the '@' in username should be

Re: smtpd: Allow labels containing "@"

2019-07-24 Thread Gilles Chehade
On Tue, Jul 23, 2019 at 10:20:10PM +0200, Sebastian Benoit wrote: > Gilles Chehade(gil...@poolp.org) on 2019.07.23 09:06:33 +0200: > > On Tue, Jul 23, 2019 at 08:51:54AM +0200, Sebastien Marie wrote: > > > On Mon, Jul 22, 2019 at 11:26:28PM +0200, Klemens Nanni wrote: >

Re: smtpd: default to standard ports in relay-host

2019-07-23 Thread Gilles Chehade
On Tue, Jul 23, 2019 at 10:54:57AM +0200, Klemens Nanni wrote: > On Tue, Jul 23, 2019 at 08:18:18AM +0200, Gilles Chehade wrote: > > it should definitely default to 25 in my opinion, disregarding if people > > use "relay host" for submission or not. > Fine with me; I

Re: smtpd: Allow labels containing "@"

2019-07-23 Thread Gilles Chehade
text_to_relayhost(struct relayhost *rela > > relay->port = 0; > > > > /* first, we extract the label if any */ > > - if ((q = strchr(p, '@')) != NULL) { > > + if ((q = strrchr(p, '@')) != NULL) { > > *q = 0; > > if (strlcpy(relay->authlabel, p, sizeof (relay->authlabel)) > > >= sizeof (relay->authlabel)) > > > > -- > Sebastien Marie > -- Gilles Chehade @poolpOrg https://www.poolp.orgpatreon: https://www.patreon.com/gilles

Re: Diff to stop using reserved words for smtpd.conf(5) examples

2019-07-23 Thread Gilles Chehade
-952,14 +952,14 @@ table other-relays file:/etc/mail/other- > listen on lo0 > listen on egress > > -action "mbox" mbox alias > -action "relay" relay > +action local-mbox mbox alias > +action inet-mail relay > > -match for local action "mbox" > -match for any action "relay" > +match for local action local-mbox > +match for any action inet-mail > match !from src mail\-from "@example.com" for any \e >reject > -match from any for domain example.com action "mbox" > +match from any for domain example.com action local-mbox > .Ed > .Sh SEE ALSO > .Xr mailer.conf 5 , > -- Gilles Chehade @poolpOrg https://www.poolp.orgpatreon: https://www.patreon.com/gilles

Re: smtpd: default to standard ports in relay-host

2019-07-23 Thread Gilles Chehade
0, > 587 }, > + { "smtp+notls://", RELAY_TLS_NO,0, > 25 }, > + { "lmtp://",RELAY_TLS_NO,RELAY_LMTP, > 0 }, > + { "smtps://", RELAY_TLS_

Re: smtpd: Use IPPORT_HILASTAUTO not 0xffff

2019-07-23 Thread Gilles Chehade
gt; p = beg + len; > if (*p == ':') { > - relay->port = strtonum(p+1, 1, 0x, ); > + relay->port = strtonum(p+1, 1, IPPORT_HILASTAUTO, ); > if (errstr) > return 0; > } > -- Gilles Chehade

Re: smtpd: Allow labels containing "@"

2019-07-22 Thread Gilles Chehade
7 +352,7 @@ text_to_relayhost(struct relayhost *rela > relay->port = 0; > > /* first, we extract the label if any */ > - if ((q = strchr(p, '@')) != NULL) { > + if ((q = strrchr(p, '@')) != NULL) { >

Re: smtpd replace mkstemp+fdopen with tmpfile

2019-07-02 Thread Gilles Chehade
On Mon, Jul 01, 2019 at 08:25:02PM +0200, Martijn van Duren wrote: > No functional change intended, just simplify the code. > > OK? > yes, ok gilles@ > Index: enqueue.c > === > RCS file: /cvs/src/usr.s

Re: smtpd fix proc filter chaining with proceed

2019-07-01 Thread Gilles Chehade
rom). > > Mischa has been running with this diff for several days now without > issue. > > OK? > yes ok gilles@ > Index: lka_filter.c > === > RCS file: /cvs/src/usr.sbin/smtpd/lka_filter.c,v > retrieving re

Re: tls_load_file.3

2019-06-17 Thread Gilles Chehade
will be read. I don't see what was wrong here :-/ > .Pp > .Fn tls_config_set_cert_mem > sets the public certificate directly from memory. > .Pp > .Fn tls_config_set_crl_file > -sets the filename used to load a file containing the > +sets the file used to load a file contain

Re: [patch] use acme-client to sign certificated with ecdsa keys

2019-06-14 Thread Gilles Chehade
> > > > > > > > > On 6/12/19 2:30 PM, Renaud Allard wrote: > > > > > > > > > > > > > > > On 6/11/19 2:36 PM, Sebastian Benoit wrote: > > > > > > Hi, > > > > > > > > > > >

Re: [patch] use acme-client to sign certificated with ecdsa keys

2019-06-14 Thread Gilles Chehade
> > > > Hi, > > > > > > > > some feedback below. > > > > > > > > Renaud: maybe wait for feedback from florian or gilles until > > > > acting on my comments, sometimes sending diffs to fast creates more > > > > work ;

Re: [patch] use acme-client to sign certificated with ecdsa keys

2019-06-12 Thread Gilles Chehade
ION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > > - */ > > - > > -#include > > -#include > > -#include > > - > > -#include > > -#include > > -#include > > - > > -#include "rsa.h" > > - > > -/* > > - * Default number of bits when creating a new key. > > - */ > > -#defineKBITS 4096 > > - > > -/* > > - * Create an RSA key with the default KBITS number of bits. > > - */ > > -EVP_PKEY * > > -rsa_key_create(FILE *f, const char *fname) > > -{ > > - EVP_PKEY_CTX*ctx = NULL; > > - EVP_PKEY*pkey = NULL; > > - > > - /* First, create the context and the key. */ > > - > > - if ((ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL)) == NULL) { > > - warnx("EVP_PKEY_CTX_new_id"); > > - goto err; > > - } else if (EVP_PKEY_keygen_init(ctx) <= 0) { > > - warnx("EVP_PKEY_keygen_init"); > > - goto err; > > - } else if (EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, KBITS) <= 0) { > > - warnx("EVP_PKEY_set_rsa_keygen_bits"); > > - goto err; > > - } else if (EVP_PKEY_keygen(ctx, ) <= 0) { > > - warnx("EVP_PKEY_keygen"); > > - goto err; > > - } > > - > > - /* Serialise the key to the disc. */ > > - > > - if (PEM_write_PrivateKey(f, pkey, NULL, NULL, 0, NULL, NULL)) > > - goto out; > > - > > - warnx("%s: PEM_write_PrivateKey", fname); > > -err: > > - EVP_PKEY_free(pkey); > > - pkey = NULL; > > -out: > > - EVP_PKEY_CTX_free(ctx); > > - return pkey; > > -} > > - > > - > > -EVP_PKEY * > > -rsa_key_load(FILE *f, const char *fname) > > -{ > > - EVP_PKEY*pkey; > > - > > - pkey = PEM_read_PrivateKey(f, NULL, NULL, NULL); > > - if (pkey == NULL) { > > - warnx("%s: PEM_read_PrivateKey", fname); > > - return NULL; > > - } else if (EVP_PKEY_type(pkey->type) == EVP_PKEY_RSA) > > - return pkey; > > - > > - warnx("%s: unsupported key type", fname); > > - EVP_PKEY_free(pkey); > > - return NULL; > > -} > > Index: rsa.h > > === > > RCS file: rsa.h > > diff -N rsa.h > > --- rsa.h 31 Aug 2016 22:01:42 - 1.1 > > +++ /dev/null 1 Jan 1970 00:00:00 - > > @@ -1,23 +0,0 @@ > > -/* $Id: rsa.h,v 1.1 2016/08/31 22:01:42 florian Exp $ */ > > -/* > > - * Copyright (c) 2016 Kristaps Dzonsons > > - * > > - * Permission to use, copy, modify, and distribute this software for any > > - * purpose with or without fee is hereby granted, provided that the above > > - * copyright notice and this permission notice appear in all copies. > > - * > > - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHORS DISCLAIM ALL WARRANTIES > > - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > > - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR > > - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > > - * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > > - * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > > - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > > - */ > > -#ifndef RSA_H > > -#define RSA_H > > - > > -EVP_PKEY *rsa_key_create(FILE *, const char *); > > -EVP_PKEY *rsa_key_load(FILE *, const char *); > > - > > -#endif /* ! RSA_H */ > > > > > -- > I'm not entirely sure you are real. > -- Gilles Chehade @poolpOrg https://www.poolp.org tip me: https://paypal.me/poolpOrg

  1   2   3   >