Date: Wed, 16 Sep 2026 15:07:43 +0000 From: Taylor R Campbell Subject: [DRAFT] Sending mail from @NetBSD.org TL;DR: Major mail hosts have grown stricter about what incoming mail they will accept and deliver, vs silently discard. To send mail from your @NetBSD.org or @pkgsrc.org developer address, we recommend that you either: (a) submit mail by running /usr/sbin/sendmail on mail.NetBSD.org (e.g., via `ssh mail.NetBSD.org /usr/sbin/sendmail' or by just running your MUA like mutt(1) or alpine(1) over ssh on mail.n.o); or (b) submit mail via `submissions' (formerly `smtps') on port 465 authenticated with SASL GSSAPI, using a Kerberos ticket as in -- you'll need to run kinit(1) to log in once a day when you want to send mail. Many mailers support either a shell command or SASL/GSSAPI/Kerberos out of the box -- see MAIL USER AGENT CONFIGURATIONS below. Please file an admins ticket by sending mail to admins@NetBSD.org if you have any trouble setting this up. DETAILS We've long had developers sending mail with `From: ...@NetBSD.org' header fields from any mail server of their choice. But mail hosts these days are increasingly likely to spambucket or silently discard incoming mail without all the i's dotted, t's crossed, and 27b/6's filled out in the header according to the DMARC/SKIM/SPF mechanisms they use to reject phishing mail spoofing @paypal.com addresses and so on. We haven't changed our policy, but to make our mail more deliverable, we started putting DKIM signatures[1] on messages that go out via mail.NetBSD.org a couple years ago. This only works for mail that is submitted via mail.NetBSD.org, however -- so mail you originate at your own mail server won't get the DKIM signature, and in that case Google/Yahoo/Microsoft might silently discard mail they receive from you (even though our SPF[2] and DMARC[3] policies tell them not to do so). (We are not currently regularly rotating the NetBSD.org or pkgsrc.org DKIM keys, but we should really do that -- in fact, to mitigate DKIM's incentive to leak private mail[4], I'd like to rotate them on a daily or weekly basis and include X-DKIM-Private-Key header fields alongside the DKIM-Signature. But automatic key rotation takes a little more work to engineer.) Developers have long been able to log into mail.n.o and run an MUA there, or pipe mail into `ssh mail.NetBSD.org /usr/sbin/sendmail'. What's new this year is a standard mail submission service[5][6] for more conventional outgoing mail submission. PRIVACY Mail submitted through mail.n.o DOES NOT include your client IP address in the outgoing header. Postfix as a mail submission agent will normally do this by default, but we have configured it to strip this header field. (See /etc/postfix/submission_header_checks and the `submissions' service in /etc/postfix/master.cf on mail.n.o for details, if you're interested in how to do this for your own postfix deployment.) MAIL USER AGENT CONFIGURATIONS Configuration for several mailers here: - mutt (mail/mutt, mail/neomutt) - alpine (mail/alpine, mail/pine) - thunderbird (mail/thunderbird) - msmtp (mail/msmtp) -- drop-in replacement for /usr/sbin/sendmail that does the authentication itself, if you have another MUA that can run a custom sendmail program but can't talk SMTP with SASL GSSAPI authentication - msmtpd (mail/msmtp) -- runs as a local SMTP server that does the authentication itself, if you have another MUA that can talk SMTP but can't either can't run a shell command or talk SMTP with SASL GSSAPI authentication - postfix transport via mail.n.o * mutt (if you're running it locally, not on mail.n.o): In your ~/.muttrc, either: (a) Mail through ssh: set sendmail = "ssh mail.NetBSD.org /usr/sbin/sendmail -oi" (The `-oi' option is important! Otherwise a message with a single `.' line would be truncated.) or (b) Mail through submission (in pkgsrc, requires `sasl' option and security/cy2-gssapi -- note: mutt's `gssapi' option is only for IMAP AUTH=GSSAPI, RFC 1731): set smtp_authenticators = "gssapi" set smtp_url = "smtps://jrandomdev@mail.NetBSD.org/" Replace `jrandomdev' by your login name. Before you can send mail, you must run `kinit jrandomdev@NETBSD.ORG' to get a ticket, once a day. NOTE: This must be `smtps://', not `smtp://'. or you can use mutt together with msmtp(1) or a local msmtpd(8) instance (see below). * alpine (if you're running it locally, not on mail.n.o): In your ~/.pinerc, either: (a) Mail through ssh: sendmail-path=ssh mail.NetBSD.org /usr/sbin/sendmail -oi -t (The `-oi' _and_ `-t' options are important! Without `-oi', a message with a single `.' line would be truncated, and without `-t', it just won't work.) or (b) Mail through submissions (in pkgsrc, requires `kerberos' option, which doesn't currently work on NetBSD because upstream relies on mitkrb5isms): smtp-server=mail.NetBSD.org:465/user=jrandomdev Replace `jrandomdev' by your login name. Before you can send mail, you must run `kinit jrandomdev@NETBSD.ORG' to get a ticket, once a day. or you can use alpine together with msmtp(1) or a local msmtpd(8) instance (see below). * Thunderbird: Set up an outgoing mail server with: - Hostname: mail.NetBSD.org - Port: 465 - Connection security: SSL/TLS - Authentication method: GSSAPI / Kerberos - Username: jrandomdev Replace `jrandomdev' by your login name. Before you can send mail, you must run `kinit jrandomdev@NETBSD.ORG' to get a ticket, once a day. (You can also use Thunderbird with a local msmtpd(8) instance; see below.) * msmtp(1)/msmtpd(8): Set up msmtp.conf with: defaults account netbsd user jrandomdev auth gssapi set_msgid_header off host mail.NetBSD.org port 465 tls on account default : netbsd Replace `jrandomdev' by your login name. Now you can use msmtp(1) as a /usr/sbin/sendmail substitute, or start msmtpd(8) to run a local SMTP server listening on 127.0.0.1 port 25 by default. Make sure NOT to listen on any public addresses -- you must not become an open relay! (You can adjust the `defaults' and `account default : netbsd' line if you have other outgoing mail servers configured and you don't want mail.n.o to be the default; see the msmtp(1) man page for more. The set_msgid_header line avoids leaking your client's hostname in the outgoing message header -- mail.n.o will fill in a Message-ID header field anyway.) * postfix transport via mail.n.o: If you want to submit mail from @NetBSD.org on your own MTA (e.g., with a local /usr/sbin/sendmail command), you can configure postfix out of the box in the NetBSD base system to transport mail from @NetBSD.org via mail.n.o authenticated with your Kerberos ticket. Add the following to /etc/postfix/main.cf (or set up a per-service equivalent in /etc/postfix/master.cf if this would conflict with your existing smtp_* options): sender_dependent_default_transport_maps = inline:{@NetBSD.org=smtp:[mail.NetBSD.org]:465} smtp_sasl_auth_enable = yes smtp_sasl_mechanism_filter = GSSAPI smtp_sasl_password_maps = inline:{mail.NetBSD.org=jrandomdev} smtp_tls_security_level = encrypt smtp_tls_wrappermode = yes Create a file /var/spool/postfix/.krb5/config containing the single line: [libdefaults] Reload the postfix configuration: # postfix check # service postfix reload Get a ticket for postfix to use: # HOME=~postfix su -m postfix -c 'kinit jrandomdev@NETBSD.ORG' jrandomdev@NETBSD.ORG's Password: The ticket will be stored in /tmp/krb5cc_$(id -u postfix); you can revoke it by deleting that file. Since this is a personal ticket rather than a service keytab, it expires after 24h and has to be acquired once on each day you want to use it -- it's designed as a single-sign-on mechanism for a person to log in once per day, not as a long-term application key. We can arrange to give you a service keytab instead which doesn't require kinit once a day -- if you want that, file an admins ticket (mail to admins@) with your MTA's hostname. [1] D. Crocker, T. Hansen, and M. Kucherawy, RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, IETF, September 2011 https://www.rfc-editor.org/rfc/rfc6376.html [2] S. Kitterman, RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, IETF, April 2014 https://www.rfc-editor.org/rfc/rfc7208.html [3] M. Kucherawy and E. Zwicky, RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC), IETF, March 2015 https://www.rfc-editor.org/rfc/rfc7489.html [4] Matthew Green [not ours, the other one], `Ok Google: please publish your DKIM secret keys', A Few Thoughts on Cryptography Engineering blog, November 2020 https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ [5] R. Gellens and J. Klensin, RFC 6409: Message Submission for Mail, IETF, November 2011 https://www.rfc-editor.org/rfc/rfc6409.html [6] K. Moore and C. Newman, RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access, IETF, January 2018 https://www.rfc-editor.org/rfc/rfc8314.html