[patch] Re: smtpd.conf new grammar

[Edgar Pettijohn III]

On 05/26/18 19:18, Edgar Pettijohn III wrote:



Sorry, I've read the announcements, looked at man pages and examples,
but still didn't manage to figure out how to translate "deliver via 
dovecot

lmtp"
(to have sieve working) into the new syntax. So far my config was:

table vusers ldap:/etc/mail/ldap.conf
table vdomains ldap:/etc/mail/ldap.conf
table passwd ldap:/etc/mail/ldap.conf

accept from local for local virtual  deliver to lmtp
"/var/dovecot/lmtp"
accept from any for domain  virtual  deliver to lmtp
"/var/dovecot/lmtp"


I tried changing those into:

action "lmtp-local" mda "/usr/libexec/mail.lmtp -d /var/dovecot/lmtp"


try:
action "lmtp-local" mda "/usr/libexec/mail.lmtp -d 
unix:/var/dovecot/lmtp -f %{sender}"


However, this does feel odd. I need to switch over as well, but still 
trying to wrap my brain around the new config.

virtual 
action "relay" relay
match from local for local action "lmtp-local"
match from any for domain  action "lmtp-local"
match from local for any action "relay"


but delivery attempts fail with Error ("mail.lmtp: sender must be 
specified

with -f")

What would be the proper config for this?
  --
viq


Try this patch. You may need to play with the %%{rcpt.user} bit 
depending on your dovecot userdb. It needs more to handle different use 
cases.


smtpd.conf bits
action "local" lmtp "unix:/var/dovecot/lmtp"
match for local action "local"


diff -u -p -u -r1.202 parse.y
--- parse.y 25 May 2018 14:10:28 -  1.202
+++ parse.y 27 May 2018 03:00:06 -
@@ -179,7 +179,7 @@ typedef struct {
 %token HELO HELO_SRC HOST HOSTNAME HOSTNAMES
 %token INCLUDE INET4 INET6
 %token KEY
-%token LIMIT LISTEN LOCAL
+%token LIMIT LISTEN LOCAL LMTP
 %token MAIL_FROM MAILDIR MASK_SRC MASQUERADE MATCH MAX_MESSAGE_SIZE 
MAX_DEFERRED MBOX MDA MTA MX

 %token NODSN
 %token ON
@@ -376,6 +376,10 @@ MBOX {
 | EXPAND_ONLY {
    dispatcher->u.local.expand_only = 1;
 } dispatcher_local_options
+| LMTP STRING {
+   asprintf(>u.local.command,
+  "/usr/libexec/mail.lmtp -f %%{sender} -d %s %%{rcpt.user}", $2);
+} dispatcher_local_options

 ;

@@ -1535,6 +1539,7 @@ lookup(char *s)
    { "key",    KEY },
    { "limit",  LIMIT },
    { "listen", LISTEN },
+   { "lmtp",   LMTP },
    { "local",  LOCAL },
    { "mail-from",  MAIL_FROM },
    { "maildir",    MAILDIR },

Plus a little log porn for you.
May 26 22:07:45 laptop smtpd[38093]: e133b6fee23c0b30 smtp 
event=connected address=local host=laptop.my.domain
May 26 22:07:45 laptop smtpd[38093]: e133b6fee23c0b30 smtp event=message 
address=local host=laptop.my.domain msgid=39a32d75 
from= to= size=355 
ndest=1 proto=ESMTP
May 26 22:07:45 laptop smtpd[38093]: e133b6fee23c0b30 smtp event=closed 
address=local host=laptop.my.domain reason=quit

May 26 22:07:45 laptop dovecot: lmtp(9496): Connect from local
May 26 22:07:45 laptop dovecot: lmtp(edgar): 
msgid=: saved mail to INBOX
May 26 22:07:45 laptop dovecot: lmtp(9496): Disconnect from local: 
Successful quit
May 26 22:07:45 laptop smtpd[38093]:  mda event=delivery 
evpid=39a32d75b3524ef6 from= 
to= rcpt= user=edgar 
delay=0s result=Ok stat=Delivered

Re: opensmtpd / ldap unreliable

[Paul B. Henson]

On Sat, May 26, 2018 at 08:16:28AM +0200, Gilles Chehade wrote:

> please do so we have more people able to test

Done, thanks.

What are your thoughts design-wise on dealing with ldap not being
available at startup? Should layer 7 issues (ldap auth failed, etc) be
handled differently than transport level issues (connection
refused/timed out)?

Re: smtpd.conf new grammar

[Amelia A Lewis]

On Sun, 27 May 2018 00:43:02 +0200, viq wrote:
> Sorry, I've read the announcements, looked at man pages and examples,
> but still didn't manage to figure out how to translate "deliver via dovecot
> lmtp"
> (to have sieve working) into the new syntax. So far my config was:
> 
> table vusers ldap:/etc/mail/ldap.conf
> table vdomains ldap:/etc/mail/ldap.conf
> table passwd ldap:/etc/mail/ldap.conf
> 
> accept from local for local virtual  deliver to lmtp
> "/var/dovecot/lmtp"
> accept from any for domain  virtual  deliver to lmtp
> "/var/dovecot/lmtp"
> 
> 
> I tried changing those into:
> 
> action "lmtp-local" mda "/usr/libexec/mail.lmtp -d /var/dovecot/lmtp"
> virtual 
> action "relay" relay
> match from local for local action "lmtp-local"
> match from any for domain  action "lmtp-local"
> match from local for any action "relay"
> 
> 
> but delivery attempts fail with Error ("mail.lmtp: sender must be specified
> with -f")
> 
> What would be the proper config for this?

Good point (and I'm going to need it, too, when I get to that point, 
for dovecot lmtp on one machine and dspam lmtp on another).

Gilles, shouldn't there be a keyword 'lmtp' to go along with 
mbox/maildir/mda/relay/forward-only/expand-only? Comparing old (6.2) 
smtp.conf(5) with the updated one linked from your article, it seems to 
be the only missing method of delivery.

Or perhaps it just got skipped in the man page? viq, have you tried 

action "lmtp-local" lmtp "/var/dovecot/lmtp"

?

(yes, I should do it, but I'm not yet comfortable following -current, 
even as I move more and more machines to openbsd, I am a Bad Person™)

Amy!
-- 
Amelia A. Lewisamyzing {at} talsever.com
Life is a glorious cycle of song / a medley of extemporanea;
and love is a thing that can never go wrong;
and I am Marie of Roumania.
-- Dorothy Parker

Re: smtpd.conf new grammar

[Edgar Pettijohn III]

Sorry, I've read the announcements, looked at man pages and examples,
but still didn't manage to figure out how to translate "deliver via dovecot
lmtp"
(to have sieve working) into the new syntax. So far my config was:

table vusers ldap:/etc/mail/ldap.conf
table vdomains ldap:/etc/mail/ldap.conf
table passwd ldap:/etc/mail/ldap.conf

accept from local for local virtual  deliver to lmtp
"/var/dovecot/lmtp"
accept from any for domain  virtual  deliver to lmtp
"/var/dovecot/lmtp"


I tried changing those into:

action "lmtp-local" mda "/usr/libexec/mail.lmtp -d /var/dovecot/lmtp"


try:
action "lmtp-local" mda "/usr/libexec/mail.lmtp -d 
unix:/var/dovecot/lmtp -f %{sender}"


However, this does feel odd. I need to switch over as well, but still 
trying to wrap my brain around the new config.

virtual 
action "relay" relay
match from local for local action "lmtp-local"
match from any for domain  action "lmtp-local"
match from local for any action "relay"


but delivery attempts fail with Error ("mail.lmtp: sender must be specified
with -f")

What would be the proper config for this?
  --
viq

Re: smtpd.conf new grammar

[viq]

On Thu, May 24, 2018 at 2:18 PM, Gilles Chehade  wrote:

> Hi,
>
> I have just committed a major change in smtpd that'll require smtpd.conf
> to be rewritten before your update to the new code.
>
> The new grammar is not TOO different from the former one, a lot of stuff
> remains exactly identical, but the ruleset is now split into two parts:
>
> - a named action
> - a matching pattern which is associated to a named action
>
> In effect, instead of having:
>
> accept from any for local deliver to mbox
>
>
> You will have:
>
> action "my_action" mbox
>
> match from any for local action "my_action"
>
>
> There are a few keywords that have been shortened too but all in all the
> switch to new grammar is easy, the smtpd.conf man page has been updated,
> and it continues being improved thanks to ingo and jmc.
>
> The man page by itself should be enough to do the switch.
>
> Since this is quite a major change, I also wrote a post that describes a
> conversion of my own complex smtpd.conf to new grammar:
>
> https://poolp.org/posts/2018-05-21/switching-to-opensmtpd-new-config/
>
>
> I have also compiled a list of directives recognized by the parser which
> I intend to use for regress tests:
>
> https://poolp.org/~gilles/smtpd.conf
>
>
> As for the reasons behind the change they are numerous, I explained some
> at EuroBSDCon 2017, I explained some on my blog, the bottom line is that
> while one-line rules were apparently an awesome idea, they were actually
> a design error that had consequences on pretty much the entire daemon.
>
> We didn't realize it until a few months ago, we tried hard to maintain a
> one-line rule grammar but it became more and more obvious that this just
> isn't doable without creating issues and unnecessary complexity.
>
> The new grammar is cleaner, it helped remove ~700 lines of complex code,
> made the handling of .forward files as well much safer, removed a lot of
> very unpleasant side-effects most people didn't even realize existed ...
> until they hit that one case for which we had no way to work around.
>
>
> Anyways,
> looking forward for you to test and report how it works for you :-)


Sorry, I've read the announcements, looked at man pages and examples,
but still didn't manage to figure out how to translate "deliver via dovecot
lmtp"
(to have sieve working) into the new syntax. So far my config was:

table vusers ldap:/etc/mail/ldap.conf
table vdomains ldap:/etc/mail/ldap.conf
table passwd ldap:/etc/mail/ldap.conf

accept from local for local virtual  deliver to lmtp
"/var/dovecot/lmtp"
accept from any for domain  virtual  deliver to lmtp
"/var/dovecot/lmtp"


I tried changing those into:

action "lmtp-local" mda "/usr/libexec/mail.lmtp -d /var/dovecot/lmtp"
virtual 
action "relay" relay
match from local for local action "lmtp-local"
match from any for domain  action "lmtp-local"
match from local for any action "relay"


but delivery attempts fail with Error ("mail.lmtp: sender must be specified
with -f")

What would be the proper config for this?
 --
viq

Re: connect two midi devices

[Sebastian Reitenbach]

Am Samstag, Mai 26, 2018 11:12 CEST, Alexandre Ratchov  schrieb:

> On Sat, May 26, 2018 at 12:10:03AM +0200, Sebastian Reitenbach wrote:
> > Am Freitag, Mai 25, 2018 22:22 CEST, Alexandre Ratchov  
> > schrieb:
> >
> > > On Fri, May 25, 2018 at 10:22:26AM +0200, Sebastian Reitenbach wrote:
> > > > Hi Alexandre,
> > > >
> > > > Am Freitag, Mai 25, 2018 08:41 CEST, Alexandre Ratchov  
> > > > schrieb:
> > > >
> > > > > On Fri, May 25, 2018 at 12:21:18AM +0200, Alexandre Ratchov wrote:
> > > > > >
> > > > > > Maybe, but unlikely. If the device attaches, generally it works. 
> > > > > > Show
> > > > > > what's received on midi2 when you type on the keyboard or do any 
> > > > > > other
> > > > > > simple actions.
> > > > > >
> > > > >
> > > > > fwiw, here's a small utility that I use very often to debug & connect
> > > > > MIDI ports.
> > > > >
> > > > > http://caoua.org/alex/obsd/midicat.tar.gz
> > > > >
> > > > > To connect two rmidi/2 -> rmidi/1 and dump the data on stderr, run:
> > > > >
> > > > > midicat -d -q rmidi/2 -q rmidi/1
> > > >
> > > >  Actually, that midicat seems to do the trick. When I run it in debug, 
> > > > and press some keys on the
> > > > system-1, output looks like:
> > > >
> > > > f8
> > > > f8
> > > > fe
> > > > f8
> > > > f8
> > > > f8
> > > > 90 80 9b
> > >
> > > ^^^
> > >
> > > these 3 bytes make no sense. The status byte 0x90 is correct but the
> > > two args are wrong. This is when you pressed the key, right?
> > >
> > > > ...
> > > > 90 9b b2
> > >
> > > These are also wrong, and this is when you released the key, right?
> > > Interestingly the 0x9b is repeated.
> > >
> >
> > f8
> > f8
> > f8
> > 90 80 34
> > 90 40 f8
> >  released key
>
> This one is cleary wrong. 0x90 must be followed by two numbers in the
> 0..0x7f range.
>
> > >
> > > Clearly, the midi events are corrupted by the usb interface. Does the
> > > midi interface claim to be "class compliant"? does it come with
> > > drivers for MacOS or Windows?
> >
> > It was advertized as class compliant, and it just came the cable, no 
> > drivers.
> > But as I said, it was el-chepo from ebay not even 3 EUR incl. shipping from 
> > China.
> >
>
> do you know if it works on other operating systems?

got Ubuntu installed on a notebook, installed lmms, connected the system-1
to it via MIDI-to-USB. Similar as under OpenBSD, some notes don't play, others
have wrong pitch, or only play after second or third push of the note.

Thanks for all the hints, but in the end at least that cable seems to be
just broken.

Sebastian

Re: acme-client new cert error

[justina colmena]

On Sat, 26 May 2018 09:14:35 -0700
Scott Vanderbilt  wrote:

> On 5/26/2018 4:54 AM, Stuart Henderson wrote:
> 
> > aeneas.datagenic.com doesn't respond on port 80. (And if I can't
> > fetch it, letsencrypt's checkers are also unlikely to be able to).
> > 
> > Firewall issue?  
> 
> Oh, FFS.
> 
> Yes. A silly pf rule blocking incoming traffic from outside my LAN
> that I overlooked when I first considered that idea, but then
> discarded on account of the error message. Which, to me, at least,
> does not in any reasonable way point to a connection problem.
> 
> So, thanks very much for applying the clue stick. And, to whom may I 
> suggest that the misleading error message from acme-client be changed
> to something actually resembling the problem it has encountered?
> 

I had a little trouble with acme-client and was discussing it over here

https://community.letsencrypt.org/t/acme-client-on-openbsd-6-3/61785

My solution involved putting in a CAA ("Certificate Authority
Authorization") record for the domain for which I was requesting the
certficate. Of course letsencrypt is supportive of open standards and
working with other clients, etc., but they do seem to have their own
client, "certbot", which is available in ports and packages on OpenBSD.

 * https://letsencrypt.org/
 * https://certbot.eff.org/

Yes, it would be unreasonable to expect too much support from the
"certbot" folks on OpenBSD's acme-client, because they aren't the ones
who are responsible for developing acme-client, although is a little
curious to me that "certbot" has such a close relationship with
"letsencrypt".

[justina@blanco ~]$ dig amarillo.colmena.biz caa

; <<>> DiG 9.11.3-RedHat-9.11.3-6.fc28 <<>> amarillo.colmena.biz caa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55341
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;amarillo.colmena.biz.IN  CAA

;; ANSWER SECTION:
amarillo.colmena.biz.  38362  IN  CAA  0 issue "letsencrypt.org"
amarillo.colmena.biz.  38362  IN  CAA  0 issuewild ";"

;; Query time: 570 msec
;; SERVER: 192.168.44.1#53(192.168.44.1)
;; WHEN: Sat May 26 18:25:19 GMT 2018
;; MSG SIZE  rcvd: 107

[justina@blanco ~]$

Re: smtpd.conf new grammar

[Leighton Sheppard]

On Thu, May 24, 2018 at 02:18:56PM +0200, Gilles Chehade wrote:
> Hi,
> 
> I have just committed a major change in smtpd that'll require smtpd.conf
> to be rewritten before your update to the new code.
> 
> The new grammar is not TOO different from the former one, a lot of stuff
> remains exactly identical, but the ruleset is now split into two parts:
> 
> - a named action
> - a matching pattern which is associated to a named action
> 
> In effect, instead of having:
> 
> accept from any for local deliver to mbox
> 
> 
> You will have:
> 
> action "my_action" mbox
> 
> match from any for local action "my_action"
> 
> 
> There are a few keywords that have been shortened too but all in all the
> switch to new grammar is easy, the smtpd.conf man page has been updated,
> and it continues being improved thanks to ingo and jmc.
> 
> The man page by itself should be enough to do the switch.
> 
> Since this is quite a major change, I also wrote a post that describes a
> conversion of my own complex smtpd.conf to new grammar:
> 
> https://poolp.org/posts/2018-05-21/switching-to-opensmtpd-new-config/
> 
> 
> I have also compiled a list of directives recognized by the parser which
> I intend to use for regress tests:
> 
> https://poolp.org/~gilles/smtpd.conf
> 
> 
> As for the reasons behind the change they are numerous, I explained some
> at EuroBSDCon 2017, I explained some on my blog, the bottom line is that
> while one-line rules were apparently an awesome idea, they were actually
> a design error that had consequences on pretty much the entire daemon.
> 
> We didn't realize it until a few months ago, we tried hard to maintain a
> one-line rule grammar but it became more and more obvious that this just
> isn't doable without creating issues and unnecessary complexity.
> 
> The new grammar is cleaner, it helped remove ~700 lines of complex code,
> made the handling of .forward files as well much safer, removed a lot of
> very unpleasant side-effects most people didn't even realize existed ...
> until they hit that one case for which we had no way to work around.
> 
> 
> Anyways,
> looking forward for you to test and report how it works for you :-)
> 
> 
> -- 
> Gilles Chehade
> 
> https://www.poolp.org  @poolpOrg
> 

Hi,

I upgraded my laptop and VM both to the latest snapshot this morning, and 
migrated the configuration for smtpd.conf to the new grammar. No issues 
to report and I like the new format!

Regards,
Leighton

Re: connect two midi devices

[Sebastian Reitenbach]

Sent from my iPhone

> On 26. May 2018, at 11:12, Alexandre Ratchov  wrote:
> 
>> On Sat, May 26, 2018 at 12:10:03AM +0200, Sebastian Reitenbach wrote:
>> Am Freitag, Mai 25, 2018 22:22 CEST, Alexandre Ratchov  
>> schrieb:
>> 
>>> On Fri, May 25, 2018 at 10:22:26AM +0200, Sebastian Reitenbach wrote:
 Hi Alexandre,
 
 Am Freitag, Mai 25, 2018 08:41 CEST, Alexandre Ratchov  
 schrieb:
 
> On Fri, May 25, 2018 at 12:21:18AM +0200, Alexandre Ratchov wrote:
>> 
>> Maybe, but unlikely. If the device attaches, generally it works. Show
>> what's received on midi2 when you type on the keyboard or do any other
>> simple actions.
>> 
> 
> fwiw, here's a small utility that I use very often to debug & connect
> MIDI ports.
> 
> http://caoua.org/alex/obsd/midicat.tar.gz
> 
> To connect two rmidi/2 -> rmidi/1 and dump the data on stderr, run:
> 
> midicat -d -q rmidi/2 -q rmidi/1
 
 Actually, that midicat seems to do the trick. When I run it in debug, and 
 press some keys on the
 system-1, output looks like:
 
 f8
 f8
 fe
 f8
 f8
 f8
 90 80 9b
>>> 
>>> ^^^
>>> 
>>> these 3 bytes make no sense. The status byte 0x90 is correct but the
>>> two args are wrong. This is when you pressed the key, right?
>>> 
 ...
 90 9b b2
>>> 
>>> These are also wrong, and this is when you released the key, right?
>>> Interestingly the 0x9b is repeated.
>>> 
>> 
>> f8
>> f8
>> f8
>> 90 80 34
>> 90 40 f8
>>  released key
> 
> This one is cleary wrong. 0x90 must be followed by two numbers in the
> 0..0x7f range.
> 
>>> 
>>> Clearly, the midi events are corrupted by the usb interface. Does the
>>> midi interface claim to be "class compliant"? does it come with
>>> drivers for MacOS or Windows?
>> 
>> It was advertized as class compliant, and it just came the cable, no drivers.
>> But as I said, it was el-chepo from ebay not even 3 EUR incl. shipping from 
>> China.
>> 
> 
> do you know if it works on other operating systems?

Don’t know, I need to dig out an unused notebook and install some Linux on it.

Sebastian 

Re: acme-client new cert error

[Scott Vanderbilt]

On 5/26/2018 4:54 AM, Stuart Henderson wrote:


aeneas.datagenic.com doesn't respond on port 80. (And if I can't
fetch it, letsencrypt's checkers are also unlikely to be able to).

Firewall issue?


Oh, FFS.

Yes. A silly pf rule blocking incoming traffic from outside my LAN that 
I overlooked when I first considered that idea, but then discarded on 
account of the error message. Which, to me, at least, does not in any 
reasonable way point to a connection problem.


So, thanks very much for applying the clue stick. And, to whom may I 
suggest that the misleading error message from acme-client be changed to 
something actually resembling the problem it has encountered?

More fun with the new smtpd.conf syntax

[Liviu Daia]

I'm trying to upgrade a trivial config:

table aliases file:/etc/mail/aliases

listen on lo0 inet4
limit mta inet4
bounce-warn 1d

accept from local for any relay via 192.168.7.2

The aliases file contains, aside from the defaults:

root:   daia
daia:   daia@[192.168.7.2]

Basically this machine shouldn't receive mail, and all messages
generated locally should be relayed to a certain user at some other
machine.  This has worked well for a few years.

My naive attempt to achieve the same with the new syntax doesn't
work:

table aliases file:/etc/mail/aliases

listen on lo0 inet4
set bounce warn-interval 1d

action "local" mbox alias 
action "relay" relay host 192.168.7.2

match for local action "local"
match from local for any action "relay"

This delivers locally generated messages to the local user "daia",
the forward alias "daia@[192.168.7.2]" is ignored.

Commenting out the "match for local" line doesn't work either: it
relays messages to the remote machine, but obviously aliases are not
resolved.

Other combinations involving expand-only, forward-only, and virtual
are mentioned by name, without being actually documented in any obvious
place.  So, is there any way to make this work again?

Regards,

Liviu Daia

Re: Checking my new smtpd.conf syntax

[Walter Alejandro Iglesias]

On Sat, May 26, 2018 at 12:35:57PM +0200, Walter Alejandro Iglesias wrote:
> On Sat, May 26, 2018 at 08:15:18AM +0200, Gilles Chehade wrote:
> > > Gilles, I also saw the "ca" directive.  I've been using the acme
> > > certificates in pki directives, can I use them in the "ca" directive
> > > too? (any advantage in doing this?)
> > > 
> > 
> > don't touch a knob if you don't KNOW that you absolutely need it.
> > 
> > I know why some people would like to use a custom CA certificate instead
> > of the one shipped with the system, I don't know why YOU should do it so
> > if you are asking I can only guess you are going to break your setup.
> 
> First of all, each one is responsible of what they do with their system,
> it's the nature of free software, isn't it?  Don't be afraid, if I break
> my setup I won't sue you. :-)
> 
> In the past I used the defunct StartSSL(TM) certificates with Apache and
> Sendmail during years.  In the case of a mail server I thought that, by
> logic, to present something that certificates your identity (what a CA
> is for, isn't it?) should be one among the more acceptable ways to avoid
> your messages be considered SPAM.
> 
> What I'm not clear about is what Let's Encrypt does (differently).  And,
> logically, I'm not clear about what your software does in this case.
> And over all I'm not clear about (and probably nobody is at this stage)
> what mail servers do and why with their SPAM filters.  That was the aim
> of my question.
> 
> By the way, your messages got to my server but not to misc@ (at least I
> can't not read them through gmane), I guess they got trapped in spamd
> daemon.

Let me add something more about what I know.

Each software (i.e. apache, ngnix, uw-imap, sendmail, etc) requires a
different setup to get the certificates working.  In some cases you need
to put chain and cert in one file, in others (uw-imap) you need to
include the key in a same one file.

I just expected you could tell me (or point me where this is documented)
what to do in opensmptd case.  The explanaintion in starttls(8) isn't
enough.

For example, what does the smptd.conf "ca" directive expect?, a root
certificates bundle?  Intermediate certificates?  What does the software
use in case you don't set this option?, the system provided
/etc/ssl/cert.pem?

I'll tell you what I been doing so far.  When time ago I started using
opensmtpd with the certs downloaded with acme-client, *after some trial
and error* I got it working with this set up:

Here I use the "full chain" certificate:

  pki $server cert "/etc/ssl/server.crt"

Here the key:

  pki $server key "/etc/ssl/private/server.key"

/usr/X11R6/bin/xset linked to missing libXfontcache.so.5.0

[Zé Loff]

On a vanilla amd64-current fresh install, /usr/X11R6/bin/xset seems to
be linked to libXfontcache.so.5.0, which I believe was recently dropped
from the install sets.  This (obviously) makes xset fail on start.


pagurus# xset
ld.so: xset: can't load library 'libXfontcache.so.5.0'
Killed
pagurus# ls /usr/X11R6/lib/libXfontcache.so.5.0
ls: /usr/X11R6/lib/libXfontcache.so.5.0: No such file or directory


OpenBSD 6.3-current (GENERIC) #44: Thu May 24 19:18:04 MDT 2018 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 520093696 (496MB)
avail mem = 496361472 (473MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz, 159.86 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,RDSEED,ADX,SMAP,CLFLUSHOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
pvbus0 at mainbus0: OpenBSD
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "OpenBSD VMM Host" rev 0x00
virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00
viornd0 at virtio0
virtio0: irq 3
virtio1 at pci0 dev 2 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio1
scsibus1 at vioblk0: 2 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3
0/direct fixed
sd0: 4096MB, 512 bytes/sector, 8388608 sectors
virtio1: irq 5
virtio2 at pci0 dev 3 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk1 at virtio2
scsibus2 at vioblk1: 2 targets
sd1 at scsibus2 targ 0 lun 0:  SCSI3
0/direct fixed
sd1: 360MB, 512 bytes/sector, 738240 sectors
virtio2: irq 6
virtio3 at pci0 dev 4 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio3: address 0a:00:10:17:18:92
virtio3: irq 7
virtio4 at pci0 dev 5 function 0 "OpenBSD VMM Control" rev 0x00
vmmci0 at virtio4
virtio4: irq 9
isa0 at mainbus0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16450, no fifo
com0: console
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on sd0a (281a39d09c7575bc.a) swap on sd0b dump on sd0b


-- 
 

Re: acme-client new cert error

[Stuart Henderson]

On 2018-05-25, Scott Vanderbilt  wrote:
> I'm having difficulty creating a new SSL cert for a virtual host I'm 
> just standing up for the first time. I get the following error on 
> successive attempts:
>
> urn:acme:error:unauthorized
> Error creating new cert :: authorizations for these names not found or 
> expired: aeneas.datagenic.com
>
> I've verified it's not a web server access issue, as I am able to 
> successfully retrieve a static HTML file from the challenge directory
>
>     aeneas$ curl 
> http://aeneas.datagenic.com/.well-known/acme-challenge/test.html
>     Foo
>     aeneas$

I'm not able to successfully retrieve one from that address,
aeneas.datagenic.com doesn't respond on port 80. (And if I can't
fetch it, letsencrypt's checkers are also unlikely to be able to).

Firewall issue?

Re: Checking my new smtpd.conf syntax

[Walter Alejandro Iglesias]

On Sat, May 26, 2018 at 08:15:18AM +0200, Gilles Chehade wrote:
> > Gilles, I also saw the "ca" directive.  I've been using the acme
> > certificates in pki directives, can I use them in the "ca" directive
> > too? (any advantage in doing this?)
> > 
> 
> don't touch a knob if you don't KNOW that you absolutely need it.
> 
> I know why some people would like to use a custom CA certificate instead
> of the one shipped with the system, I don't know why YOU should do it so
> if you are asking I can only guess you are going to break your setup.

First of all, each one is responsible of what they do with their system,
it's the nature of free software, isn't it?  Don't be afraid, if I break
my setup I won't sue you. :-)

In the past I used the defunct StartSSL(TM) certificates with Apache and
Sendmail during years.  In the case of a mail server I thought that, by
logic, to present something that certificates your identity (what a CA
is for, isn't it?) should be one among the more acceptable ways to avoid
your messages be considered SPAM.

What I'm not clear about is what Let's Encrypt does (differently).  And,
logically, I'm not clear about what your software does in this case.
And over all I'm not clear about (and probably nobody is at this stage)
what mail servers do and why with their SPAM filters.  That was the aim
of my question.

By the way, your messages got to my server but not to misc@ (at least I
can't not read them through gmane), I guess they got trapped in spamd
daemon.


> 
> 
> -- 
> Gilles Chehade
> 
> https://www.poolp.org  @poolpOrg


Walter

Re: connect two midi devices

[Alexandre Ratchov]

On Sat, May 26, 2018 at 12:10:03AM +0200, Sebastian Reitenbach wrote:
> Am Freitag, Mai 25, 2018 22:22 CEST, Alexandre Ratchov  
> schrieb:
> 
> > On Fri, May 25, 2018 at 10:22:26AM +0200, Sebastian Reitenbach wrote:
> > > Hi Alexandre,
> > >
> > > Am Freitag, Mai 25, 2018 08:41 CEST, Alexandre Ratchov  
> > > schrieb:
> > >
> > > > On Fri, May 25, 2018 at 12:21:18AM +0200, Alexandre Ratchov wrote:
> > > > >
> > > > > Maybe, but unlikely. If the device attaches, generally it works. Show
> > > > > what's received on midi2 when you type on the keyboard or do any other
> > > > > simple actions.
> > > > >
> > > >
> > > > fwiw, here's a small utility that I use very often to debug & connect
> > > > MIDI ports.
> > > >
> > > > http://caoua.org/alex/obsd/midicat.tar.gz
> > > >
> > > > To connect two rmidi/2 -> rmidi/1 and dump the data on stderr, run:
> > > >
> > > > midicat -d -q rmidi/2 -q rmidi/1
> > >
> > >  Actually, that midicat seems to do the trick. When I run it in debug, 
> > > and press some keys on the
> > > system-1, output looks like:
> > >
> > > f8
> > > f8
> > > fe
> > > f8
> > > f8
> > > f8
> > > 90 80 9b
> >
> > ^^^
> >
> > these 3 bytes make no sense. The status byte 0x90 is correct but the
> > two args are wrong. This is when you pressed the key, right?
> >
> > > ...
> > > 90 9b b2
> >
> > These are also wrong, and this is when you released the key, right?
> > Interestingly the 0x9b is repeated.
> >
> 
> f8
> f8
> f8
> 90 80 34
> 90 40 f8
>  released key

This one is cleary wrong. 0x90 must be followed by two numbers in the
0..0x7f range.

> >
> > Clearly, the midi events are corrupted by the usb interface. Does the
> > midi interface claim to be "class compliant"? does it come with
> > drivers for MacOS or Windows?
> 
> It was advertized as class compliant, and it just came the cable, no drivers.
> But as I said, it was el-chepo from ebay not even 3 EUR incl. shipping from 
> China.
> 

do you know if it works on other operating systems?

Re: opensmtpd / ldap unreliable

[Gilles Chehade]

On Thu, May 24, 2018 at 11:45:40AM -0700, Paul B. Henson wrote:
> > From: Gilles Chehade
> > Sent: Wednesday, May 23, 2018 1:20 PM
> > 
> > That's bad but could easily be fixed if you want to help us
> 
> So I dropped in the latest table-ldap from git, and it still failed
> authentications after an LDAP server outage. It looks like the check is only
> in the table_ldap_check function? I'm not sure what that's for, but it
> doesn't seem to be called at all when doing authentication. I added a
> similar check into the table_ldap_lookup function, and also had to reorder
> the functions  in the file a bit due to errors like this:
> 
> table_ldap.c:92:15: warning: implicit declaration of function 'ldap_open' is
> invalid in C99 
>   [-Wimplicit-function-declaration]   
> 
> Afterwards, opensmtpd successfully reconnected to LDAP and performed
> authentication after an LDAP outage :).
> 
> users[14726]: debug: table_ldap: ldap_query:
> filter=(&(objectClass=uidObject)(uid=henson)), ret=0
> users[14726]: debug: table-ldap: reconnecting
> users[14726]: info: table-ldap: closed previous connection
> users[14726]: debug: ldap server accepted credentials
> users[14726]: debug: table_ldap: ldap_query:
> filter=(&(objectClass=uidObject)(uid=henson)), ret=1
> 
> 
> Here's what my changes currently are. I can submit a pull request on github
> if you'd like. Thanks.
> 

please do so we have more people able to test

I'll review shortly



> diff --git a/extras/tables/table-ldap/table_ldap.c
> b/extras/tables/table-ldap/table_ldap.c
> index 88c9ffd..9d20526 100644
> --- a/extras/tables/table-ldap/table_ldap.c
> +++ b/extras/tables/table-ldap/table_ldap.c
> @@ -74,45 +74,6 @@ table_ldap_update(void)
> return 1;
>  }
>  
> -static int
> -table_ldap_check(int service, struct dict *params, const char *key)
> -{
> -   int ret;
> -
> -   switch(service) {
> -   case K_ALIAS:
> -   case K_DOMAIN:
> -   case K_CREDENTIALS:
> -   case K_USERINFO:
> -   case K_MAILADDR:
> -   if ((ret = ldap_run_query(service, key, NULL, 0)) >= 0) {
> -   return ret;
> -   }
> -   log_debug("debug: table-ldap: reconnecting");
> -   if (!(ret = ldap_open())) {
> -   log_warnx("warn: table-ldap: failed to connect");
> -   }
> -   return ret;
> -   default:
> -   return -1;
> -   }
> -}
> -
> -static int
> -table_ldap_lookup(int service, struct dict *params, const char *key, char
> *dst, size_t sz)
> -{
> -   switch(service) {
> -   case K_ALIAS:
> -   case K_DOMAIN:
> -   case K_CREDENTIALS:
> -   case K_USERINFO:
> -   case K_MAILADDR:
> -   return ldap_run_query(service, key, dst, sz);
> -   default:
> -   return -1;
> -   }
> -}
> -
>  static int
>  table_ldap_fetch(int service, struct dict *params, char *dst, size_t sz)
>  {
> @@ -361,6 +322,32 @@ err:
> return 0;
>  }
>  
> +static int
> +table_ldap_lookup(int service, struct dict *params, const char *key, char
> *dst, size_t sz)
> +{
> +   int ret;
> +
> +   switch(service) {
> +   case K_ALIAS:
> +   case K_DOMAIN:
> +   case K_CREDENTIALS:
> +   case K_USERINFO:
> +   case K_MAILADDR:
> +   if ((ret = ldap_run_query(service, key, dst, sz)) > 0) {
> +   return ret;
> +   }
> +   log_debug("debug: table-ldap: reconnecting");
> +   if (!(ret = ldap_open())) {
> +   log_warnx("warn: table-ldap: failed to connect");
> +   return ret;
> +   }
> +   return ldap_run_query(service, key, dst, sz);
> +   default:
> +   return -1;
> +   }
> +}
> +
> +
>  static int
>  ldap_query(const char *filter, char **attributes, char ***outp, size_t n)
>  {
> @@ -498,6 +485,31 @@ end:
> return ret;
>  }
>  
> +static int
> +table_ldap_check(int service, struct dict *params, const char *key)
> +{
> +   int ret;
> +
> +   switch(service) {
> +   case K_ALIAS:
> +   case K_DOMAIN:
> +   case K_CREDENTIALS:
> +   case K_USERINFO:
> +   case K_MAILADDR:
> +   if ((ret = ldap_run_query(service, key, NULL, 0)) >= 0) {
> +   return ret;
> +   }
> +   log_debug("debug: table-ldap: reconnecting");
> +   if (!(ret = ldap_open())) {
> +   log_warnx("warn: table-ldap: failed to connect");
> +   }
> +   return ret;
> +   default:
> +   return -1;
> +   }
> +}
> +
> +
>  int
>  main(int argc, char **argv)
>  {
> 
> 

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

Re: Checking my new smtpd.conf syntax

[Gilles Chehade]

On Fri, May 25, 2018 at 09:37:07PM +0200, Walter Alejandro Iglesias wrote:
> On Fri, May 25, 2018 at 03:58:59PM +0300, Consus wrote:
> > On 14:31 Fri 25 May, Gilles Chehade wrote:
> > > On Fri, May 25, 2018 at 02:20:50PM +0200, Walter Alejandro Iglesias wrote:
> > > > Could someone tell me if my changes below are OK. :-)
> > > > 
> > > > The part I'm not clear is I read in current.html remote authenticated
> > > > users need a explicit rule.  Do I need to add some "match auth" rule?
> > > > 
> > > 
> > > yes.
> > > 
> > > before, "from local" would match authenticated users as if they had sent
> > > mail from the local machine but this led to being unable to express some
> > > setups where depending on the source you want to relay to different hubs
> > > even though users are authenticated.
> > > 
> > > 
> > > With this:
> > > 
> > > > match from local for local apply local_users
> > > > match from any for domain  virtual  apply 
> > > > local_users
> > > > match from local sender  for any apply remote_users
> > > 
> > > you need an additonal rule such as:
> > > 
> > > match auth from any sender  for any apply remote_users
> > > 
> > > 
> > > because:
> > > 
> > > > #accept from local sender  for any relay
> > > 
> > > no longer matches authenticated users
> > 
> > Ain't it "action local_users" instead of "apply local_users"? The man
> > page states "action".
> 
> I took the "apply" from here:
> 
>   https://undeadly.org/cgi?action=article;sid=20180430122930
> 
> Now reading this:
> 
>   https://poolp.org/posts/2018-05-21/switching-to-opensmtpd-new-config/
> 
> I see I also have to change the "certificate" keyword to "cert" here:
> 
>   pki $server cert "/etc/ssl/server.crt"
> 
> 
> Gilles, I also saw the "ca" directive.  I've been using the acme
> certificates in pki directives, can I use them in the "ca" directive
> too? (any advantage in doing this?)
> 

don't touch a knob if you don't KNOW that you absolutely need it.

I know why some people would like to use a custom CA certificate instead
of the one shipped with the system, I don't know why YOU should do it so
if you are asking I can only guess you are going to break your setup.


-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

Re: opensmtpd / ldap unreliable

[Christophe Simon]

Hello,

Thanks for this patch! I'm setting up a similar configuration. I'll have 
a test also.


Regards.

Christophe

Le 05/24/18 à 20:45, Paul B. Henson a écrit :

From: Gilles Chehade
Sent: Wednesday, May 23, 2018 1:20 PM

That's bad but could easily be fixed if you want to help us


So I dropped in the latest table-ldap from git, and it still failed
authentications after an LDAP server outage. It looks like the check is only
in the table_ldap_check function? I'm not sure what that's for, but it
doesn't seem to be called at all when doing authentication. I added a
similar check into the table_ldap_lookup function, and also had to reorder
the functions  in the file a bit due to errors like this:

table_ldap.c:92:15: warning: implicit declaration of function 'ldap_open' is
invalid in C99
   [-Wimplicit-function-declaration]

Afterwards, opensmtpd successfully reconnected to LDAP and performed
authentication after an LDAP outage :).

users[14726]: debug: table_ldap: ldap_query:
filter=(&(objectClass=uidObject)(uid=henson)), ret=0
users[14726]: debug: table-ldap: reconnecting
users[14726]: info: table-ldap: closed previous connection
users[14726]: debug: ldap server accepted credentials
users[14726]: debug: table_ldap: ldap_query:
filter=(&(objectClass=uidObject)(uid=henson)), ret=1


Here's what my changes currently are. I can submit a pull request on github
if you'd like. Thanks.

diff --git a/extras/tables/table-ldap/table_ldap.c
b/extras/tables/table-ldap/table_ldap.c
index 88c9ffd..9d20526 100644
--- a/extras/tables/table-ldap/table_ldap.c
+++ b/extras/tables/table-ldap/table_ldap.c
@@ -74,45 +74,6 @@ table_ldap_update(void)
 return 1;
  }
  
-static int

-table_ldap_check(int service, struct dict *params, const char *key)
-{
-   int ret;
-
-   switch(service) {
-   case K_ALIAS:
-   case K_DOMAIN:
-   case K_CREDENTIALS:
-   case K_USERINFO:
-   case K_MAILADDR:
-   if ((ret = ldap_run_query(service, key, NULL, 0)) >= 0) {
-   return ret;
-   }
-   log_debug("debug: table-ldap: reconnecting");
-   if (!(ret = ldap_open())) {
-   log_warnx("warn: table-ldap: failed to connect");
-   }
-   return ret;
-   default:
-   return -1;
-   }
-}
-
-static int
-table_ldap_lookup(int service, struct dict *params, const char *key, char
*dst, size_t sz)
-{
-   switch(service) {
-   case K_ALIAS:
-   case K_DOMAIN:
-   case K_CREDENTIALS:
-   case K_USERINFO:
-   case K_MAILADDR:
-   return ldap_run_query(service, key, dst, sz);
-   default:
-   return -1;
-   }
-}
-
  static int
  table_ldap_fetch(int service, struct dict *params, char *dst, size_t sz)
  {
@@ -361,6 +322,32 @@ err:
 return 0;
  }
  
+static int

+table_ldap_lookup(int service, struct dict *params, const char *key, char
*dst, size_t sz)
+{
+   int ret;
+
+   switch(service) {
+   case K_ALIAS:
+   case K_DOMAIN:
+   case K_CREDENTIALS:
+   case K_USERINFO:
+   case K_MAILADDR:
+   if ((ret = ldap_run_query(service, key, dst, sz)) > 0) {
+   return ret;
+   }
+   log_debug("debug: table-ldap: reconnecting");
+   if (!(ret = ldap_open())) {
+   log_warnx("warn: table-ldap: failed to connect");
+   return ret;
+   }
+   return ldap_run_query(service, key, dst, sz);
+   default:
+   return -1;
+   }
+}
+
+
  static int
  ldap_query(const char *filter, char **attributes, char ***outp, size_t n)
  {
@@ -498,6 +485,31 @@ end:
 return ret;
  }
  
+static int

+table_ldap_check(int service, struct dict *params, const char *key)
+{
+   int ret;
+
+   switch(service) {
+   case K_ALIAS:
+   case K_DOMAIN:
+   case K_CREDENTIALS:
+   case K_USERINFO:
+   case K_MAILADDR:
+   if ((ret = ldap_run_query(service, key, NULL, 0)) >= 0) {
+   return ret;
+   }
+   log_debug("debug: table-ldap: reconnecting");
+   if (!(ret = ldap_open())) {
+   log_warnx("warn: table-ldap: failed to connect");
+   }
+   return ret;
+   default:
+   return -1;
+   }
+}
+
+
  int
  main(int argc, char **argv)
  {