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:35]
fishy External IP, selecting cert-files. 		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 177: Line 182:
 accept for all relay via smtp.example.com tls enable auth accept for all relay via smtp.example.com tls enable auth
 </code>   </code>  
 +
 +As far as I can tell, there is one significant limitation to SMTP Auth in smtpd currently:
 +users are authenticated against the local user database. This means that all users that
 +are to be authenticating their SMTP connections, have to have some form of local authentication
 +on the OpenBSD box serving SMTP. Yes, these accounts may be non-login-accounts, and yes,
 +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.
 +
 +> //**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 240: 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 294: 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.//
  
 
You are here: start » guides » opensmtpd
Trace:
guides/opensmtpd.1256427358.txt.gz · Last modified: 2009/10/25 01:35 by fishy