Does the OpenSMTPD project have any plans to from OpenSSL to LibReSSL?
Just curious if OpenSMTPD has any plans to swap out OpenSSL for LibReSSL once the latter has been deemed stable enough. -- Seth I 3 nicely trimmed email replies -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Invalid command: Pipelining not supported
On Thu, 06 Nov 2014 23:48:10 -0800, Gilles Chehade gil...@poolp.org wrote: What this means is that the mail client used by your webapp has sent two SMTP commands in a row without reading the server reply in-between. Confirmed with the web app developer that this was a bug with their TLS implementation in that particular version of the product. -- Seth I 3 nicely trimmed email replies -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
excluding sender IPs in email headers
I was inspired by the article below and want to implement this on the OpenSMTPD servers I administer. Is this possible? Stop Including Sender IPs in Email Headers https://blog.ageispolis.net/page/4/ -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: snapshot build against LibreSSL 2.1.3 error: previous declaration of 'SSL_CTX_use_certificate_chain' was here
I think this particular issue might have been fixed by commit https://github.com/OpenSMTPD/OpenSMTPD/commit/8bca141233921dcfee7b1fc734d376adb70ef044. Can't be sure though because the build doesn't even get far enough to compile tortls.c. It fails earlier with this error: -compare -Wformat-security -Wno-pointer-sign -fno-strict-aliasing -fno-builtin-memset -MT bsd-misc.o -MD -MP -MF .deps/bsd-misc.Tpo -c -o bsd-misc.o bsd-misc.c bsd-misc.c: In function 'nanosleep': bsd-misc.c:146: error: expected ';' before '(' token bsd-misc.c:165: error: expected ';' before 'return' *** [bsd-misc.o] Error code 1 Stop in /usr/local/src/opensmtpd/openbsd-compat. *** [all-recursive] Error code 1 Stop in /usr/local/src/opensmtpd. *** [all] Error code 1 Stop in /usr/local/src/opensmtpd. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: a few more questions
On Mon, 19 Jan 2015 15:14:14 -0800, Edgar Pettijohn ed...@pettijohn-web.com wrote: http://www.mail-archive.com/misc%40opensmtpd.org/msg01427.html That gives the following error: # /usr/sbin/smtpd -d /etc/mail/smtpd.conf:16: invalid use of table dynamic:0 as HOSTNAMES parameter Looks like you're getting the same error as posted of the 2nd mailing list thread I linked to above ^^. Might be prudent to file a bug report on github. https://github.com/OpenSMTPD/OpenSMTPD/issues -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: a few more questions
On Sun, 18 Jan 2015 20:20:19 -0800, Seth l...@sysfu.com wrote: https://github.com/OpenSMTPD/OpenSMTPD/issues/376 Related email threads http://www.mail-archive.com/misc%40opensmtpd.org/msg00625.html Declare your listener with a hostnames table and declare a pki entry for every domain that should be supported by SNI: pki foo.bar ... pki bar.baz ... listen on [...] tls hostnames { foo.bar, bar.baz } http://www.mail-archive.com/misc%40opensmtpd.org/msg01427.html -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: auth/auth-optional
On Sun, 18 Jan 2015 08:39:01 -0800, Edgar Pettijohn ed...@pettijohn-web.com wrote: I've been lurking on the list for a while, and I'm finally getting close on my config to replace postfix/dovecot. However, I'm having some issues. I'm pretty sure I want to use auth in a listener context, but its not working out for me. I think you only need the auth-optional line is situations where you want to relay email through this server via SMTP 25/tcp from your own computer via a public IP address, and cannot setup the server to listen on the separate submission port 587/tcp. Also in the logs it shows Server certificate verification failed on session dcad1b1012daf5ab which doesn't sound good, This is not a show-stopper, it just means that whatever TLS certificate the mail server is presenting cannot be verified by the other SMTP endpoint involved. It looks like you are using self-signed certs so this is to be expected unless you setup your own CA (Certificate Authority) and then install your CA's root certificate on all computers involved. and finally the accept from any for any tls seems scary is that safe or does it need work? That options will force TLS encryption of outbound SMTP connections. If the remote mail server does not support TLS, message delivery will fail. You can test public mail servers for TLS support using these web sites. mxtoolbox.com starttls.info checktls.com -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Lavabit like encryption with OpenSMTPD
On Tue, 10 Feb 2015 04:47:38 -0800, Gilles Chehade gil...@poolp.org wrote: People actually open an account at Gmail/Yahoo/Microsoft because they do not give the slightest shit about these privacy concerns. They want mail that gets sent when pressing a button, and they want it so bad that even when most ISP provide an email address you can fetch with POP/IMAP, they go for Gmail/Yahoo/Microsoft because the webmail is simpler than dealing with the configuration of Outlook / Thunderbird. Get real, these people do not care about your concerns, they will go for the simplest solution and you will never convince them that they have to setup PGP, remember yet another passphrase for a keypair they need to be careful with, just so they can send an email... when the alternative can just be pressing a button. I think Gilles observations are borne out by reality. PGP is without question a powerful tool but it's a terrible tool IMO for anyone but the technically minded and OpSec disciplined. Clay Shirky wrote a great article that I always circle back to when I see these debates: The RIAA Succeeds Where the Cypherpunks Failed http://www.shirky.com/writings/riaa_encryption.html Long story short the 'Eat your peas' approach has been and continues to be a miserable failure. Gilles is right, the vast majority of the email using population does not give two shits about security or surveillance. This is no longer debatable two years after the Snowden leaks began. How many non-technical people do you know that have dropped their PRISM-approved email provider since then? Crikey, half the people on the mailing lists I subscribe to are still using gmail accounts, it's pathetic. If we want to live in a world where people have some semblance of computer security and protection from surveillance, the people writing the software must build these features into software products so that they are baked in, impossible to disable, fail closed, and completely transparent to the end user. Any other approach is doomed to failure as far as I can tell. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: relay via: No MX found for domain
On Wed, 11 Feb 2015 13:21:30 -0800, Meutel meu...@meutel.net wrote: I did some tests with a simple smtp.conf which relays everything via gmail, and with a public nameserver instead of my local one. table gmailcred file:/usr/local/etc/mail/gmailcred accept from local for any relay via tls+auth://gmailc...@smtp.gmail.com auth gmailcred as meu...@gmail.com With 5.4.2, it works. With 5.4.4, it fails: smtp-out: Failed to resolve MX for [relay:smtp.gmail.com,starttls,auth=gmailcred:gmailcred,mx]: No MX found for domain Same result with opensmtpd and libasr from ports. full logs with smtpd -vvv What's your /etc/resolv.conf look like? Have you tried plugging Google's DNS servers in there as a test? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: SSL: fatal access denied with opensmtpd on freebsd
On Sun, 15 Feb 2015 23:37:55 -0800, Hugo Osvaldo Barrera h...@barrera.io wrote: Any hints? My guess is that SSL is failing somewhere, but I don't know how to continue to track this down. Someone on the FreeBSD list suggested making sure that the CAs were installed, and they are - though I'm not sure it's 100% relevant. Try switching out OpenSSL with LibreSSL and see if you can reproduce the problem with that arrangement. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Virtual users with valid email addresses for usernames?
On Thu, 12 Feb 2015 19:18:45 -0800, Josh Kunz joshk...@me.com wrote: I'm trying to run an OpenSSMTPd + dovecot setup for two separate domains. I'd like to be able to assign passwords based on the user and the domain part of the address, and using actual email addresses as the user names helps with integrating with dovecot. I can create a userbase table where the user field is a standard email address, but since OpenSMTPd is only matching against the userbase using the user part of the address the userbase alone doesn't work. I thought that using a virtual user map might work, but since the user names on the right hand side of the table are valid email addresses it triggers a circular lookup. Is there any way I can users whose names are addresses? Yes you can. Granted, this is really more of a dovecot question, but since I had to figure out how to do the same thing on my own, and dovecot is in my opinion a natural companion to OpenSMTPD, I'm happy to help. The process is basically this: * Add a system account (and group) for a user called 'email' that will serve as the 'virtual mail' user with a (completely arbitrarily chosen) home directory of /var/vmaildir * Configure OpenSMTPD to deliver emails in Maildir format to that directory * Configure Dovecot to look in that same directory for email and authenticate IMAP/POP users against a plain text file containing usernames in the format u...@domain.tld and corresponding passwords Now for the relevant lines and changes in config files /etc/passwd --- email:7200::/var/vmaildir:nologin: /etc/group -- email:*:7200: /etc/mail/smptd.conf table vdoms /etc/mail/vdoms table vusers/etc/mail/vusers accept from any for domain vdoms virtual vusers deliver to maildir /var/vmaildir/%{dest.domain:lowercase}/%{dest.user:lowercase|strip}/mail/ /etc/dovecot/conf.d/10-auth.conf auth_mechanisms = plain !include auth-passwdfile.conf.ext /etc/dovecot/conf.d/10-mail.conf mail_home = /var/vmaildir/%d/%n mail_location = maildir:~/mail namespace inbox { inbox = yes } mail_uid = email mail_gid = email /etc/dovecot/conf.d/auth-passwdfile.conf.ext passdb { driver = passwd-file args = scheme=CRYPT username_format=%n /etc/dovecot/userdb/%d } userdb { driver = passwd-file args = username_format=%n /etc/dovecot/userdb/%d # Default fields that can be overridden by passwd-file default_fields = uid=email gid=email } /etc/dovecot/userdb/domain1.tld --- joeuser:{SHA512-CRYPT}pwhash-gobbletygook/var/vmaildir/domain1.tld/joeuser:/bin/nologin billybobuser:{SHA512-CRYPT}pwhash-gobbletygook/var/vmaildir/domain1.tld/billybobuser:/bin/nologin /etc/dovecot/userdb/domain2.tld --- sallyuser:{SHA512-CRYPT}pwhash-gobbletygook/var/vmaildir/domain2.tld/sallyuser:/bin/nologin Generate the SHA512-CRYPT pw hash string for each user with this command doveadm pw -s SHA512-CRYPT -p superpassword -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Mail archive
On Tue, 17 Feb 2015 06:45:43 -0800, Alan Gilson agil...@otcgc.com wrote: These are great, thanks folks. May I suggest that they be added to the auto-footer for the group? They're sort of common knowledge amongst most people that have been using mailing lists for a while, but I guess that doesn't really doesn't help newcomers. A concern would be, which ones to include? If you included all of them it would be too much clutter IMO. I think marc.info, gmane, and mail-archive are the most popular, but there's other like readlist.com and probably a host of others I am not aware of. Maybe it would be better to add any mailing list web archive links to this page rather than the email footer. https://opensmtpd.org/list.html -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: SSL: fatal access denied with opensmtpd on freebsd
On Mon, 16 Feb 2015 13:11:27 -0800, Hugo Osvaldo Barrera h...@barrera.io wrote: libressl.c:72:1: error: conflicting types for 'SSL_CTX_use_certificate_chain' SSL_CTX_use_certificate_chain(SSL_CTX *ctx, char *buf, off_t len) ^ /usr/local/include/openssl/ssl.h:1587:5: note: previous declaration is here int SSL_CTX_use_certificate_chain(SSL_CTX *ctx, void *buf, int len); ^ I noticed this being mentioned before, so I went back and found it: https://marc.info/?l=opensmtpd-miscm=142402080601260w=2 However, this did not resolve the issue for me, and the issue persists. I take it you're trying to build from source? I've run into the same issue. My workaround has been to build OpenSMTPD with LibreSSL dependency using ports, this works. Remove OpenSSL, and put this in /etc/make.conf: OPENSSL_PORT=security/libressl WITH_OPENSSL_PORT=yes OPENSSL_SHLIBVER=30 Then build using portmaster or whatever portmaster mail/opensmtpd -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Support for ECDSA CA server certificates
I'm in the process of switching out existing RSA Certificate Authority server certificates for ECDSA (Elliptical Curve DSA) ones. Are ECDSA certs supported by OpenSMTPD? Or does that depend completely on the chosen SSL library, i.e. OpenSSL, LibreSSL, BoringSSL, etc? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: SSL: fatal access denied with opensmtpd on freebsd
On Mon, 16 Feb 2015 14:42:12 -0800, Hugo Osvaldo Barrera h...@barrera.io wrote: Oh, this works with mail/opensmtpd, but *not* mail/opensmtpd-devel. Funny. Build worked, but the same initial issue still happens: Feb 16 22:40:00 hydrogen smtpd[43826]: smtp-in: New session 7530b8f4cbc97b60 from host hyperion.barrera.io [190.210.108.249] Feb 16 22:40:03 hydrogen smtpd[43826]: smtp-in: Disconnecting session 7530b8f4cbc97b60: IO error: error:14094419:SSL routines:SSL3_READ_BYTES:tlsv1 alert access denied So it doesn't seem an openssl vs libressl issue. Any other ideas? Maybe this means you should zero in on the SMTP client connecting from hyperion.barrera.io [190.210.108.249] as the source of the problem then? What computer or host did the log entry above come from? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: SSL: fatal access denied with opensmtpd on freebsd
On Mon, 16 Feb 2015 14:32:29 -0800, Hugo Osvaldo Barrera h...@barrera.io wrote: I hadn't been using portmaster (rather cd /usr/ports/mail/opensmtpd-devel make), but I got the same error using it too: Sorry, I should have clarified that it works on FreeBSD 9.3 with the OpenSMTPD 5.4.4 release and LibreSSL 2.1.3. I have not yet verified a successful ports build with the opensmptd-devel. Sometimes you run into problems where a dependency will not build against LibreSSL, python27 being a common one that comes to mind. In those cases I simply installed the dependency from packages, then resume the build. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Best way to relay mail to a server with intermittent connectivity
I administer an email system which uses a VPS running OpenSMTPD as the public facing bit. The VPS relays email to and from a separate OpenSMTPD mail server which is located on premises. We'll call this the 'local' server. The local server gets powered down every night, however this currently causes messages to back up on the VPS or 'public' server. When the local server comes back online in the morning, I have to log into the public relay server and use smtpctl to manually resume the route to the local server. Then a 'smtpctl schedule all' command must be run after which the backed up overnight email comes pouring in. This configuration is suboptimal for two reasons * It generates bounce and 'sending delayed' postmaster messages when the local server is down * It requires manual intervention to ensure speedy email delivery to the local server when it's powered back on. I've been thinking about adding another OpenSMTPD relay mail server at the local site, which is low power and can stay running all the time without issue. But this merely shifts the location of the mail pile-up from remote to local. Any mail gurus out there have a solid method for solving this problem? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Best way to relay mail to a server with intermittent connectivity
On Tue, 27 Jan 2015 17:22:43 -0800, Edgar Pettijohn ed...@pettijohn-web.com wrote: *bounce-warn* /n/{*s*|*m*|*h*|*d*}[, /.../] Specify the delays for which temporary failure reports must be generated when messages are stuck in the queue. For example: bounce-warn 1h, 6h, 2d will generate a failure report when an envelope is in the queue for more than one hour, six hours and two days. The default is 4h. Thanks, I caught that right after posting, of course. Dialed it back to 1d. Still need to solve the problem of scheduling that big morning dump. Of email. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Best way to relay mail to a server with intermittent connectivity
On Tue, 27 Jan 2015 20:18:04 -0800, Edgar Pettijohn ed...@pettijohn-web.com wrote: Still need to solve the problem of scheduling that big morning dump. Of email. cron That's not really going to work because the power-up time could vary between 2-4 hours. The mail needs to flow as soon as possible after powering on the local server. What would be ideal is for the relaying server to probe the local server every five minutes. As soon as an active SMTP port is discovered on the local server, the relay sends all queued emails. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Best way to relay mail to a server with intermittent connectivity
On Tue, 27 Jan 2015 21:11:52 -0800, Sunil Nimmagadda su...@nimmagadda.net wrote: I was wondering what if your local server is the primary MX and then your public server a backup MX. That way, whenever your local server is online the mails end up directly in it and your backup server automatically checks for primary server availability and routes accumulated mails once the primary MX is up. That's a good point. The VPS is configured as the sole MX host in this case because it runs OpenBSD + PF + Spamd + BGP, and serves as the spam choke-point. http://bgp-spamd.net/ To date, it has not been possible to stand up an OpenBSD host on premises to perform the same role, although I am pushing in this direction. Another idea I had was provision a low power embedded *nix device running OpenBSD/OpenSMTPD on premise that runs 24/7, and stores the 'night's catch' of emails locally on a flash device etc. When the main email server comes on line in the morning, startup scripts or whatever grabs or syncs the 'night's catch' in maildir format and transfers the whole bundle to the main 'local' email, server which runs Dovecot IMAP or some groupware like Zarafa. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: fatal: smtp_setup_events: ssl_setup failure: No such file or directory
On Sun, 01 Feb 2015 11:57:01 -0800, Michael bele...@bsdmail.de wrote: Rebuilding and reinstalling did not help. My current version is OpenSMTPD 5.4.2p1. smtpd -dv additionally shows the following: debug: SSL library error: ssl_setup: error:26078067:engine routines:ENGINE_LIST_ADD:conflicting engine id debug: SSL library error: ssl_setup: error:2606906E:engine routines:ENGINE_add:internal list error fatal: smtp_setup_events: ssl_setup failure: No such file or directory Are you able to post your smptd.conf config file(s) so we can inspect for potential problems? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Lavabit like encryption with OpenSMTPD
On Mon, 09 Feb 2015 13:28:03 -0800, brettm bre...@coiloptic.org wrote: On Mon, 9 Feb 2015 12:02:06 + skin...@britvault.co.uk (Craig Skinner) wrote: | | Neither can Goatmail, Snotmail, NSA, govt agencies, etc. | As far as we know, NSA etc cannot read other people's PGP encrypted mail. I think it is important to remember (and state clearly in these type of discussions) that this is an assumption that cannot be tested. It could be tested. All it would take is some people who are willing to use PGP encrypted communications to plan and carry out the assassination of a Five-eyes top ranking political or military figure. If NSA is able to break or circumvent the PGP encryption of these communications, the conspirators would be busted and the decrypted evidence used to put them away forever. It's known that five-eyes law enforcement was unable (or unwilling?) to catch the majority of a child pedophile ring as detailed here: https://grugq.github.io/blog/2013/12/01/yardbirds-effective-usenet-tradecraft/ So either intelligence agencies are willing to let pedophiles walk in order to protect operational secrets, or they can't crack PGP. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: How to debug Bad response: line too short?
On Mon, 16 Mar 2015 12:51:16 -0700, Eric Ripa e...@stickybit.se wrote: One of the failing envelopes are below (this one was sent using Apple mail but it doesn't seem to related as other clients are doing the same, seemingly random). Does the error occur frequently enough where you could perhaps grab some debug log output of it occurring? Have you made any attempts at reproducing it manually by feeding the same email through the system again? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: How to debug Bad response: line too short?
On Tue, 17 Mar 2015 01:17:24 -0700, Eric Ripa e...@stickybit.se wrote: Hard to say because after a retry or two the mail goes through so I will have to monitor it more closely. What traces are suitable for more verbose output of smtp-out? Simply smtp? I would start with 'smtpctl trace smtp' -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: OpenSMTPD build process does not recognize newer LibreSSL 2.1.4 libraries
Solved. This can be accomplished by setting environment variables with the make command, no configure script needed. Hat tip to Nick Mathewson from the Tor-relays mailing list for cluing me in to this method. $ sudo CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib make $ sudo make install $ ldd /usr/sbin/smtpd /usr/sbin/smtpd: StartEnd Type Open Ref GrpRef Name 1eb9f3d0 1eb9f41a9000 exe 10 0 /usr/sbin/smtpd 1ebc57315000 1ebc57721000 rlib 01 0 /usr/lib/libevent.so.4.1 1ebc36f81000 1ebc3738d000 rlib 01 0 /usr/lib/libutil.so.12.1 1ebc635bf000 1ebc63a1d000 rlib 01 0 /usr/local/lib/libssl.so.32.0 1ebc30b6b000 1ebc3113b000 rlib 02 0 /usr/local/lib/libcrypto.so.32.0 1ebc55e4c000 1ebc56274000 rlib 01 0 /usr/lib/libm.so.9.0 1ebca923e000 1ebca9653000 rlib 01 0 /usr/lib/libz.so.5.0 1ebc2a309000 1ebc2a7f2000 rlib 01 0 /usr/lib/libc.so.77.0 1ebbfad0 1ebbfad0 rtld 01 0 /usr/libexec/ld.so -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Virtual domains
On Thu, 12 Mar 2015 07:14:11 -0700, Gonzalo tengoandr...@gmail.com wrote: Mmm I have the same output.. El mar 11, 2015 11:31 PM, Seth l...@sysfu.com escribió: Offhand I would say this is probably more of Dovecot delivery configuration issue moreso than an OpenSMTPD one. I don't have much experience using or troubleshooting LDA or LMTP delivery unfortunately however so sorry I cannot be of more help. Try increasing verbosity of the Dovecot logs and watch them with a tail -f command as message deliveries are attempted, that might yield some clues. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Building dkimproxy on headless OpenBSD server with no X install sets
On Thu, 12 Mar 2015 09:54:52 -0700, Eric Ripa e...@stickybit.se wrote: I did the following on my X-less installation of OpenBSD 5.6 - downloaded the two sets xetc56.tgz and xbase56.tgz - added the sets according to the FAQ http://www.openbsd.org/faq/faq4.html#AddFileSet http://www.openbsd.org/faq/faq4.html#AddFileSet - created the symlink as follows: /usr/local/lib/X11/app-defaults - /etc/X11/app-defaults after doing so dkimproxy compiled and installed fine. I have not tried to remove the sets after installation however. Thank you, that solved the problem. Commands used $ ftp -o http://mirrors.sonic.net/openbsd/5.6/amd64/xetc56.tgz $ ftp -o http://mirrors.sonic.net/openbsd/5.6/amd64/xbase56.tgz $ sudo mv x*.tgz /; cd / $ sudo pax -rvzf xetc56.tgz -p e $ sudo pax -rvzf xbase56.tgz -p e $ sudo ln -s /etc/X11/app-defaults /usr/local/lib/X11/app-defaults $ cd /usr/ports/mail/dkimproxy/; sudo make install -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Building dkimproxy on headless OpenBSD server with no X install sets
On Thu, 12 Mar 2015 09:54:52 -0700, Eric Ripa e...@stickybit.se wrote: I have not tried to remove the sets after installation however. This command will remove the installation sets $ pax -vzf xetc56.tgz | awk '{ print $9}'| sudo xargs rm -rf Obviously test it out first somewhere where it won't trash your system. $ cd ~ $ sudo pax -rvzf xetc56.tgz -p e $ pax -vzf xetc56.tgz | awk '{ print $9}'| sudo xargs rm -rf It leaves a few skeleton directories but that's it. $ tree . |-- etc | |-- X11 | | |-- app-defaults | | |-- fs | | |-- twm | | |-- xdm | | |-- xinit | | `-- xsm | `-- fonts | `-- conf.d |-- usr -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Building dkimproxy on headless OpenBSD server with no X install sets
On Thu, 12 Mar 2015 11:13:53 -0700, Seth l...@sysfu.com wrote: On Thu, 12 Mar 2015 09:54:52 -0700, Eric Ripa e...@stickybit.se wrote: I have not tried to remove the sets after installation however. This command will remove the installation sets $ pax -vzf xetc56.tgz | awk '{ print $9}'| sudo xargs rm -rf Obviously test it out first somewhere where it won't trash your system. $ cd ~ $ sudo pax -rvzf xetc56.tgz -p e $ pax -vzf xetc56.tgz | awk '{ print $9}'| sudo xargs rm -rf Ahem, DO NOT try this against the xbase56.tgz set, I did and it trashed my system. Thank the cybergodz for disk snapshots. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Virtual domains
You might need to include a '${dest}' bit at the end of this smptd.conf accept statement: accept from any for domain dominios virtual usuariosv deliver to mda /usr/local/libexec/dovecot/dovecot-lda -f %{sender} -d %{dest} Found a related LDA accept statement example here: http://www.mail-archive.com/misc%40opensmtpd.org/msg00531.html -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Case sensitivity in automatic folder filtering by tag
On Sat, 28 Mar 2015 07:14:20 -0700, Kevin Chadwick m8il1i...@gmail.com wrote: If the filesystem supports case sensitivity then I can understand users expecting the current behaviour but it doesn't seem practical to me and I couldn't see a format specifier to lowercase deliveries to Maildir expanding to just TAG. When someone sends to a tag user+...@users.org and there is an existing folder Tag then it works great and I really love it, however I am sure I cannot always trust senders to keep the case correct. Am I missing a configuration tweak? I use the lowercase delivery option to address this issue. accept from blah blah blah deliver to maildir /var/vmaildir/%{dest.domain:lowercase}/%{dest.user:lowercase|strip}/mail/ -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: opensmtpd 5.4.4 in freebsd 9 jail
On Fri, 27 Feb 2015 01:47:16 -0800, Eric Faurot e...@faurot.net wrote: I'll think how asr can be improved in the way you suggest. In the meantime, the regression you see is actually due to the following change in smtpd. Try without it. Note that it will also retreive inet6 addresses, so you might want to add limit mta inet4 in smtpd.conf if inet6 is not routable on your system. I have these two lines in the smptd.conf for FreeBSD 9.3 jails running OpenSMTPD 5.4.4 and they're working fine. limit mta inet4 listen on lo0 inet4 Probably why I did not experience the same problem after upgrading. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Custom bounce messages for messages sent from NSA PRISM program providers
On Sun, 01 Mar 2015 20:36:17 -0800, Jason Barbier jab...@serversave.us wrote: Custom bounce messages are in the issue tracker as I recall. Maybe this is this ticket you're thinking of? Bounces without Bodies #429 [1] I was thinking it would be convenient to simply use SPF records published by Microsoft, Google, Yahoo and *cough* AOL to create the blacklist. That would probably make for the most current blacklist with the least amount of effort. The solution might very well lie in spamd. From the spamd-setup manual page [2] The spamd-setup utility sends blacklist data to spamd(8), as well as configuring mail rejection messages for blacklist entries. [1] https://github.com/OpenSMTPD/OpenSMTPD/issues/429 [2] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/spamd-setup.8?query=spamd-setupsec=8 -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: relay verify produces syntax error
On Mon, 04 May 2015 09:44:09 -0700, Daniel Pajonzeck li...@bitfactory.ws wrote: $ cat smtpd.conf table aliases { root=pi, pi=f...@domain.tld } accept for local alias aliases deliver to mbox accept for any relay verify $ smtpd -dv /usr/local/etc/smtpd.conf:3: syntax error If I change the 'verify' to 'tls' everything is working well. Looks like a bug!? accept for any relay verify should probably read accept for any relay tls verify instead. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: relay verify produces syntax error
On Tue, 05 May 2015 13:11:32 -0700, Daniel Pajonzeck li...@bitfactory.ws wrote: I haven't tested if invalid certificates are rejected, but surprisingly accept for any relay tls verify doesn't result in a syntax error. This contradicts the manpage: relay ... [tls | verify] and Note that the tls and verify options are mutually exclusive Correct me if I am wrong. You are correct this contradicts the man page. I just pulled example from one of my production configs. Can't even remember how I decided to set it that way to be honest, probably just experimentation. Someone who understands C code or one the devs will have to weight in to explain the observed behavior. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: relay verify produces syntax error
On Tue, 05 May 2015 13:11:32 -0700, Daniel Pajonzeck li...@bitfactory.ws wrote: It's a man page bug, found this in the list archives http://marc.info/?l=opensmtpd-miscm=142866776526943w=2 -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: [IMPORTANT] latest snapshot - certificate check failed issue
On Sun, 10 May 2015 23:56:36 -0700, Gilles Chehade gil...@poolp.org wrote: I have spotted a logic error which explains your issue. Without this, you cannot fallback to the default CA, you have to declare your CA explicitely. Can you apply the following diff ? diff --git a/smtpd/lka.c b/smtpd/lka.c index 31b7176..b621e10 100644 --- a/smtpd/lka.c +++ b/smtpd/lka.c @@ -689,7 +689,10 @@ lka_certificate_verify_resume(enum imsg_type type, struct ca_vrfy_req_msg *req) if (req-fallback) sca = dict_get(env-sc_ca_dict, *); cafile = sca ? sca-ca_cert_file : CA_FILE; - if (sca == NULL || ! lka_X509_verify(req, cafile, NULL)) + + if (sca == NULL !req-fallback) + resp.status = CA_FAIL; + else if (! lka_X509_verify(req, cafile, NULL)) resp.status = CA_FAIL; else resp.status = CA_OK; I applied the patch and now server certificate verification is working as expected, thank you. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
THE SAD STATE OF SMTP ENCRYPTION - is OpenSMTPD also vulnerable?
Came across this article the other day and was curious if OpenSMTPD can be configured to address the vulnerability without using DNSSEC (ack!) = https://blog.filippo.io/the-sad-state-of-smtp-encryption/ Filippo Valsorda, 31 Mar 2015 THE SAD STATE OF SMTP ENCRYPTION This is a quick recap of why I'm sad about SMTP encryption. It explains how TLS certificate verification in SMTP is useless even if you force it. SMTP SMTP is the protocol that mail servers talk between them to deliver mail. Standardized in 1982 it used to be, unsurprisingly, 100% plaintext. It works like this: a mail server mail.company.com has an email for [email protected]. It does a DNS lookup for a MX record: ;; ANSWER SECTION: example.com.300 IN MX 10 smtp.example.com. ;; ADDITIONAL SECTION: smtp.example.com. 300 IN A 1.2.3.4 Then it opens a connection to 1.2.3.4, exchange greetings, and deliver the email. S: 220 smtp.example.com ESMTP Postfix C: HELO mail.company.com S: 250 Hello mail.company.com, I am glad to meet you C: MAIL FROM:[email protected] S: 250 Ok C: RCPT TO:[email protected] S: 250 Ok ... SMTP is also used by local email clients to submit email, but today we're not talking about that. STARTTLS Then around 2000 people realized that plaintext was a bad idea and started to retrofit encryption on top of protocols. Enter STARTTLS [RFC3207]. The idea is simple: upon connection the server announces its support for STARTTLS and if the client supports it too the connection is upgraded. That is, a TLS handshake is performed and the connection resumes over the encrypted channel. It looks like this on the wire — keep in mind that here client and server are both mail servers: S: 220 smtp.example.com ESMTP Postfix C: HELO mail.company.com S: 250 Hello mail.company.com, I am glad to meet you S: 250 STARTTLS C: STARTTLS S: 220 Go ahead C S: start a TLS session C [TLS]: EHLO mail.company.com S: 250 Hello mail.company.com, I am glad to meet you C: MAIL FROM:[email protected] S: 250 Ok C: RCPT TO:[email protected] S: 250 Ok ... The obvious problem STARTTLS has a glaring problem: it's negotiated over the plaintext channel. The S: 250 STARTTLS line is sent on the clear so an attacker performing a MitM attack can just block it, prevent it from ever reaching the client. At that point the client will simply go ahead with unencrypted SMTP, unaware that the server supports TLS, and the server will think it's the client that came short in supporting it. In browser world, it's as if you always connected over HTTP and relied on the 301 redirect to switch to HTTPS. An attacker can do a SSL stripping attack where they just answer to your HTTP query. It's also what HSTS is designed to prevent. So in its normal configuration STARTTLS is not effective against an active attacker, whom can just downgrade the connection at will. The insidious problem At this point you might think you can make a choice: I'll require encryption on all my connections and accept the tradeoff of only receiving from and delivering to servers that support STARTTLS. Or, I'll make a whitelist of known domains for which I require STARTTLS because I know they support it. You actually can't. The problem is in certificate verification: what hostname do you verify a certificate against? That is, what name do you require on the certificate to make sure you are not talking with an attacker? The answer is whatever the target of the MX record is. And this makes certificate validation—and signed certificates—completely useless. (Indeed, all mail servers will accept expired, self–signed certificates.) First, let's see why we can't verify against the domain portion of the email address. Take my email: it's @filippo.io but it's handled by FastMail. FastMail doesn't have a certificate for filippo.io. How it works instead is that a client will perform a MX lookup ;; ANSWER SECTION: filippo.io.300 IN MX 20 in2-smtp.messagingengine.com. filippo.io.300 IN MX 10 in1-smtp.messagingengine.com. and then verify the certificate against inX-smtp.messagingengine.com (FastMail). If you ask me it's silly, since whoever is able to receive mail for your domain would be able to get a DV certificate issued for it by any CA. But it doesn't happen and this is the Internet we are stuck with. So, verification against the MX target. What does this mean for security? It means that verifying certificates is pointless. The MX record lookup is unencrypted. A MitM'ing attacker can simply falsify the MX like this example.com.300 IN MX 10 smtp.attacker.com. and then present a valid shiny certificate for smtp.attacker.com. Over. Opportunistic encryption STARTTLS can't be secured in any way against an active attacker. So, what is it good for? Well, it's opportunistic encryption and it's not worthless. Opportunistic
Re: [IMPORTANT] latest snapshot - certificate check failed issue
On Sat, 09 May 2015 07:37:13 -0700, Gilles Chehade gil...@poolp.org wrote: Hi, We are preparing upcoming major release and there's been some invasive updates since latest snapshot. In particular these 3 parts require HEAVY testing: - smtp and mta TLS setup can never be concurrent anymore, simplify lka - turn the lka certificate verification into an async operation The TLS code used to be duplicated between incoming and outgoing path, I have factored it so the same code is used to validate client certificate in the incoming path and server certificate in the outgoing path. I have been running with this for a while but we could use some feedback that you don't observe regressions when accepting mail over TLS, or when relaying over TLS. I installed the latest snapshot and restarted the service and now relay connections from my public server to local LAN server are failing with SSL certificate check failed errors. I can provide the smtpd -dv output off-list on request. /etc/mail/smptd.conf -- pki mx.sysfu.com certificate/etc/mail/tls/mx_sysfu_com.crt pki mx.sysfu.com key/etc/mail/tls/mx_sysfu_com.key limit mta inet4 listen on lo0 inet4 listen on egress inet4 tls-require pki mx.sysfu.com auth-optional hostname mx.sysfu.com mask-source listen on egress inet4 port 587 tls-require pki mx.sysfu.com auth-optional tag SYSFU_OUT bounce-warn 1d table trusted-relays/etc/mail/trusted-relays table enforce-tls /etc/mail/enforce-tls # incoming mail destined for users is relayed back to home mail server accept from any for domain { sysfu.com mx.sysfu.com } relay via tls://mail.dvllc.co verify accept from source trusted-relays for domain enforce-tls relay tls verify# require STARTTLS accept from source trusted-relays for any relay accept from local for any relay -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Latest portable snapshot not sending emails.
On Tue, 12 May 2015 09:37:10 -0700, Gilles Chehade gil...@poolp.org wrote: Please try the snapshot I just published, it should fix your issue The snapshot does, but a pull from the latest github version does not. How far behind the snapshots does the Github repo lag? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: [OpenSMTPD] portable snapshot opensmtpd-201505121836p1 available
On Fri, 15 May 2015 13:22:40 -0700, Gilles Chehade gil...@poolp.org wrote: This is now fixed in git, will be part of next snapshot to be published this week-end That did the trick, thanks. BTW, if you're running FreeBSD and installing over a packaged version, you probably need to remove some symlinks first or the 'make install' step will fail. rm /usr/local/bin/sendmail /usr/local/sbin/newaliases /usr/local/sbin/mailq; make install -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
TLS Policy Database and the 'relay tls verify' option....like peas and carrots?
There's been some discussion on the list recently about using the 'relay tls verify' to mitigate STARTTLS downgrade attacks. [1] Gilles suggested using something like this in smtpd.conf as a protective measure: table validcrt file:/etc/mail/hosts-with-valid-certs accept for domain validcrt relay tls verify The question then becomes, how to build the list of domains in the 'validcrt' table. I've been performing this manually by applying some text processing tools to the maillogs , but figured there has to be a better way. The other week I noticed a host 'tls-scan.informatik.uni-bremen.de' showing up in my spamd logs. I visited the web page and found this statement on their web site: The TLS Policy Database collects information about the TLS capability and certificate validity of mailservers on the internet. We provide a simple DNS based database to help you to secure you outgoing email connections. [2] Perfect! This could be a useful resource for building a table of STARTTLS capable mailservers that present verifiable certificates. Combine that with a rule using the 'relay tls verify' option and I believe this would greatly improve email transport security. [1] http://www.mail-archive.com/misc%40opensmtpd.org/msg01967.html [2] http://tls-scan.informatik.uni-bremen.de/ -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: THE SAD STATE OF SMTP ENCRYPTION - is OpenSMTPD also vulnerable?
On Mon, 11 May 2015 17:45:47 -0700, Kevin Chadwick m8il1i...@gmail.com wrote: I wonder what is best more likely and easier to accomplish or gain traction. SMTPS or DNSSEC DNSSEC causes problems but people seem to be wanting it enough to implement it anyway, though many providers still including I believe Google cloud dns do not. I am still in two minds about it. I also have reservations about DNSSec, the primary one being that several security minded people whose opinions I respect have already declared it dead. Below are some 'DNSSec is dead' sides of the argument AppSec is Eating Security - Opening Keynote - AppSec California 2015 - Alex Stamos https://www.youtube.com/watch?v=-1kZMn1RueI#t=2432 DNSSec portion begins at 40:35 Slide 31 of 51 http://www.slideshare.net/astamos/appsec-is-eating-security DNSSEC is dead. Several reasons why... * Complexity * Not end-to-end. How much do you trust your DNS provider? * Invisible to user applications Dan Bernstein: Authenticating The Whole Internet on Vimeo http://vimeo.com/18417770 Dan Kaminsky's response - http://dankaminsky.com/2011/01/05/djb-ccc/ *** Personally I'm a fan of DNSChain over DNSSEC - https://okturtles.com/ *** -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Vacation
On Wed, 15 Apr 2015 08:30:06 -0700, JC PAROLA cont...@sels-ingenierie.com wrote: hi, i configure openstpd on openBSD 5.6 whith vitual users and smt pauth. i want to configure vacation but i dont find any information on man or google opensmtpd have this feature ? There was a thread about this topic back in February https://www.mail-archive.com/misc@opensmtpd.org/msg01660.html -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Slight correction on Does anyone else have an issue establishing a starttls to this host.
On Thu, 09 Apr 2015 02:06:58 -0700, Kevin Chadwick m8il1i...@gmail.com wrote: Hmm, now I am puzzled as that is what should happen. You don't have /usr/bin/openssl and /usr/sbin/openssl installed do you? I guess you ran the same as above but /usr/sbin on 5.6 as it has moved to /usr/bin/ on 5.7 No, the system was updated with LibreSSL 2.1.6, after which I simply renamed /usr/sbin/openssl to /usr/bin/openssl213, then created a soft link /usr/sbin/openssl = /usr/local/bin/openssl Also have you applied the ssl patches from www.openbsd.org/errata56.html or by using mtiers openup tool (no building). Particularly 005 that disables sslv3? That is correct, the system has been updated with all the latest patches via Mtiers openup tool. On my 5.6 box it stops at CONNECTED and the traffic shows client hello like for OpenSMTPD (well actually a certificate receipt can be seen in the encrypted traffic but not much more). Only thing I can think of is that you're running a different version of LibreSSL. I can also try the command from a FreeBSD host if that's of any value. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Slight correction on Does anyone else have an issue establishing a starttls to this host.
On Wed, 08 Apr 2015 12:16:49 -0700, Kevin Chadwick m8il1i...@gmail.com wrote: http://marc.info/?l=openbsd-miscm=142842356024311w=2 When I looked at the actual traffic it appeared that it gets one step further and the connection actually stops at OpenSMTPD sending a client hello via STARTTLS with no further response from the other side. If someone can say it happens to them too but not to any/many other hosts then I'd be glad to chalk it down to a bad implementation on their side? I haven't found any others like this yet. Do you have a test email address we can try sending something to which uses that server? Starttls.info gives it a crappy score BTW https://starttls.info/check/mx5.demon.co.uk Does your mail server support STARTTLS? If you care about privacy, it should. Read more in the blog. Results for: mx5.demon.co.uk Mail server Result mx5.demon.co.uk Grade: E (31.6%) Certificate The certificate is not valid for the server's hostname. There are validity issues for the certificate. Certificates are seldom verified for SMTP servers, so this doesn't mean that STARTTLS won't be used. Generally speaking it's a bad practice not to have a valid certificate, and an even worse practice not to verify them. Any attempted encrypted communication is left all but wide open to Man-in-the-Middle attacks. Protocol Supports SSLV2. More info. Supports SSLV3. Supports TLSV1. Key exchange Anonymous Diffie-Hellman is accepted. This is suspectible to Man-in-the-Middle attacks. Key size is 2048 bits; that's good. Cipher Weakest accepted cipher: 0. Strongest accepted cipher: 256. Click the score for details. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: OpenSMTPD build process does not recognize newer LibreSSL 2.1.4 libraries
On Mon, 09 Mar 2015 16:05:28 -0700, Seth l...@sysfu.com wrote: Solved. This can be accomplished by setting environment variables with the make command, no configure script needed. Hat tip to Nick Mathewson from the Tor-relays mailing list for cluing me in to this method. $ sudo CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib make $ sudo make install $ ldd /usr/sbin/smtpd /usr/sbin/smtpd: StartEnd Type Open Ref GrpRef Name 1eb9f3d0 1eb9f41a9000 exe 10 0 /usr/sbin/smtpd 1ebc57315000 1ebc57721000 rlib 01 0 /usr/lib/libevent.so.4.1 1ebc36f81000 1ebc3738d000 rlib 01 0 /usr/lib/libutil.so.12.1 1ebc635bf000 1ebc63a1d000 rlib 01 0 /usr/local/lib/libssl.so.32.0 1ebc30b6b000 1ebc3113b000 rlib 02 0 /usr/local/lib/libcrypto.so.32.0 1ebc55e4c000 1ebc56274000 rlib 01 0 /usr/lib/libm.so.9.0 1ebca923e000 1ebca9653000 rlib 01 0 /usr/lib/libz.so.5.0 1ebc2a309000 1ebc2a7f2000 rlib 01 0 /usr/lib/libc.so.77.0 1ebbfad0 1ebbfad0 rtld 01 0 /usr/libexec/ld.so Ran into this problem again on OpenBSD 5.7 with LibreSSL 2.2.0. Previously posted solution only works for one of the two libraries in /usr/local/lib $ ldd /usr/sbin/smtpd /usr/sbin/smtpd: StartEnd Type Open Ref GrpRef Name 0df21a20 0df21a6a9000 exe 10 0 /usr/sbin/smtpd 0df4fa561000 0df4fa96d000 rlib 01 0 /usr/lib/libevent.so.4.1 0df4fd17f000 0df4fd58b000 rlib 01 0 /usr/lib/libutil.so.12.1 0df453912000 0df453d71000 rlib 01 0 /usr/lib/libssl.so.32.0 0df4b38d6000 0df4b3ea6000 rlib 01 0 /usr/local/lib/libcrypto.so.33.0 0df4932e6000 0df49370e000 rlib 01 0 /usr/lib/libm.so.9.0 0df5086c3000 0df508ad8000 rlib 01 0 /usr/lib/libz.so.5.0 0df4e52e5000 0df4e57d1000 rlib 01 0 /usr/lib/libc.so.78.1 0df4d870 0df4d870 rtld 01 0 /usr/libexec/ld.so Any troubleshooting suggestions? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: revisiting 'feature: show program version' request for configuration management testing purposes
On Wed, 01 Jul 2015 23:18:11 -0700, Seth l...@sysfu.com wrote: The only outstanding issue I can think of is how to distinguish between patch versions, e.g. 5.7.1 vs 5.7.1p1 Disregard that dumb question, realized that p1 stands for portable, been a long day. This is the command I'm using to extract the smtpd version number for the Ansible test smtpd -h 21 | head -1 | awk '{ print $3 }' -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Recommended method for blasting the queue clean- can smtpctl be used?
I discovered I had thousands of message stuck in my queue from running some stress tests earlier which needed removal. Apparently the 'smtpctl remove evpid|msgid' command does not support wild cards. Instead, I changed to /var/spool/smtpd/queue and ran this command with root privs: # 'find . -type f -exec rm {} \;' That seemed to do the trick but was wondering if there's any way to accomplish the same via the smtpctl utility. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: revisiting 'feature: show program version' request for configuration management testing purposes
On Wed, 01 Jul 2015 17:33:38 -0700, Seth l...@sysfu.com wrote: Dennis F (ledeuns@github) informs me that the smptd version number can be obtained via the following command 'smtpd -h'. It appears that this switch is currently undocumented in the smtpd man page. The only outstanding issue I can think of is how to distinguish between patch versions, e.g. 5.7.1 vs 5.7.1p1 -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
revisiting 'feature: show program version' request for configuration management testing purposes
I'd like to revisit github issue #283 [1] feature: show program version In a nutshell I'm trying to create some OpenSMTPD version tests for the Ansible config mgmt system, and grepping the logs for the version has the following problems 1) Version number could be in uncompressed or gzipped logs, requiring two tests and more complex shell command ugliness 2) Version number disappears from the logs after a week or so 3) Taking the above into account, there's really no reliable way to determine if the version number is still in the logs, so the smtpd service must be bounced to ensure the version number is written to /var/log/maillog and findable 4) Version number then must be pulled out of the standard output which looks something like this... $ sudo grep 'info: OpenSMTPD' /var/log/maillog Jul 1 17:17:58 mx smtpd[13744]: info: OpenSMTPD 5.7.1 starting ...and awked or whatever. All of this boils down to a huge pain in the a** just to obtain the current OpenSMTPD version number in order to determine whether the software needs to be updated or not. In the name of all that is good and holy, please re-consider adding a 'show version' feature, preferably to smptctl. [1] https://github.com/OpenSMTPD/OpenSMTPD/issues/283 -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: That SSLv3 thing
On Wed, 15 Oct 2014 12:33:50 -0700, Gilles Chehade gil...@poolp.org wrote: Hi, As you may know, SSLv3 has been pushed into end of life. While SSL libraries are working this out, I committed a fix to disable it explicitely in our code just in case someone builds it against some pre-catastrophe OpenSSL/LibreSSL version. We're going to be releasing a minor stable in the next few days with a few bugs fixed in it, the SSLv3 disable WILL be part of it. I'll also be publishing both master and portable snapshots in a couple minutes with the SSLv3 disable in them. If you're running stable and can't wait for the next minor stable, you can simply apply the following diff: Index: ssl.c === RCS file: /cvs/src/usr.sbin/smtpd/ssl.c,v retrieving revision 1.71 diff -u -p -r1.71 ssl.c --- ssl.c 2 Oct 2014 18:30:21 - 1.71 +++ ssl.c 15 Oct 2014 19:14:52 - @@ -263,7 +263,7 @@ ssl_ctx_create(const char *pkiname, char SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF); SSL_CTX_set_timeout(ctx, SSL_SESSION_TIMEOUT); SSL_CTX_set_options(ctx, - SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_TICKET); + SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TICKET); SSL_CTX_set_options(ctx, SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION); I'm trying to disable the TLSv1.0 protocol on the 5.7.1 release using a similar approach... ssl.c: SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1_0 | SSL_OP_NO_TICKET); however compile is failing with this error /usr/local/src/opensmtpd-5.7.1/smtpd/smtpd/../ssl.c: In function 'ssl_ctx_create': /usr/local/src/opensmtpd-5.7.1/smtpd/smtpd/../ssl.c:287: error: 'SSL_OP_NO_TLSv1_0' undeclared (first use in this function) /usr/local/src/opensmtpd-5.7.1/smtpd/smtpd/../ssl.c:287: error: (Each undeclared identifier is reported only once /usr/local/src/opensmtpd-5.7.1/smtpd/smtpd/../ssl.c:287: error: for each function it appears in.) *** Error 1 in smtpd (sys.mk:87 'ssl.o') *** Error 1 in /usr/local/src/opensmtpd-5.7.1/smtpd (bsd.subdir.mk:48 'all') Any pointers? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: OpenSMTPD build process does not recognize newer LibreSSL 2.1.4 libraries
On Mon, 29 Jun 2015 12:46:08 -0700, Gilles Chehade gil...@poolp.org wrote: The subject being: Re: OpenSMTPD build process does not recognize newer LibreSSL 2.1.4 libraries The original issue from March concerned LibresSL 2.1.4, which was solved with the CFLAGS LDFLAGS workaround. The recent posts concern LibreSSL 2.2.0. Maybe I should have created a new thread rather that reviving the older one, sorry for the confusion. Current build environment: OpenBSD 5.7 amd64 release with all latest patches applied via Mtier openup utility. LibreSSL 2.2.0 OpenSMTPD 5.7.1-rc1 -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: OpenSMTPD build process does not recognize newer LibreSSL 2.1.4 libraries
On Mon, 29 Jun 2015 09:38:54 -0700, Gilles Chehade gil...@poolp.org wrote: Can you show me the build error ? Ran 'sudo CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib make' 'from opensmtpd-5.7.1-rc1/smtpd' dir and there were no errors. Log of make output attached. opensmtpd-make.log Description: Binary data
Re: OpenSMTPD build process does not recognize newer LibreSSL 2.1.4 libraries
On Mon, 29 Jun 2015 12:55:21 -0700, Gilles Chehade gil...@poolp.org wrote: what is is that you experience in this setup ? it builds but fails at startup ? It build and runs fine, however the binaries is not linked to the latest libssl in /usr/local/lib. Only the libcrypto lib is correctly linked. $ ldd /usr/sbin/smtpd /usr/sbin/smtpd: StartEnd Type Open Ref GrpRef Name 1a26c5f0 1a26c63b3000 exe 10 0 /usr/sbin/smtpd 1a28e03a8000 1a28e07b4000 rlib 01 0 /usr/lib/libevent.so.4.1 1a28e1bc 1a28e1fcc000 rlib 01 0 /usr/lib/libutil.so.12.1 1a2933c95000 1a29340f4000 rlib 01 0 /usr/lib/libssl.so.32.0 1a28d80a2000 1a28d8672000 rlib 01 0 /usr/local/lib/libcrypto.so.33.0 1a298dd3c000 1a298e164000 rlib 01 0 /usr/lib/libm.so.9.0 1a28f83ce000 1a28f87e3000 rlib 01 0 /usr/lib/libz.so.5.0 1a28f57c9000 1a28f5cb5000 rlib 01 0 /usr/lib/libc.so.78.1 1a2925c0 1a2925c0 rtld 01 0 /usr/libexec/ld.so -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: OpenSMTPD build process does not recognize newer LibreSSL 2.1.4 libraries
On Mon, 29 Jun 2015 12:55:21 -0700, Gilles Chehade gil...@poolp.org wrote: what is is that you experience in this setup ? I should add that I would like OpenSMTPD to detect and build against the latest installed LibreSSL libraries automatically without requiring any manual CFLAGS/LDFLAGS workaround. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: OpenSMTPD build process does not recognize newer LibreSSL 2.1.4 libraries
On Mon, 29 Jun 2015 09:38:54 -0700, Gilles Chehade gil...@poolp.org wrote: You installed LibreSSL 2.2.0 on top of OpenBSD 5.7 ? Correct Previous versions worked ? If you mean OpenSMTPD would compile with updated LibreSSL libraries when using the CFLAGS and LDFLAGS were needed as described earlier, then 'yes' Can you show me the build error ? I don't recall any build errors, running another one and will update the thread with any found. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Revisiting Issue #359 - Allow OpenSSL options to be specified
Copying my comment on this ticket[1] to the list for discussion --- I would like to re-open discussion on this issue for a different use case: In light of more vulnerabilities discovered in the TLSv1.0 protocol since Dec 2013, I no longer feel it provides acceptable security and would like a configuration option to disable support for it. Going even further, I would also like to be able to disable TLSv1.1, and force all incoming connections to use TLSv1.2. Seeing as how this does not downgrade security, but rather upgrades it, I think it merits consideration. Syntax could be something like dovecot's 10-ssl.conf option tls_protocols = !TLSv1 !TLSv1.1 Also, lets purge all references to the Netscape product from 1996...'ssl' and replace them with the IETF standard name, 'tls' --- [1] https://github.com/OpenSMTPD/OpenSMTPD/issues/359 -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Revisiting Issue #359 - Allow OpenSSL options to be specified
On Mon, 27 Jul 2015 12:53:19 -0700, Török Edwin ed...@etorok.net wrote: Would this be for incoming or outgoing connections? It's the incoming that I'm primarily concerned with, but that's a good point to raise. Should the setting effect both directions or be applied independently? For incoming connections this would downgrade security, if remote server uses TLSv1.1 and fails to make a connection to OpenSMTPD (because it requires TLSv1.2) then it'll fall back to plaintext which is worse than a hard to exploit vulnerability in TLS. This argument assumes that incoming plaintext connections are accepted, which I am completely aware is the default. I've been forcing inbound TLS via the tls-require option for over a year now with no complaints. For outgoing connections you could require tls always, but I'm not sure thats realistic yet if you actually want to deliver mail, and if you're not careful it might cause plaintext fallbacks. Just looking at my personal mail server I have roughly: smtp-in: TLSv1/SSLv3 (TLSv1.2) 63% TLSv1/SSLv3 (SSLv3) 24% TLSv1/SSLv3 () 7% plaintext (proto=SMTP) 6% If I reject SSLv3, TLSv1 and 1.1 I'd have: TLSv1.2 63% plaintext 37% The SSLv3 seems to come from public mailing list servers. smtp-out: TLSv1/SSLv3 (TLSv1.2) 96% TLSv1/SSLv3 () 4% I wouldn't be opposed to deprecating SSLv3, but what is the right way to do that without breaking mail deliverability or causing plaintext fallbacks? Perhaps you could accept the connection and reject immediately with an SMTP error code and a message describing the problem? Basically, I want to force TLSv1.2 in both directions, plaintext is always verboten, and if the other party doesn't support it, that's their problem, I'm prepared to do without. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: SSL/TLS
On Mon, 27 Jul 2015 19:40:39 -0700, SSL tuy...@aoiyuma.mydns.jp wrote: i am afraid of being attacked . so i want to limit PCs in japan only (if japanese PC is hacked , this setting in not safe ) . It would probably be more appropriate and effective to use a firewall such as OpenBSD's pf to accomplish this goal. OpenBSD also provides spamd which, along with a few selected real time black lists added to the mix, makes a very effective spam filter. but i want to use conection secrity SSL/TLS . how to do it ? The smptd.conf(5) man page documents key generation in the EXAMPLES section near the end. In this second example, the aim is to permit mail relaying for any user that can authenticate using their normal login credentials. An RSA certificate must be provided to prove the server's identity. The mail server listens on all interfaces the default route(s) point to. Mail with a local destination should be sent to an external mda. First, the RSA certificate is created: # openssl genrsa -out /etc/ssl/private/mail.example.com.key 4096 # openssl req -new -x509 -key /etc/ssl/private/mail.example.com.key \ -out /etc/ssl/mail.example.com.crt -days 365 # chmod 600 /etc/ssl/mail.example.com.crt # chmod 600 /etc/ssl/private/mail.example.com.key -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: [Extras] Problems with sqlite tables
On Sun, 26 Jul 2015 08:03:45 -0700, Edgar Pettijohn ed...@pettijohn-web.com wrote: # smtpd -d If so add some v's: # smtpd -d Do the extra stmpd 'v' flags produce more verbose output on all platforms? I just tried this on Arch linux and can't tell that smptd -d yields any more output than smtpd -dv -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Receiving broken e-mails?
On Sat, 25 Jul 2015 01:27:00 -0700, Herbert J. Skuhra herb...@oslo.ath.cx wrote: anyone else who is running OpenSMTPD on FreeBSD receive broken e-mails? In tcpdump/wireshark the message looks ok, but in the trace log the lines are broken. Receiving the same message with Postfix works! I haven't seen problem of this sort so far, but I don't have any public facing FreeBSD/OpenSMTPD servers, the ones I do have all sit behind OpenBSD/OpenSMTPD relays. When you say 'broken' what exactly does that mean? Only part of the message is delivered instead of A complete one? Btw. OpenSMTPD portable from git does not compile for a while unless I add #define HAVE_ERR_H 1 to config.h. Reproduced the build error and success of your workaround on a FreeBSD 9x system. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: smtpd fails on automatic startup
On Wed, 14 Oct 2015 05:45:05 -0700, Allyn Bottorffwrote: Unless you use a service that actually provides it, a target will do absolutely nothing on its own. So how is using the proper things "not an ideal solution"? Systemd's own networkd should provide that target. It's not an ideal solution because using that service extends the boot time in a way that shouldn't be necessary in this case. It forces the boot to wait until the network is up and an IP address is assigned. Besides, it didn't solve the problem anyway, so this particular discussion is academic. Have you tried to reproduce this issue by disabling systemd's networkd and using Arch's netctl to configure the interface? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: smtpd fails on automatic startup
On Sat, 10 Oct 2015 07:44:51 -0700, Allyn Bottorffwrote: Because 'network.target' doesn't actually wait for any of the interfaces to be up - what you want is 'network-online.target'[0]. Regards, Raf [0] https://wiki.freedesktop.org/www/Software/systemd/NetworkTarget/ Thanks, I wasn't aware of that. This hasn't solved the problem, however... I'm still getting: fatal: smtpd: bind: Cannot assign requested address This is after changing to network-online.target and also adding in Restart=always for good measure. I think my next step will be to enable the systemd-networkd-wait-online.service to see if that makes a difference, even though it's not an ideal solution. Hopefully I'll have time to mess with that tonight. Can you please post your smtpd.conf? Maybe this has something to do with the name chosen for the listening interface. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: smtpd fails on automatic startup
On Fri, 09 Oct 2015 13:19:32 -0700, Allyn Bottorffwrote: Greetings, I've been running an OpenSMTPD server for a while now on an ArchLinux server and I've noticed some strange behavior. When I reboot the server, smptd crashes on startup. If I restart the service manually, however, it starts up just fine and will run without issue until I need to reboot for whatever reason. Because of this, I'm assuming it has to do with the way the OS is starting the service rather than an smtpd problem specifically, but I'm hoping that someone here may know more about the error codes than I and will be able to point me in the right direction. #journalctl -u smtpd.service Your network interface might not be fully initialized when the smtpd service attempts to start. Try monkeying with the smtpd.service unit file dependencies as per https://wiki.archlinux.org/index.php/Systemd#Handling_dependencies -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
adding rDNS check feature to OpenSMTPD
I'm searching for additional ways to combat spam and looking into using reverse DNS lookups as a tool for doing so. What do others think of using rDNS lookups as an anti-spam tactic? If rDNS lookups are worthwhile, where would the most appropriate place to implement them be; spamd or the OpenSMTPD daemon? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Emails not forwarding to external addresses
On Thu, 09 Jul 2015 11:58:38 -0700, Herbert J. Skuhra herb...@oslo.ath.cx wrote: CONFIG pki domain.tld certificate /etc/smtpd/tls/smtpd.crt pki domain.tld key/etc/smtpd/tls/smtpd.key table vdoms /etc/smtpd/vdoms table vusers /etc/smtpd/vusers listen on eth0 hostname domain.tld accept from any for domain vdoms virtual vusers deliver to maildir /home/tom/mails accept from source { localhost 109.237.26.21/24 } for any relay I think the above line is the problem. It should work if you add 216.119.104.83! Hm. That last line is meant to allow the local system and other email clients on the specified subnet to be able to send outbound mail through the server. It's not intended for other mail servers on the Internet, the prior statement should handle that traffic. I also need to update the wiki article so that the listen statement makes use of the pki key and cert. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Log file on Linux?
On Sat, 26 Sep 2015 15:04:38 -0700, Holger Jahn <li...@loomsday.co.nz> wrote: Thanks for your reply, Seth. For the sake of argument, simply assume for a moment that no system logger is present and/or can be installed. Is there a way to set up logging specifically for OpenSMTPD only? Not without modifying the log.c component with your own custom logging code, best I can tell there is no built in provision for the smtpd daemon to create and write to its own log file. https://github.com/OpenSMTPD/OpenSMTPD/blob/master/smtpd/log.c -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Log file on Linux?
On Thu, 24 Sep 2015 17:38:40 -0700, Holger Jahnwrote: After installing the latest portable version 5.7.1p1 on Arch Linux, I was wondering how to set a log file for SMTPD. I am running a virtual server with no syslog running, i.e. I would like to specify my own log file ("/var/log/smtpd"). Logging to STDERR with "smtpd -d" works nicely, but a dedicated log file would even be nicer. On Arch linux opensmtpd logging is handled via systemd by default. If journalctl does not suit your needs then I think you would need to install syslog-ng in tandem with systemd to accomplish your goal. https://wiki.archlinux.org/index.php/Syslog-ng -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: The death of TLSv1.0
On Sat, 09 Jan 2016 03:57:24 -0800, Clint Pachlwrote: Tom Smyth wrote on 01/08/16 16:40: Besides do we want to have a mail system that is so secure that a large portion of legacy systems cant negotiate security and therefore cant send mail to our servers... I think options / enforced by default options like this could seriously hurt adoption of openSMTPD I think sacrificing security for adoption is a bad trade off and does not align with the OpenBSD ecosystem. I believe "secure by default" and "proactive security" do align with the OpenBSD ecosystem. Read http://www.openbsd.org/security.html "OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there)." I just wanted to say that @reyk and the devs working on httpd(8) made the default protocol TLSv1.2 only. However, they also have a knob. Clint, I couldn't agree more. In the post-Snowden era it's incredibly frustrating to see 2nd and 3rd class, weak and obsolete crypto protocols in use up right up until the inevitable devastating attack that becomes public and makes a news splash. I used a compile time hack to disabled TLSv1 on my servers a while ago [1] and can you guess the only two email services I found in the logs that stopped being able to deliver email? Discover.com and Paypal.com, two financial services companies, what a joke. I think the approach reyk took with httpd, supporting only TLSv1.2 by default is the correct one. If people insist on shooting a hole in their security foot to support obsolete clients and organizations with crap security like Discover.com and Paypal.com, so be it, give them a knob to do so, but don't let them do it unknowingly. [1] https://www.mail-archive.com/misc%40opensmtpd.org/msg02326.html -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Recommended method for blasting the queue clean- can smtpctl be used?
Can someone please commit Sunil's patch below to the main code base when they get a chance? Removing all the spammer's bogus email destinations from my queue one at a time is painful. On Thu, 02 Jul 2015 01:44:10 -0700, Sunil Nimmagaddawrote: As far I can see, the smtpctl is capable of... smtpctl remove all smtpctl resume envelope all smtpctl pause envelope all just like... smtpctl schedule all but a cmd_install of the "all" variant is missing. This diff works for me, could you try... diff --git a/smtpd/smtpctl.8 b/smtpd/smtpctl.8 index fa7a661..9369234 100644 --- a/smtpd/smtpctl.8 +++ b/smtpd/smtpctl.8 @@ -99,6 +99,8 @@ Generated bounces. .It Cm pause envelope Ar envelope-id | message-id Temporarily suspend scheduling for the envelope with the given ID, or all envelopes with the given message ID. +.It Cm pause envelope all +Temporarily suspend scheduling all the envelopes. .It Cm pause mda Temporarily stop deliveries to local users. .It Cm pause mta @@ -119,9 +121,13 @@ imsg, to profile cost of event handlers .El .It Cm remove Ar envelope-id | message-id Remove a single envelope, or all envelopes with the same message ID. +.It Cm remove all +Remove all envelopes. .It Cm resume envelope Ar envelope-id | message-id Resume scheduling for the envelope with the given ID, or all envelopes with the given message ID. +.It Cm resume envelope all +Resume scheduling all the envelopes. .It Cm resume mda Resume deliveries to local users. .It Cm resume mta diff --git a/smtpd/smtpctl.c b/smtpd/smtpctl.c index e45a0a0..fa9642e 100644 --- a/smtpd/smtpctl.c +++ b/smtpd/smtpctl.c @@ -990,14 +990,17 @@ main(int argc, char **argv) cmd_install("monitor",do_monitor); cmd_install("pause envelope ", do_pause_envelope); cmd_install("pause envelope ", do_pause_envelope); + cmd_install("pause envelope all", do_pause_envelope); cmd_install("pause mda", do_pause_mda); cmd_install("pause mta", do_pause_mta); cmd_install("pause smtp", do_pause_smtp); cmd_install("profile ",do_profile); cmd_install("remove ", do_remove); cmd_install("remove ", do_remove); + cmd_install("remove all", do_remove); cmd_install("resume envelope ", do_resume_envelope); cmd_install("resume envelope ", do_resume_envelope); + cmd_install("resume envelope all",do_resume_envelope); cmd_install("resume mda", do_resume_mda); cmd_install("resume mta", do_resume_mta); cmd_install("resume route ", do_resume_route); -- Using Opera's mail client: http://www.opera.com/mail/ -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
apparent 31 character username limit for smtp auth
I'm running into an issue on an OpenSMTPD mail server where the mail client cannot successfully authenticate via SMTP auth on port 587 when the username is longer than 31 characters. Happens with both Mailbird and Thunderbird email clients. These are the errors that show up in the logs when the username is over 31 chars: Mar 12 21:51:17 mx smtpd[26118]: smtp-in: Failed command on session 78fa93cb23366cfe: "AUTH PLAIN (...)" => 501 5.5.2 Syntax error: Syntax error environment: OpenBSD 5.8 release LibreSSL 2.2.6 OpenSMTPD 5.7.3 Mailbird 2.2.5.0 Thunderbird 38.6.0 /etc/mail/smtpd.conf pki domain.tld certificate "/etc/ssl/domain_tld.crt" pki domain.tld key "/etc/ssl/private/domain_tld.key" table creds "/etc/mail/creds" table trusted-relays"/etc/mail/trusted-relays" table enforce-tls "/etc/mail/enforce-tls" table vdoms "/etc/mail/vdoms" table vusers"/etc/mail/vusers" bounce-warn 1d limit mta inet4 listen on lo inet4 listen on lo0 port 10028 tag DKIM_OUT # outgoing mail listen on egress inet4 tls pki domain.tld listen on egress inet4 port 587 tls-require pki domain.tld auth mask-source # tagged mail returned from dkimproxy_out relays out accept tagged DKIM_OUT for domain relay tls # require STARTTLS for domains known to support it, otherwise fail hard accept tagged DKIM_OUT for any relay # incoming mail for local users delivered via maildir accept from any for domain virtual deliver to maildir "/var/maildir/%{dest.domain:lowercase}/%{dest.user:lowercase|strip}/mail/" # relay other email to the Internet at large accept from source for any relay via smtp://127.0.0.1:10027 accept for any relay via smtp://127.0.0.1:10027 -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Is the /etc/aliases file an anachronism on modern systems running OpenSMTPD?
I've been running several OpenSMPTD servers on OpenBSD for a while now without using the /etc/aliases file. I'm having issues however with annoying email being generated from the r...@mx.domain.tld and mailer-dae...@mx.domain.tld addresses which get stuck in the delivery queue because I don't have the systems configured to accept email at the mx.domain.tld subdomain. Maybe this is more of a question for the OpenBSD list, but I'm wondering if in this day and age, the '/etc/aliases' file is really just a dumb clunky sendmail throwback that needs to die in a fire and is unnecessary on modern OpenBSD/OpenSMTPD systems. If it's not necessary, is there anyway that I can force all system email generated for the root user to go to a designated email of my choosing, without having to use /etc/aliases and add the corresponding table and accept lines in smptd.conf? I can edit the cron /etc/daily|weekly|monthly scripts but that does not seem to address the smtpd daemon generated error messages. Curious to know how other OpenSMTPD users address 'the aliases' question. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Problem with elliptic key
On Sun, 17 Apr 2016 09:59:07 -0700, Gilles Chehadewrote: With an elliptic key opensmtpd won't start. I have attached the config, the debug output and my used EC cert+key attached (both are only self signed test certs). I would kindly ask, if someone has some time to give me a hint, what's wrong with an EC key. To prevent private keys from leaking in case of a security issue in the network facing process, OpenSMTPD keeps keys in a separate process and does some magic to hand over the crypto operations to that process. Problem is that we don't have the code for EC yet. I opened a related ticket for relayd that you might want to keep an eye on. [1] If memory serves correctly OpenSMTPD was going to import that ECC code once it's complete. [1] https://github.com/reyk/relayd/issues/8 -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: please test upcoming release
On Thu, 12 May 2016 09:01:10 -0700, Gilles Chehadewrote: Do test asap, the longer we lock on 5.9.2, the longer we are not doing new OpenSMTPD work. Forgot to ask: Will this release candidate 'play nice' with opensmtpd-extras-201602042118? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org