Changes RSS

====== Differences ====== This shows you the differences between two versions of the page.

Link to this comparison view

guides:opensmtpd [2009/10/25 01:50]
fishy Local auth...
guides:opensmtpd [2009/12/01 21:30] (current)
fishy Disclaimer...
Line 1: Line 1:
 ====== OpenBSD SMTPd ====== ====== OpenBSD SMTPd ======
 +
 +>  **(!) NOTE:**
 +> //My words about maturity and documentation are rendered void by the development that has been happening since 4.6-release. By following -current, you will have access to better documentation, added features and a more stable smtpd.\\
 +Please read http://www.openbsd.org/faq/current.html for information on following -current.//
 +
  
 As of version 4.6 of [[http://www.openbsd.org/|OpenBSD]], a new alternative MTA is available.  As of version 4.6 of [[http://www.openbsd.org/|OpenBSD]], a new alternative MTA is available. 
Line 184: Line 189:
 external authentication mechanisms may be plugged into the OpenBSD auth system. But I personally would external authentication mechanisms may be plugged into the OpenBSD auth system. But I personally would
 really like to be able to have SMTP user accounts separate from user accounts on my SMTP gateway. really like to be able to have SMTP user accounts separate from user accounts on my SMTP gateway.
 +
 +> //**Update**//: Different authentication backends are in the works!
 +> Posted the same day I wrote the article, gilles@ comments that mapping to db's and other backends is to come: http://undeadly.org/cgi?action=article&sid=20091013122256&pid=2
  
 ==== Adding SMTPS without authentication ==== ==== Adding SMTPS without authentication ====
Line 247: Line 255:
  
   makemap /etc/mail/secrets   makemap /etc/mail/secrets
 +
 +When working with different relays for different recipients, I also discovered some peculiarity.
 +The documentation tells that wildcards are supported. Make sure that you check the following if you
 +want to do wildcards:
 +
 +Quotes are required on wildcards. Follow the syntax:
 +
 +  accept for domain example.com     # <- This is valid, as it involves no wildcard.
 +  accept for domain *.example.com   # <- This is INvalid, wildcards require quotes
 +  accept for domain "*.example.com"  # <- This is valid syntax with wildcards.
 +
 +... so it is probably best to get in the habit of adding quotes to all domains...
 +
 +Check the scope of your wildcard. If you are running "mail.com", you probably do not
 +want your wildcard to glob "gmail.com" and "hotmail.com". So, add that dot. But when you
 +add that dot, your wildcard no longer matches the "stem". So, to match all "mail.com" adresses
 +without globbing too much, you need two "accept .. for" rules:
 +
 +  accept ... for domain "*.mail.com" ...
 +  accept ... for domain "mail.com" ...
 +
 +Also make sure you have your relaying chains set up for all __from__ definitions you have...
  
 ==== Multiple external IP addresses ==== ==== Multiple external IP addresses ====
Line 301: Line 331:
 to the "certificate" option, and that certs need to live in /etc/mail/certs, regardless of wether the to the "certificate" option, and that certs need to live in /etc/mail/certs, regardless of wether the
 cert is auto-located or manually defined. cert is auto-located or manually defined.
 +
 +==== Transparent redirection of SMTP ====
 +
 +As mentioned early, I intended to do transparent redirection of internally generated mail.
 +This is naturally handled by pf. The configurations I am splaying now are closer to reality
 +than the previous ones, so it is probably also appropriate to add some info about my home setup:
 +
 +=== The setup ===
 +
 +  * My connection to the world is handled by an OpenBSD installation with pf and NAT.
 +  * My external connection has several IP-adresses on the interface rl0. For sake of example, let us call these: 
 +    * 172.16.81.241
 +    * 172.16.81.242
 +    * 172.16.81.243
 +    * 172.16.81.244
 +    * 172.16.81.245
 +  * The first address is used for NAT of my internal "home" network
 +  * The following addresses are binat'ed to my "DMZ" network
 +  * I am running VLAN tagging to separate my networks:
 +    * VLAN id 1 is used for netboxes, no user equipment. IP-range 10.0.1.0/24
 +    * VLAN id 2 is used for DMZ, IP-range 10.0.2.0/24
 +    * VLAN id 3 is used for my internal net, IP-range 10.0.3.0/24
 +    * All VLAN's are mapped directly numeric to interface names.
 +  * The internal network is fully nat'ed.
 +  * The OpenBSD box holds the .1 IP-adress inn all VLANs.
 +  * My troublesome external client has the IP 172.16.17.18
 +
 +=== The smtpd.conf ===
 +
 +<code>
 +listen on lo0
 +listen on vlan1
 +listen on vlan1 smtps certificate home.defcon.no
 +listen on 172.16.81.241 port 465 smtps certificate home.defcon.no enable auth
 +
 +map "aliases" { source db "/etc/mail/aliases.db" }
 +map secrets { source db "/etc/mail/secrets.db" }
 +
 +accept for local deliver to mbox
 +
 +# I really would have liked the "from local" keyword.
 +# That one is available in CVS, but I am not running CVS -current :(
 +accept for domain "rt.defcon.no" relay via rt.home.defcon.no
 +accept for domain "*.defcon.no" relay via mail.defcon.no
 +accept for domain "defcon.no" relay via mail.defcon.no
 +
 +# For the internal networks
 +accept from 10.0.0.0/22 for domain "rt.defcon.no" relay via rt.home.defcon.no
 +accept from 10.0.0.0/22 for domain "*.defcon.no" relay via mail.defcon.no
 +accept from 10.0.0.0/22 for domain "defcon.no" relay via mail.defcon.no
 +accept from 10.0.0.0/22 for domain gmail.com relay via smtp.gmail.com ssl enable auth
 +accept from 10.0.0.0/22 for all relay via smtp.hig.no tls enable auth
 +
 +# For troublehost
 +accept from 172.16.17.18 for domain "rt.defcon.no" relay via rt.home.defcon.no
 +accept from 172.16.17.18 for domain "*.defcon.no" relay via mail.defcon.no
 +accept from 172.16.17.18 for domain "defcon.no" relay via mail.defcon.no
 +accept from 172.16.17.18 for domain gmail.com relay via smtp.gmail.com ssl enable auth
 +accept from 172.16.17.18 for all relay via smtp.hig.no tls enable auth
 +
 +# All other (local) mail, including authenticated.
 +accept for all relay via smtp.hig.no tls enable auth
 +</code>
 +
 +=== The pf.conf ===
 +
 +<code>
 +# The internal network is NAT'ed
 +nat on rl0 from 10.0.3.0/24 -> 172.16.81.241
 +# ...while the 'DMZ' is binat'ed
 +binat on rl0 from 10.0.2.2 to any -> 172.16.81.242
 +binat on rl0 from 10.0.2.3 to any -> 172.16.81.243
 +binat on rl0 from 10.0.2.4 to any -> 172.16.81.244
 +binat on rl0 from 10.0.2.5 to any -> 172.16.81.245
 +
 +# This is the transparent redirect! I am running smtpd on my
 +# VLAN1 IP so that the box it self is not trapped by rdr ;)
 +# I am also transparently redirecting SSL/SMTPS on both "standard" ports..
 +rdr pass on vlan2 proto tcp to any port 25 -> 10.0.1.1 port 25
 +rdr pass on vlan2 proto tcp to any port 465 -> 10.0.1.1 port 465
 +rdr pass on vlan2 proto tcp to any port 587 -> 10.0.1.1 port 465
 +rdr pass on vlan3 proto tcp to any port 25 -> 10.0.1.1 port 25
 +rdr pass on vlan3 proto tcp to any port 465 -> 10.0.1.1 port 465
 +rdr pass on vlan3 proto tcp to any port 587 -> 10.0.1.1 port 465
 +
 +# Some filter rules for good measure... Nothe, this is absolutely not what
 +# is running in prod, but it is a minimum that works ;)
 +
 +# Block all unknown traffic
 +block in log
 +# Permit all "known" traffic, unless we block it again later. And keep state!
 +pass in log on vlan2 keep state
 +pass in log on vlan3 keep state
 +
 +# No, DMZ is not allowed to communicate with internal computers,
 +# unless asked to do so...
 +block in log on vlan2 inet to 10.0.3.0/24
 +
 +# Allow rdr'ed and binat'ed traffic in to the DMZ
 +pass in log on rl0 inet from any to 10.0.2.2 keep state
 +pass in log on rl0 inet from any to 10.0.2.3 keep state
 +pass in log on rl0 inet from any to 10.0.2.4 keep state
 +pass in log on rl0 inet from any to 10.0.2.5 keep state
 +
 +# Permit incoming SMTPS to gw.home.defcon.no from the world.
 +pass  in log on rl0 inet proto tcp from any to 172.16.81.241 port 465
 +pass  in log on rl0 inet proto tcp from any to 172.16.81.241 port 587
 +
 +# But block any unsolicited SMTP
 +block in log on rl0 inet proto tcp from any to 10.0.2.0/24 port 25
 +</code>
 +
 +So, that was a bit more pf.conf listing that strictly needed for the smtpd
 +example, so here are the relevant parts separated:
 +
 +<code>
 +rdr pass on vlan2 proto tcp to any port 25 -> 10.0.1.1 port 25
 +rdr pass on vlan2 proto tcp to any port 465 -> 10.0.1.1 port 465
 +rdr pass on vlan2 proto tcp to any port 587 -> 10.0.1.1 port 465
 +rdr pass on vlan3 proto tcp to any port 25 -> 10.0.1.1 port 25
 +rdr pass on vlan3 proto tcp to any port 465 -> 10.0.1.1 port 465
 +rdr pass on vlan3 proto tcp to any port 587 -> 10.0.1.1 port 465
 +pass  in log on rl0 inet proto tcp from any to 172.16.81.241 port 465
 +pass  in log on rl0 inet proto tcp from any to 172.16.81.241 port 587
 +</code>
 +
 +===== Final words =====
 +
 +The new smtpd in OpenBSD is, as you hopefull have seen through my examples, really very
 +simple to set up and configure. It has tolerated my stress-testing really well, and shows
 +great promise.
 +
 +The version that ships with OpenBSD 4.6 is probably not something I personally would put
 +into production for a large-scale system quite yet, but work is progressing with good
 +updates in CVS, and I am expecting this to be "large-scale capable" by the time 4.7 is
 +out. But to achieve main-stream adoption, the documentation really needs more content
 +and more examples.
 +
 +For a smaller setup, like a small to medium company, or home use, smtpd is really quite
 +complete, and a lot less pain to get running than most other MTA's.
 +
 +In this walk-through, I have not touched on virtual domains at all, and that is
 +probably for the better, as the implementation if virtual domains in 4.6 (release) and
 +CVS (current) is quite different.
 +
 +My next step is to re-introduce my old spamd setup, and get spamd and smtpd to "talk nice"
 +with each other, while still maintaining separate logic for internal and external use.
 +
 +I would really love to see a sensible way to handle authentication for non-local user accounts.
 +This may really already be supported somehow, and if that is the case, my knowledge of
 +BSD Auth is apparently not aboce "newb" level...
 +> //**Update**//: Different authentication backends are in the works!
 +> Check the comment under the heading [[#Adding SMTPS with authentication]].
 +
 +> **(!) NOTE:**\\
 +> //My words about maturity and documentation are rendered void by the
 +> development that has been happening since 4.6-release. By following -current,
 +> you will have access to better documentation, added features and a more stable smtpd.
 +> Please read http://www.openbsd.org/faq/current.html for information on following -current.//