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' on port 465 authenticated with Kerberos as in . Most 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. BACKGROUND 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 If you read and compose mail by sshing into mail.n.o and running mail/mutt/alpine/whatever, you need not configure anything and you can stop here! Configuration for several mailers below: - mail(1) - 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) -- local SMTP server that authenticates to a remote SMTP server, 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 For mail over ssh: You should use a wrapper script at (say) ~/nbsendmail.sh (chmod +x) to safely transmit any arguments even if the addresses you're trying to send to have embedded shell metacharacters: #!/bin/sh cmd=/usr/sbin/sendmail for arg; do qarg="$(printf '%s' "$arg" | sed -e "s/'/'\"'\"'/g")" cmd="${cmd} '${qarg}'" done exec ssh mail.NetBSD.org "$cmd" For mail over submission with Kerberos: On NetBSD or other systems with Heimdal, create a file ~/.krb5/config with the following content [libdefaults] name_canon_rules = as-is:match_domain=NetBSD.org On macOS, no configuration is needed -- it will keep tickets (and can save your krb5 passphrase) in the system keychain. Run `kinit jrandomdev@NETBSD.ORG' to get a ticket, where `jrandomdev' is your TNF login name -- each ticket (stored in /tmp/krb5cc_$(id -u) by default on NetBSD), will last a day before you have to get a new one. You can use `klist' to see your current tickets and what services you've authenticated to with them, or `kdestroy' to delete them and log out. * mail(1) (if you're running it locally, not on mail.n.o): Use the `-f' sendmail option (on the command line after the recipients, or in the `smopts' setting) to specify the `From:' address, and in your ~/.mailrc, either: (a) Mail through ssh: set sendmail=~/nbsendmail.sh or (b) Mail with Kerberos using msmtp(1) -- see below for configuring msmtp(1): set sendmail=/usr/pkg/bin/msmtp Before you can send mail, you must `kinit jrandomdev@NETBSD.ORG' to get a ticket, once a day. * mutt (if you're running it locally, not on mail.n.o): In your ~/.muttrc, set the address for `From:' header fields in outgoing messages (or unset use_from to let mail.n.o fill it in for you): set from = "jrandomdev@NetBSD.org" And either: (a) Mail through ssh: set sendmail = "~/nbsendmail.sh -oi" (The `-oi' option is important! Otherwise a message with a single `.' line would be truncated.) or (b) Mail with Kerberos (in pkgsrc, requires `sasl' option and security/cy2-gssapi -- note: mutt's `gssapi' option is only for IMAP AUTH=GSSAPI, RFC 1731, not relevant here): 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 (c) Mail with Kerberos using msmtp(1) -- see below for configuring msmtp(1) itself: set sendmail = "/usr/pkg/bin/msmtp" Before you can send mail, you must `kinit jrandomdev@NETBSD.ORG' to get a ticket, once a day. * 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. Without `-t', it just won't work. or (b) Mail with Kerberos (in pkgsrc, requires `kerberos' option, which doesn't currently work on NetBSD because upstream relies on mitkrb5isms and NetBSD ships heimdal): smtp-server=mail.NetBSD.org:465/ssl/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 (c) Mail with Kerberos using msmtp(1) -- see below for configuring msmtp(1) itself: sendmail-path=/usr/pkg/bin/msmtp -t Before you can send mail, you must `kinit jrandomdev@NETBSD.ORG' to get a ticket, once a day. * Thunderbird: Set up an outgoing mail server with: - Hostname: mail.NetBSD.org - Port: 465 - Connection security: SSL/TLS - Authentication method: GSSAPI / Kerberos - Username: jrandomdev@NETBSD.ORG Replace `jrandomdev' by your login name. Note that `@NETBSD.ORG' must be all-uppercase. 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(1) instance as the outgoing SMTP server; see below. * msmtp(1)/msmtpd(1): Set up ~/.msmtprc with: defaults account netbsd user jrandomdev auth gssapi from jrandomdev@NetBSD.org set_msgid_header off host mail.NetBSD.org port 465 tls on tls_starttls off account default : netbsd Replace `jrandomdev' by your login name. Now you can use msmtp(1) as a substitute for `/usr/sbin/sendmail -oi'. Or start msmtpd(1) to run a local SMTP server listening on port 25 by default, or under inetd(8), and use that as your outgoing SMTP server. 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 details. 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), replacing `jrandomdev' by your login name: 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 (~postfix/.krb5/config) containing the two lines: [libdefaults] name_canon_rules = as-is:match_domain=NetBSD.org Reload the postfix configuration: # postfix check # service postfix reload Get a ticket for postfix to use: # HOME=/var/spool/postfix su -m postfix -c 'kinit jrandomdev@NETBSD.ORG' jrandomdev@NETBSD.ORG's Password: You can revoke it by running kdestroy(1) as user postfix. (The ticket will be stored in /tmp/krb5cc_$(id -u postfix) by default; you can also 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