OpenBSD Journal

Developer Blog - gilles@ on smtpd

Contributed by weerd on from the you've-got-mail dept.

Very recently, Gilles Chehade (gilles@) imported his smtpd into OpenBSD base. Since then, there's been some activity around the code in cvs. To give users some insight into the reasons for writing smtpd and the design behind it, Gilles writes in with a developer blog on smtpd.

I had been running Postfix for four or five years when I decided to switch to sendmail. Postfix had a license that prevented it from getting commited into base, which meant it would not get audited and would force me to go through more work to keep it updated and reinstalled after each OpenBSD reinstall ... twice a year. I had rather simple needs so the stock sendmail would do just fine.

A few months ago, I had to dive into the configuration of sendmail to make a very small change. It turns out I spent almost an hour trying to make sense out of a maze of files that were plain unreadable. Even the slightest changes would cause me to stand a couple minutes thinking, just trying to make sure I really wanted to make that change.

It pissed me off enough that I grabbed my laptop and a copy of rfc2821 with me to the pub where I started writing the first bricks of a very simple smtp server. After two or three hours, I had a little piece of code which would understand a simple smtp session, with no protocol error checking, and would deliver it to my mailbox in both Maildir and mbox formats. It was not THAT great, but it was just enough to keep me motivated ;-)

The next days I studied imsg and started making use of it while I implemented privilege separation, privilege dropping and chrooting into smtpd. I commited all the code to the private cvs repository that I was using, and showed it to chl@ so he could tell me what he thought about it. chl@ started reading the code and sending more and more diffs, the smtpd soon got basic support for aliases, mailer daemons and relaying.

After a couple weeks of hard work and late commits, I contacted pyr@ and told him about smtpd while showing him the code and a proof of concept running on one of my servers. I was a bit nervous about his reaction but he was quite motivated as he had ... ideas ;-)

pyr@ was ok with most of the code except that it wasn't doing things in the OpenBSD way and he wanted smtpd to be fully asynchronous. We decided that the best idea would be to create a separate cvs module where he would basically put the infrastructure for smtpd. Infrastructure contained mostly code that does not know anything about the smtp protocol but was rather aimed at providing an OpenBSD look and feel to the code and config.

He did an amazing job, the new parse.y replaced my named-like syntax with a pf-like one which turned something like:

	listener 127.0.0.1:25 {
		hostname mx1.poolp.org
		domain poolp.og {
			store to mbox
		}
	}

into the almost final:

	listen on 127.0.0.1 port 25
	hostname mx1.poolp.org
	accept domain "poolp.org" store to mbox

His code also simplified the setup and use of imsg through the entire project. Smtpd has several processes and setting up the pipes correctly is not as easy as it looks. He came up with an elegant solution which is likely to be adapted elsewhere later.

Work continued at a slower pace until I was able to go to Slackathon, where I had a lot of free time to fix broken code and implement new features. The smtp trafic was limited which made me run into bugs which would trigger in weird situations (i.e. being able to resolve a remote MX but not being able to connect to it) but also forced me into coding features such as the "relay via" which I would use to redirect smtp trafic and bypass a MX resolution to perform a direct connection to another host. During Slackathon, I made a lot of progress on supporting aliases and virtual users, implemented forward files so that it became possible to run applications like vacation(1), improved support for grey listing and made various changes to the queue so that it would be simpler and would not consume as much memory under heavy load.

Since I came back from Sweden, I spent most of my hacking time trying to clean up, make code simpler and fixing all bugs I've been made aware of. smtpd has been running on my own server for several weeks, allowing me to spot "live" bugs and fixing them.

Recently, I started implementing very basic and limited support for SMTP AUTH, which is one of the features I need and has been requested the most, the goal being to have this support work out of the box.

The current state of smtpd is basically "don't use it live unless you want to help test and spot bugs", but out of the box it currently supports:

  • IPv6 fully, it accepts, resolves and connects to IPv6 enabled hosts
  • SSL/TLS if a certificate is found in /etc/mail/certs/
  • aliases/virtual users/forward files
  • using external MDA such as procmail

There is still a loooooot of work to do though ...

A lot of developers have provided very helpful comments and testing, they know who they are and they deserve a HUGE thanks ;-)

Thanks, Gilles, for your work on smtpd and for taking the time to write this blog.

(Comments are closed)


  1. By 4420 (85.15.231.91) on

    will it be of a modular design, just like postfix?

    i.e., each daemon fulfills a single task using minimum privileges.

    1. By gilles (gilles) on http://www.poolp.org/~gilles/

      > will it be of a modular design, just like postfix?
      >
      > i.e., each daemon fulfills a single task using minimum privileges.

      yes, the daemon is multi-process with privilege separation.
      most of the processes are unprivileged and chrooted, the two exceptions being the process in charge of performing lookups which is unprivileged but not chrooted, and the parent process which is in charge of starting smtpd and handing over descriptor to mailboxes/maildir which has to run privileged and unchrooted.

      Gilles

      1. By jirib (85.207.203.106) on

        > > will it be of a modular design, just like postfix?
        > >
        > > i.e., each daemon fulfills a single task using minimum privileges.
        >
        > yes, the daemon is multi-process with privilege separation.
        > most of the processes are unprivileged and chrooted, the two exceptions being the process in charge of performing lookups which is unprivileged but not chrooted, and the parent process which is in charge of starting smtpd and handing over descriptor to mailboxes/maildir which has to run privileged and unchrooted.
        >
        > Gilles

        how would you implement sasl?

        1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

          > > > will it be of a modular design, just like postfix?
          > > >
          > > > i.e., each daemon fulfills a single task using minimum privileges.
          > >
          > > yes, the daemon is multi-process with privilege separation.
          > > most of the processes are unprivileged and chrooted, the two exceptions being the process in charge of performing lookups which is unprivileged but not chrooted, and the parent process which is in charge of starting smtpd and handing over descriptor to mailboxes/maildir which has to run privileged and unchrooted.
          > >
          > > Gilles
          >
          > how would you implement sasl?

          What do you mean by "how" ? :-)

      2. By Arach (87.103.146.206) on

        > yes, the daemon is multi-process with privilege separation.
        Any chances to see the design sheet or slides in the near future?

        1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

          > > yes, the daemon is multi-process with privilege separation.
          > Any chances to see the design sheet or slides in the near future?

          There is src/usr.sbin/smtpd/ARCHITECTURE which lags a bit behind reality but describes the ... architecture.

          1. By Arach (87.103.146.206) on

            > There is src/usr.sbin/smtpd/ARCHITECTURE which lags a bit behind reality but describes the ... architecture.

            Thanks! Looks interesting. But could you explain a little bit, how authentication is (and will be) implemented?

            Do you have any considerations about separate authentication processes? Maybe something like Dovecot's authentication processes?

            http://wiki.dovecot.org/Design/Processes
            "Authentication process

            Authentication process handles everything related to the actual authentication: SASL authentication mechanisms, looking up and verifying the passwords and looking up user information.

            It listens for two different kinds of connections: untrusted authentication client connections (from login processes) and master connections (from master process, but also from Dovecot LDA). The client connections are only allowed to try to authenticate. The master connections are allowed to ask if an authentication request with given ID was successful, and also to look up user information based on a username. This user lookup feature is used by Dovecot LDA."

            Also, do you plan to implement some sort of SASL-like authentication protocol (client and/or server side) for making external authdb/userdb lookups over sockets and/or serving external authdb lookups? Dovecot has an example:

            http://wiki.dovecot.org/Authentication_Protocol

            If a client side of such a protocol would be implemented in smtpd, that will make it possible to keep all the weird authentication and user db backends out of smtpd, and anyone will be able to write his/her own backends. I will, that's for sure... :)

            P.S.
            Arghhh! A feature request! You got me. :)

            1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

              > > There is src/usr.sbin/smtpd/ARCHITECTURE which lags a bit behind reality but describes the ... architecture.
              >
              > Thanks! Looks interesting. But could you explain a little bit, how authentication is (and will be) implemented?
              >
              > Do you have any considerations about separate authentication processes? Maybe something like Dovecot's authentication processes?
              >
              > http://wiki.dovecot.org/Design/Processes
              > "Authentication process
              >
              > Authentication process handles everything related to the actual authentication: SASL authentication mechanisms, looking up and verifying the passwords and looking up user information.
              >
              > It listens for two different kinds of connections: untrusted authentication client connections (from login processes) and master connections (from master process, but also from Dovecot LDA). The client connections are only allowed to try to authenticate. The master connections are allowed to ask if an authentication request with given ID was successful, and also to look up user information based on a username. This user lookup feature is used by Dovecot LDA."
              >

              Nothing is final yet which is why I don't want to expand too much on this, but what was planned was to use the lookup process since authentication is basically credentials lookup. I have a basic AUTH PLAIN implementation where the smtp server forwards the authentication to the lookup process, which in turn hands it over to the only privileged process in smtpd. The indirection is basically because the lookup process will be taking the decision as to which backend to use depending on configuration, and defaulting to testing for a system user. This support has been commented, as it was mostly testing, but something quite similar will be used in the end.


              > Also, do you plan to implement some sort of SASL-like authentication protocol (client and/or server side) for making external authdb/userdb lookups over sockets and/or serving external authdb lookups? Dovecot has an example:
              >

              Likely, my plans were to get basic auth working first as it can solve a fair amount of use cases (at least the cases where you auth against a user account, or against ldap if I understood correctly the goal of the recently imported ypldap). But surely, expanding to a SASL-like mechanism is important.

              Gilles

  2. By Denis (2001:7a8:b5ad:0:fdea:2dc:1768:64e7) on

    Thank you very much for this OpenBSD-style smtpd :)

    1. By Alvaro (170.252.72.61) alvarolists@aycuens.com on http://www.alvarito.org

      Great! This is fantastic, keep up the good work, a clean simple smtpd is very much needed.

    2. By Lars Noodén (84.251.129.228) on

      I look forward to trying Gilles' smtpd

      FWIW there is also a high-traffic Mail Transfer Agent available: <a href="http://rsug.itd.umich.edu/software/simta/">simta</a>

      Being under a BSD license it would at least make the first cut for consideration or else pieces of it might be useful.

  3. By Steve Shockley (68.83.96.160) on

    Any plans for milter support (or equivalent functionality)?

    1. By pyr (193.252.149.222) on

      > Any plans for milter support (or equivalent functionality)?

      Yes, it's been planned in from the beginning.

      1. By gilles (gilles) on http://www.poolp.org/~gilles/

        > > Any plans for milter support (or equivalent functionality)?
        >
        > Yes, it's been planned in from the beginning.

        ... and will be simpler to implement due to the work pyr@ did on the infrastructure he wrote.

        1. By Daniel Ouellet (66.63.10.87) daniel@presscom.net on

          > > > Any plans for milter support (or equivalent functionality)?
          > >
          > > Yes, it's been planned in from the beginning.
          >
          > ... and will be simpler to implement due to the work pyr@ did on the infrastructure he wrote.

          Only one suggestion if I may. Having Bob Becks Grey Scanner built in would also be terrific I have to say. But I know there is a very long road ahead, so it's just that an idea.

          Great work and you should be very proud of your work so far! It really look promessing for sure!

          Best of luck for your well deserved success in the end.

  4. By Mayuresh Kathe (59.182.233.96) kathe.mayuresh@gmail.com on http://kathe.in/

    As I'd said once before, keep up the good work :-)

  5. By greg (80.92.224.11) on

    Haven't checked yet, but perhaps somebody can shed a light on question right now. Is it possible to have two or more separate "listen" instances all with their own rules on how to process mail?

    i.e
    listen on some_address
    accept ..... deliver ....

    listen on other_address
    accept .... deliver ....

    also do you plan to implement UCE/ACLs?

    Thanks a lot for the very good job done.

    1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

      > Haven't checked yet, but perhaps somebody can shed a light on question right now. Is it possible to have two or more separate "listen" instances all with their own rules on how to process mail?
      >
      > i.e
      > listen on some_address
      > accept ..... deliver ....
      >
      > listen on other_address
      > accept .... deliver ....
      >

      There used to be support for this, but after discussing with pyr@ we decided that unless someone comes with a good explanation as to why this is really needed, we will not support this. It adds code complexity for no benefit, the rules by themselves are sufficient to solve most use cases.

      If someone comes up with a really good example of why we want this, we can later add it on without too much hassle.


      > also do you plan to implement UCE/ACLs?
      >

      Definitely, ACLs are already implemented as you can see from the sample smtpd.conf that got commited, UCE will have to wait until we have the milter-like interface, which is quite high on my priority list.

      Gilles

      1. By Anonymous Coward (208.181.67.27) on

        > > Haven't checked yet, but perhaps somebody can shed a light on question right now. Is it possible to have two or more separate "listen" instances all with their own rules on how to process mail?
        > >
        > > i.e
        > > listen on some_address
        > > accept ..... deliver ....
        > >
        > > listen on other_address
        > > accept .... deliver ....
        > >
        >
        > There used to be support for this, but after discussing with pyr@ we decided that unless someone comes with a good explanation as to why this is really needed, we will not support this. It adds code complexity for no benefit, the rules by themselves are sufficient to solve most use cases.
        >
        > If someone comes up with a really good example of why we want this, we can later add it on without too much hassle.
        >
        >
        > > also do you plan to implement UCE/ACLs?
        > >
        >
        > Definitely, ACLs are already implemented as you can see from the sample smtpd.conf that got commited, UCE will have to wait until we have the milter-like interface, which is quite high on my priority list.
        >
        > Gilles
        >

        Will it be possible to set up rules to accept delivery to local domains ONLY on the external interface, while allowing delivery to any address on the internal interface on, eg. as firewall that also acts as a mailserver?
        Great work, BTW!

        -Brian

        1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

          > Will it be possible to set up rules to accept delivery to local domains ONLY on the external interface, while allowing delivery to any address on the internal interface on, eg. as firewall that also acts as a mailserver?

          well if i understand correctly, this is pretty simple:

          listen on $localaddr port 25
          listen on $publicaddr port 25

          accept from 0.0.0.0/0 for domain "local.org" deliver to mbox "/var/mail/%u"
          accept from { 127.0.0.1, ::1 } for any relay

          this will accept mail from anyone for domain "local.org", and will accept only localhost to send mail for any domain.

          Gilles

          1. By pkplex (pkplex) on http://127.0.0.1

            > > Will it be possible to set up rules to accept delivery to local domains ONLY on the external interface, while allowing delivery to any address on the internal interface on, eg. as firewall that also acts as a mailserver?
            >
            > well if i understand correctly, this is pretty simple:
            >
            > listen on $localaddr port 25
            > listen on $publicaddr port 25
            >
            > accept from 0.0.0.0/0 for domain "local.org" deliver to mbox "/var/mail/%u"
            > accept from { 127.0.0.1, ::1 } for any relay
            >
            > this will accept mail from anyone for domain "local.org", and will accept only localhost to send mail for any domain.
            >
            > Gilles

            That pf like syntax is the business :)

      2. By Anonymous Coward (24.75.5.52) on

        Currently, I would find multiple "listen on ..." and "accept ... deliver ..." directives useful. I use spamd and it's greylisting feature as a UCE deterrent. However, because it's handled at such a low level, there is no way in spamd to toggle which domains will use greylisting and which will not (yes, it's true, some people want it off for whatever crazy reason). I use separate IP addresses advertised in MX records as well as multiple MTA instances to differentiate. Being able to handle this with one instance of smtpd would make it play a bit nicer with spamd in this situtation. Though, there is no loss of functionality by not supporting it (I would just stick with multiple instances). Maybe something at the filtering level will even make this a non-issue?

        1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

          > Currently, I would find multiple "listen on ..." and "accept ... deliver ..." directives useful. I use spamd and it's greylisting feature as a UCE deterrent. However, because it's handled at such a low level, there is no way in spamd to toggle which domains will use greylisting and which will not (yes, it's true, some people want it off for whatever crazy reason). I use separate IP addresses advertised in MX records as well as multiple MTA instances to differentiate. Being able to handle this with one instance of smtpd would make it play a bit nicer with spamd in this situtation. Though, there is no loss of functionality by not supporting it (I would just stick with multiple instances). Maybe something at the filtering level will even make this a non-issue?
          >

          Well to be honest I think you are solving this the right way by having the MTA listen on separate addresses and having multiple MX records. I don't understand though why you need multiple MTA instances :/

          Gilles

          1. By danh (71.251.160.14) on

            >
            > Well to be honest I think you are solving this the right way by having the MTA listen on separate addresses and having multiple MX records. I don't understand though why you need multiple MTA instances :/
            >
            > Gilles

            We use sendmail and it's just to enforce greylisting. Basically, one MX accepts mail only for the domains that use greylisting, and the other only for domains that do not use greylisting. Technically, it could use the same instance and allow mail for all domains. It would work, but then there would still be a way to send to the greylisting enabled domains and bypass spamd by using the alternate address. I work in an ISP environment, and spam bots ignoring MX records has been a real issue, so it is not enough to simply advertise separate MX addresses. They will, and do, try a range of IP addresses and domains looking for a lucky hit and attempt to bypass the normal MX records.

            I could probably pull off a single instance with the same restrictions using postfix and multiple smtp services defined in the master.cf with different maps. The alternate MX could instead serve a redundant role rather than a separate function. It would be nice if smtpd could also handle this situation in one instance.

            It's not really a problem, though. Separate instances still work fine. Perhaps I should be greylisting at a higher level even. I just prefer things that are in base and spamd has worked great for us.

          2. By danh (71.251.160.14) on

            listen on $localaddr port 25
            listen on $greylisting port 25
            listen on $nongreylisting port 25

            accept on $greylisting for domain "domain1.com" relay via $internal1
            accept on $nongreylisting for domain "domain2.com" relay via $internal2
            accept on $localaddr relay

            I guess something similar to this would best describe my current MX setup. "on $whatever" for accept being completely optional.

            1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

              > listen on $localaddr port 25
              > listen on $greylisting port 25
              > listen on $nongreylisting port 25
              >
              > accept on $greylisting for domain "domain1.com" relay via $internal1
              > accept on $nongreylisting for domain "domain2.com" relay via $internal2
              > accept on $localaddr relay
              >
              > I guess something similar to this would best describe my current MX setup. "on $whatever" for accept being completely optional.
              >
              >

              Well, this is precisely what we got rid off.
              But i still don't understand what the need for this is:

              listen on $greylisting port 25
              listen on $nongreylisting port 25

              accept from 0.0.0.0/0 for domain "domain1.com" relay via $internal1
              accept from 0.0.0.0/0 for domain "domain2.com" relay via $internal2

              Doesn't this do fundamentally the same ?

              Gilles

              1. By danh (24.75.5.52) on

                > Well, this is precisely what we got rid off.
                > But i still don't understand what the need for this is:
                >
                > listen on $greylisting port 25
                > listen on $nongreylisting port 25
                >
                > accept from 0.0.0.0/0 for domain "domain1.com" relay via $internal1
                > accept from 0.0.0.0/0 for domain "domain2.com" relay via $internal2
                >
                > Doesn't this do fundamentally the same ?
                >
                > Gilles
                >

                No, because nothing is preventing mail from being accepted on $nongreylisting for either domain. It would allow spamd to be bypassed in this setup.

                1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

                  > > Well, this is precisely what we got rid off.
                  > > But i still don't understand what the need for this is:
                  > >
                  > > listen on $greylisting port 25
                  > > listen on $nongreylisting port 25
                  > >
                  > > accept from 0.0.0.0/0 for domain "domain1.com" relay via $internal1
                  > > accept from 0.0.0.0/0 for domain "domain2.com" relay via $internal2
                  > >
                  > > Doesn't this do fundamentally the same ?
                  > >
                  > > Gilles
                  > >
                  >
                  > No, because nothing is preventing mail from being accepted on $nongreylisting for either domain. It would allow spamd to be bypassed in this setup.
                  >

                  Hum, this needs to be given some thoughts ...

              2. By danh (24.75.5.52) on

                > listen on $greylisting port 25
                > listen on $nongreylisting port 25
                >
                > accept from 0.0.0.0/0 for domain "domain1.com" relay via $internal1
                > accept from 0.0.0.0/0 for domain "domain2.com" relay via $internal2

                Hmm. Maybe I'm confusing things.

                listen on $greylisting port 25
                listen on $nongreylisting port 25

                accept to $greylisting for domain "domain1.com" relay via $internal1
                accept to $nongreylisting for domain "domain2.com" relay via $internal2

                I don't know if this any different than "accept on ..." code-wise, but it is a bit more accurate I think. Filtering by the destination address is what I would find useful.

      3. By Jean-Gérard Pailloncy (82.239.202.91) on

        Hi,

        I have a smtp proxy used as an outbound server for some Win^HHH stupid mail systems.

        I use pf.conf to allow only one IPs to connect: the ADSL IP of a buissness client (ex. bizness.com).

        Then in sendmail I use the "from_envellope" unsafe hack to filter the outgoing mail to allow only from email like <some_user@bizness.com>.

        Half the outgoing mails are rejected. Log analyze shows that all are spam, except some double bounced.

        Is this setup possible with the new OpenSTMPd ?

        1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

          > Hi,
          >
          > I have a smtp proxy used as an outbound server for some Win^HHH stupid mail systems.
          >
          > I use pf.conf to allow only one IPs to connect: the ADSL IP of a buissness client (ex. bizness.com).
          >
          > Then in sendmail I use the "from_envellope" unsafe hack to filter the outgoing mail to allow only from email like <some_user@bizness.com>.
          >
          > Half the outgoing mails are rejected. Log analyze shows that all are spam, except some double bounced.
          >
          > Is this setup possible with the new OpenSTMPd ?
          >
          >

          It is not *yet* possible inspect envelope but will be doable when we do the milter-like interface.

          Gilles

      4. By Anonymous Coward (92.104.49.133) on

        > > Haven't checked yet, but perhaps somebody can shed a light on question right now. Is it possible to have two or more separate "listen" instances all with their own rules on how to process mail?
        > >
        > > i.e
        > > listen on some_address
        > > accept ..... deliver ....
        > >
        > > listen on other_address
        > > accept .... deliver ....
        > >
        >
        > There used to be support for this, but after discussing with pyr@ we decided that unless someone comes with a good explanation as to why this is really needed, we will not support this. It adds code complexity for no benefit, the rules by themselves are sufficient to solve most use cases.
        >
        > If someone comes up with a really good example of why we want this, we can later add it on without too much hassle.
        >
        If there are more than one secure smtp domain hosted on the same server there must be a way to bind each ip address with the correct cert file.

        1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

          > > > Haven't checked yet, but perhaps somebody can shed a light on question right now. Is it possible to have two or more separate "listen" instances all with their own rules on how to process mail?
          > > >
          > > > i.e
          > > > listen on some_address
          > > > accept ..... deliver ....
          > > >
          > > > listen on other_address
          > > > accept .... deliver ....
          > > >
          > >
          > > There used to be support for this, but after discussing with pyr@ we decided that unless someone comes with a good explanation as to why this is really needed, we will not support this. It adds code complexity for no benefit, the rules by themselves are sufficient to solve most use cases.
          > >
          > > If someone comes up with a really good example of why we want this, we can later add it on without too much hassle.
          > >
          > If there are more than one secure smtp domain hosted on the same server there must be a way to bind each ip address with the correct cert file.
          >

          You can have several listen directives, you can have them use the same or different certificates, but you cannot have an accept directive apply to one listener and not the other.

          Gilles

  6. By Anonymous Coward (212.27.60.48) on

    "OpenSMTPd is to be released soon."

    -- http://www.opencvs.org/

    1. By Anonymous Coward (70.141.212.164) on

      > "OpenSMTPd is to be released soon."
      >
      > -- http://www.opencvs.org/

      That's actually pretty cool! I'm looking forward to seeing how OpenSMTPd matures. You are right, Sendmail config files are completely alien. Although, I'm using it now for our company's newsletter email server.

      Now what we need is OpenDNSd and OpenDHCPd to round out the network services stack some more. :)

    2. By minusf (92.101.2.64) on

      this was not me :]

  7. By d-ra (84.161.29.185) on

    Thanks for this great work!
    Keep on hackin' !

  8. By Anonymous Coward (85.19.213.88) on

    How will your smtpd compare to, say, sendmail and postfix? Is your goal to completely replace these or will they complement each other (e.g. your smtpd for SOHO and the others for ISP-sized sites)?

    I will, nevertheless, be very grateful the day sendmail is replaced by smtpd and moved to ports.

    1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

      > How will your smtpd compare to, say, sendmail and postfix? Is your goal to completely replace these or will they complement each other (e.g. your smtpd for SOHO and the others for ISP-sized sites)?
      >

      Initial goal is to completely replace sendmail for the setups commonly found here and there: aliases, forward files, several domains, authentication, ssl ... Dealing with ISP-sized sites is something that will eventually come in the long run (and which was taken into account in the initial design) and which will highly depend on developers and users interest in this project.

      Gilles

      1. By Anonymous Coward (67.69.227.99) on

        > > How will your smtpd compare to, say, sendmail and postfix? Is your goal to completely replace these or will they complement each other (e.g. your smtpd for SOHO and the others for ISP-sized sites)?
        > >
        >
        > Initial goal is to completely replace sendmail for the setups commonly found here and there: aliases, forward files, several domains, authentication, ssl ... Dealing with ISP-sized sites is something that will eventually come in the long run (and which was taken into account in the initial design) and which will highly depend on developers and users interest in this project.
        >
        > Gilles
        >

        I'm very interested in this! I'm sure many many others are too, or would be... including those unaware of OpenBSD yet (unfortunately, I know of a lot) - brainwashed by Linux-only marketing. This is another GREAT thing for OpenBSD and the FOSS world as a whole. Glad to see such work in progress!

        OpenBSD, nothing compares.

  9. By Anonymous Coward (170.149.100.10) on

    Oh, wow, that looks awesome. If I had a nickel for every time I've ranted about how absurdly complex smtp daemons are to administrate for the end effect (text blob from point a to b), I'd have enough money to retire to some place sunny and drink away all memories of ever having had to think about them in the first place. ;) The config syntax in particular looks like a huge win; I still have m4-induced traumatic flashbacks from time to time. Good luck and thank you!

  10. By minusf (92.101.2.64) on

    i know this article is about smtpd(8)
    but as you started by mentioning postfix,
    could you please as "admin to the other admin",
    elaborate a bit more how exactly postfix forces
    you to "go through more work to keep it updated
    and reinstalled after each OpenBSD reinstall ...
    twice a year."?

    i mean besides "pkg_add -u".

    it is also interesting to see that after the 4 or 5 years
    you have been using it, you still don't think postfix
    is doing just fine without an openbsd in-house audit.

    dont' get me wrong, it is all nice and dandy that you
    have the skills and the free time to implement an smtpd
    from scratch. but if you can't come up with a compelling
    technical reason why to do so, just blame the license and
    be done with it. spreading fud about postfix is not nice
    you know...

    1. By Brad (216.138.195.228) brad at comstyle dot com on

      The first paragraph is nothing but pure ignorance and FUD. It is ridiculous.

      1. By pkplex (pkplex) on http://127.0.0.1

        > The first paragraph is nothing but pure ignorance and FUD. It is ridiculous.

        Looks looks like a reasonable paragraph to me. Perhaps it needs to be painted a metallic blue, and have a racing stripe, but otherwise it seems fine.

    2. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

      > i know this article is about smtpd(8)
      > but as you started by mentioning postfix,
      > could you please as "admin to the other admin",
      > elaborate a bit more how exactly postfix forces
      > you to "go through more work to keep it updated
      > and reinstalled after each OpenBSD reinstall ...
      > twice a year."?
      >
      > i mean besides "pkg_add -u".
      >

      You took the sentence out of context.

      I did not say postfix forces anything, I said that postfix not being in base forced me into more work as every time I would install OpenBSD, I would also have to install and configure postfix, whereas slight configuration changes to the shipped sendmail was sufficient for me. I used to reinstall OpenBSD on a set of boxes twice a year and this meant extra work on all of these. *MY* use of OpenBSD at that time made the use of postfix extra work.

      Besides, pkg_add -u did not exist back then (appeared in 3.9) and will only work if you upgrade OpenBSD, not if you reinstall, say to prepare a clone system for preproduction.


      > it is also interesting to see that after the 4 or 5 years
      > you have been using it, you still don't think postfix
      > is doing just fine without an openbsd in-house audit.
      >

      It is doing fine, but I'd rather use on OpenBSD a daemon that was designed for OpenBSD and for which bugfixes and advisories will be released at the same place than for all the other daemons I run.

      This has *nothing* to do with postfix doing fine or not, it is a matter of simplicity in my daily work: looking at one errata page vs. looking at various websites. If I want to run a service, and there's a daemon provided by OpenBSD, then I tend to go for that daemon instead of adding one website to the list I need to monitor for bugfixes.


      > dont' get me wrong, it is all nice and dandy that you
      > have the skills and the free time to implement an smtpd
      > from scratch. but if you can't come up with a compelling
      > technical reason why to do so, just blame the license and
      > be done with it. spreading fud about postfix is not nice
      > you know...
      >

      I don't spread FUD, you took a sentence out of context and interpreted it with the false assumption that I don't like postfix, even though I said I had been using it for years which is a clear hint that it was my best choice at some point.

      Now, I'd rather not spend too much time on this discussion, I just took time to make it clear that I have nothing against postfix, except for its license. smtpd is a fun project with fun constraints, which is the main reason I work on it.

      Gilles

      1. By minusf (92.101.2.64) on

        i am sorry but this makes little sense.
        call me a troll if you will.

        i hope you do realise how silly your install/clone/configuration
        arguments look like. so it was too difficult and tiring
        to create an infrastructure (for 4 or 5 years) to deal with
        installing/upgrading a couple of extra packages and following
        2 rss feeds instead of one, but it was not too time consuming
        and difficult to write a new mail daemon from scratch.
        your definition of easy must me very different from mine.

        > I don't spread FUD, you took a sentence out of context and
        > interpreted it with the false assumption that I don't like
        > postfix, even though I said I had been using it for years
        > which is a clear hint that it was my best choice at some point.

        if someone tries to replace postfix with sendmail,
        that hardly makes that person look like they are fond of
        postfix, that's for sure :]

        > Now, I'd rather not spend too much time on this discussion,
        > I just took time to make it clear that I have nothing against
        > postfix, except for its license. smtpd is a fun project with
        > fun constraints, which is the main reason I work on it.

        yes, it is clear now. although the article intro definitely
        doesnt come out like that, i am sorry. it sounds as if
        postfix was hard to install and/or upgrade and difficult
        to configure, so let's write a new one.

        now you know how hard it is to write something and other
        people not to tear it apart, cough cough. welcome to the
        world of electronic communication.

        of course, in the end reasons don't matter anyway. if smtpd
        will be good enough to replace sendmail, good job, sendmail
        overstayed its welcome way too long. choice is always a good
        thing.

        maybe next time lose the secrecy so people (me) don't
        speculate and confirm further the openbsd team's inability
        to communicate without resorting to calling names.

        also, i am sorry to rain on your grand opening parade about
        smtpd at opencon. it wasn't intentional. you reached the
        soft limit on cvs commits-without-announcement :]

        1. By Anonymous Coward (201.81.193.91) on

          > i am sorry but this makes little sense.
          > call me a troll if you will.
          Troll.

          1. By Anonymous Coward (86.121.135.223) on

            "simple needs" + "stock sendmail" => "postfix replaced"
            Wtf is offensive here to postfix?

        2. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

          > i hope you do realise how silly your install/clone/configuration
          > arguments look like. so it was too difficult and tiring
          > to create an infrastructure (for 4 or 5 years) to deal with
          > installing/upgrading a couple of extra packages and following
          > 2 rss feeds instead of one, but it was not too time consuming
          > and difficult to write a new mail daemon from scratch.
          > your definition of easy must me very different from mine.
          >

          No, I don't realize how silly my arguments are.

          I do realize however that you know nothing about the problems we faced, the constraints we had and the solutions we evaluated. However, you are trying to convince me that postfix was the right solution without knowing anything about the situation. Please, unless you are able to make an informed comment, keep your comments to yourself.

          I currently have time to consume on writing a smtpd, I did not have it back when we switched from postfix to sendmail. See ? different times, different events, different problems and different solutions.


          > > [...]

          > > Now, I'd rather not spend too much time on this discussion,
          > > I just took time to make it clear that I have nothing against
          > > postfix, except for its license. smtpd is a fun project with
          > > fun constraints, which is the main reason I work on it.
          >
          > yes, it is clear now. although the article intro definitely
          > doesnt come out like that, i am sorry. it sounds as if
          > postfix was hard to install and/or upgrade and difficult
          > to configure, so let's write a new one.
          >

          It is fine as it is, there is no comment on how easy or hard it is to install postfix, your love for postfix makes you interpret things the wrong way. Too bad, I won't spend more time on the article and you'll have to live with it.


          > maybe next time lose the secrecy so people (me) don't
          > speculate and confirm further the openbsd team's inability
          > to communicate without resorting to calling names.
          >

          There was no secrecy, just a matter of priorities in private life.
          I don't owe you explanations, but just for the record, you're making a big deal because I waited a week before I wrote a story on code that got commited but which is not yet usable by users and not yet linked to the build ... and you're criticizing that same story because it doesn't please you. Who has an inability to communicate again ?


          > also, i am sorry to rain on your grand opening parade about
          > smtpd at opencon. it wasn't intentional. you reached the
          > soft limit on cvs commits-without-announcement :]

          You're not raining any grand opening parade, my "talk" at OpenCON was an error as I won't be able to go there.

          After reading this mail I can safely assume you are a troll and unless you come up with questions that have real interest, I will leave you trolling and ignore you.

          Gilles

          1. By minusf (195.168.92.92) on

            > I do realize however that you know nothing about the problems we faced,
            > the constraints we had and the solutions we evaluated. However, you are

            well, your article was about letting us know, wasn't it?...
            that was the whole point starting your work.
            yet you keep it to yourself. well done.


            you talk about me taking sentences out of context
            yet you put words in my mouth throughout all your answer.

            frankly, i am quite sick of this "i dont like your questions
            so yo must be a troll" stance of many of the developers.
            how convinient. you want troll? proper troll? how about
            "omg they imported a non-working smtp daemon in the tree!
            it doesn't even compile!" (it does)

            look, it is easy. my mail on misc@ and the posts here all
            boil down to one single question that you consistently fail
            to answer every time and call me names instead. i think
            actually a lot of people are interested in this:

            what was the technical reason you started working on smtpd(8)?

            and no, license and free time and security announcements
            (that come once in a blue moon about E.G. postfix) are not
            technical reasons.

            yet i am repeatedly called a troll because i am interested
            in your motivation. your article failed to answer exactly
            what was the itch you tried to scratch---the most basic
            question of all. am i asking too much?

            > Who has an inability to communicate again ?

            if you can't go to OpenCON i think it would have been nice
            to answer in the thread on misc@ to Mathias Reitinger's mail...


            ps. it was not a my "mail" but a forum post...

            1. By Anonymous Coward (71.130.195.212) on

              > and no, license and free time and security announcements
              > (that come once in a blue moon about E.G. postfix) are not
              > technical reasons.

              Hm, you just invalidated the reasons for postfix there too...

            2. By Anonymous Coward (89.77.225.214) on


              a) because he can
              b) because it's fun
              c) having stuff in base is simpler than having stuff in ports
              d) it's all a conspiracy
              e) all of the above

              choose three and move on...

              ps. Gilles, just do your thing and don't worry about justifying yourself

            3. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

              > > I do realize however that you know nothing about the problems we faced,
              > > the constraints we had and the solutions we evaluated. However, you are
              >
              > well, your article was about letting us know, wasn't it?...
              > that was the whole point starting your work.
              > yet you keep it to yourself. well done.
              >

              bla bla bla.
              my article was a short introduction to the project, not a biography.
              it will stay as it is, no matter how much you rant, live with it.


              > you talk about me taking sentences out of context
              > yet you put words in my mouth throughout all your answer.
              >
              > frankly, i am quite sick of this "i dont like your questions
              > so yo must be a troll" stance of many of the developers.
              > how convinient. you want troll? proper troll? how about
              > "omg they imported a non-working smtp daemon in the tree!
              > it doesn't even compile!" (it does)
              >

              You are a troll.
              I answered every question that were asked so far. The only reason that I don't answer yours is because you don't ask them politely and you do look for confrontation.

              Until you learn the difference between:

              "why did you start this project ?"

              and

              "why did you start this project ? im sure it will not be usable just like opencvs, you are stupid for having started it, you should use your time differently, rewrite your article, you are not doing things the way I want, you are not telling people fast enough, you live in secrecy ... bleh"

              then I don't care about your opinion and I don't care about answering YOUR questions. Too bad I don't care what you have to say...


              > look, it is easy. my mail on misc@ and the posts here all
              > boil down to one single question that you consistently fail
              > to answer every time and call me names instead. i think
              > actually a lot of people are interested in this:
              >
              > what was the technical reason you started working on smtpd(8)?
              >

              I have not called you names ... yet.
              I will still not answer your question, not until you apologize for the aggressive tone and you admit that you've been acting like an arrogant asshole. I don't owe you ANYTHING. Pay me for smtpd development and I will happily make slides and wear a tie for the presentation. Contact me off undeadly so I can give you my paypal.


              > and no, license and free time and security announcements
              > (that come once in a blue moon about E.G. postfix) are not
              > technical reasons.
              >

              Too bad you are not in a position to take decisions.


              > yet i am repeatedly called a troll because i am interested
              > in your motivation. your article failed to answer exactly
              > what was the itch you tried to scratch---the most basic
              > question of all. am i asking too much?
              >

              Yes, you are asking too much.
              Not only you are asking too much, but you are even asking it inappropriately. And this is the second time I tell you, the first time was when you sent the initial mail where I basically told you I would not answer your questions because I did not like the tone of your mail.


              > > Who has an inability to communicate again ?
              >
              > if you can't go to OpenCON i think it would have been nice
              > to answer in the thread on misc@ to Mathias Reitinger's mail...
              >

              Oh, so you also get to decide which mails I read and answer ?
              It must be a tough position to be king of the developers ...

              Gilles

              1. By minusf (92.101.2.64) on



                > "why did you start this project ? im sure it will not be usable
                > just like opencvs, you are stupid for having started it, you should
                > use your time differently, rewrite your article, you are not doing
                > things the way I want, you are not telling people fast enough, you
                > live in secrecy ... bleh"

                putting words into my mouth.

                > I will still not answer your question, not until you apologize
                > for the aggressive tone and you admit that you've been acting like
                > an arrogant asshole. I don't owe you ANYTHING. Pay me for smtpd

                i have apologized right after your reply to misc@
                still not enough for your ego?

                > development and I will happily make slides and wear a tie for the
                > presentation. Contact me off undeadly so I can give you my paypal.

                i wouldn't pay you if you were the last developer on earth.


                theo has taught you well young one.
                the circle is now complete.

                1. By Anonymous Coward (82.101.210.49) on

                  > theo has taught you well young one.
                  > the circle is now complete.

                  Actually, gilles@ has been extremely patient throughout your trolling. Which is very much unlikely the stereotypical developer. So I don't think he's taking lesson from Theo at all. It is unfortunate that his patience has not been rewarded with thoughtful questions.

                  1. By minusf (195.168.92.92) on


                    > Actually, gilles@ has been extremely patient throughout your trolling.

                    no, actually he hasn't.
                    all he's been doing is putting words into my mouth
                    and demanding apologies.

                    i don't owe him anything either.

                    1. By Anonymous Coward (98.219.132.3) on

                      >
                      > > Actually, gilles@ has been extremely patient throughout your trolling.
                      >
                      > no, actually he hasn't.
                      > all he's been doing is putting words into my mouth
                      > and demanding apologies.
                      >
                      > i don't owe him anything either.

                      Shut up and go home to your mom, whiner.

                    2. By Arach (87.103.146.206) on

                      > all he's been doing is putting words into my mouth
                      > and demanding apologies.

                      Oh, come on. There is a obvious difference between putting words into your mouth and explaining what your complaints does sound like. And know what? Mature people doesn't need this difference to be explained.

                2. By Anonymous Coward (24.87.65.150) on

                  What was your mother's motivation for pushing your ugly head out of her vagina? If I were her, I would have aborted knowing what a moron you'd turn out to be.

                3. By Chris (142.132.30.115) on


                  >
                  > theo has taught you well young one.
                  > the circle is now complete.

                  Oh ho ho, and here it is!

                  OpenBSD sure attacks its share of nerds with huge chips on their shoulders. Must be doing something right.

                  1. By Chris (142.132.30.115) on

                    >
                    > >
                    > > theo has taught you well young one.
                    > > the circle is now complete.
                    >
                    > Oh ho ho, and here it is!
                    >
                    > OpenBSD sure attacks its share of nerds with huge chips on their shoulders. Must be doing something right.

                    *attracts. But really both, in the end :)

            4. By Isak Lyberth (87.60.203.164) isak@lyberth.dk on Jelling

              > look, it is easy. my mail on misc@ and the posts here all
              > boil down to one single question that you consistently fail
              > to answer every time and call me names instead. i think
              > actually a lot of people are interested in this:
              >
              > what was the technical reason you started working on smtpd(8)?

              The thing about releasing software under the BSD license is that everyone can use the software according to this license.
              One of the things the BSD license does not give you the rights to, is an answer to questions you or anyone pose. You can use the software as you like submit code and so on. When or why he publishes the software or anything related to this software is just none of your business.

              >
              > and no, license and free time and security announcements
              > (that come once in a blue moon about E.G. postfix) are not
              > technical reasons.
              >
              > yet i am repeatedly called a troll because i am interested
              > in your motivation. your article failed to answer exactly
              > what was the itch you tried to scratch---the most basic
              > question of all. am i asking too much?

              I want you to answer why you post this question!!!
              And you cant say that you are interested in this or that you want to hear his motivation.
              You are demanding that he does have a technical motivation?!? why do you demand that?
              Given that it is not your birthright or a contractual obligation that he answers, he doesn't "fail" to answer them, he just doesn't answer.

          2. By Anonymous Coward (68.162.84.17) on

            > No, I don't realize how silly my arguments are.

            I'd just like to say thanks for your work on this project and your willingness to respond to all of the comments here at Undeadly. I know it takes away from your time to do other things.

            Best wishes.

            1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

              > > No, I don't realize how silly my arguments are.
              >
              > I'd just like to say thanks for your work on this project and your willingness to respond to all of the comments here at Undeadly. I know it takes away from your time to do other things.
              >

              Hehe, I'm answering during my coffee breaks ;-)

              Gilles

              1. By Miod Vallat (miod) on

                > Hehe, I'm answering during my coffee breaks ;-)

                But this causes you to drink more coffee, which might not be considered a good thing (because, you know, it means there will be less coffee for me).

                1. By Strog (64.207.240.34) on

                  > > Hehe, I'm answering during my coffee breaks ;-)
                  >
                  > But this causes you to drink more coffee, which might not be considered a good thing (because, you know, it means there will be less coffee for me).
                  >

                  More coffee consumed means fresher coffee because it doesn't sit around. Sounds like a good thing to me. ;-)

        3. By djm (forgetting his password) (65.57.245.11) on

          > i hope you do realise how silly your install/clone/configuration
          > arguments look like.

          What arguments? He wrote a whole two sentences about Postfix and didn't criticise it at all, despite your repeated attempts to goad him.

          Quixote, meet windmill.

          1. By minusf (195.168.92.92) on


            > What arguments? He wrote a whole two sentences about Postfix and didn't
            > criticise it at all, despite your repeated attempts to goad him.

            i was talking about his answer.
            http://undeadly.org/cgi?action=article&sid=20081112084647&pid=30&mode=expanded

            1. By djm (still without his password) (218.45.193.1) on

              > > What arguments? He wrote a whole two sentences about Postfix
              > > and didn't criticise it at all, despite your repeated attempts
              > > to goad him.
              >
              > i was talking about his answer.
              > http://undeadly.org/cgi?action=article&sid=20081112084647&pid=30&mode=expanded

              Still no criticism of postfix there, just a patient explanation of why his simple needs made the in-tree sendmail a better solution for him at the time.

              Are you just angry at the world?

    3. By Anonymous Coward (66.130.232.120) on

      lameass

  11. By Anonymous Coward (96.21.15.58) on

    This is ultra-awesome! Will this be production ready by 4.5?

    1. By Anonymous Coward (74.13.31.109) on

      > This is ultra-awesome! Will this be production ready by 4.5?

      Depends, doesn't it? You up for testing, troubleshooting, patching, maybe sponsoring? It likely isn't out of the question to have the tool ready for most uses by 4.5, but that would require people get gilles@'s back.

      Do you have his back?

      1. By Owain G. Ainsworth (oga) oga@openbsd.org on

        > > This is ultra-awesome! Will this be production ready by 4.5?
        >
        > Depends, doesn't it? You up for testing, troubleshooting, patching, maybe sponsoring? It likely isn't out of the question to have the tool ready for most uses by 4.5, but that would require people get gilles@'s back.
        >
        > Do you have his back?

        In a jar on my desk, yes. It takes up rather a lot of space; I've been wondering whether to keep it.

        1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

          > > > This is ultra-awesome! Will this be production ready by 4.5?
          > >
          > > Depends, doesn't it? You up for testing, troubleshooting, patching, maybe sponsoring? It likely isn't out of the question to have the tool ready for most uses by 4.5, but that would require people get gilles@'s back.
          > >
          > > Do you have his back?
          >
          > In a jar on my desk, yes. It takes up rather a lot of space; I've been wondering whether to keep it.
          >

          Don't throw it away please, I still need it ;)

      2. By Anonymous Coward (67.69.227.99) on

        > > This is ultra-awesome! Will this be production ready by 4.5?
        >
        > Depends, doesn't it? You up for testing, troubleshooting, patching, maybe sponsoring? It likely isn't out of the question to have the tool ready for most uses by 4.5, but that would require people get gilles@'s back.
        >
        > Do you have his back?

        I am, are you?

        1. By Anonymous Coward (74.13.31.109) on

          Of course I am have his back! Silly you asked such the question.

          1. By Miod Vallat (miod) on

            > Of course I am have his back! Silly you asked such the question.

            All your backs are belong to us.

  12. By father (118.173.155.190) on

    soo pumped. this is rad news. minusf, you are an argumentative d-bag.

    keep up the awesome work gilles

    peace from thailand!

    1. By Anonymous Coward (94.71.121.84) on

      > soo pumped. this is rad news. minusf, you are an argumentative d-bag.
      >
      > keep up the awesome work gilles
      >
      > peace from thailand!

      do you surf?

  13. By Wouter (2001:888:1b6b:b0e::6965:6b73) on

    Gilles, ignore the trolls please, I think it's awesome what you're making. The day I can finally have a decent SMTP daemon in the default install will be a very happy day for me.

    Also, can I use this to make a small feature request? I've gotten rather used to postfix' plus-hack. You know, the one where mail to user+foo@example.com gets delivered to 'user', with 'foo' as extra information to be optionally supplied to, say, procmail. If opensmtpd would support that out of the box that would be great.

    Thanks for the good work!

    1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

      > Gilles, ignore the trolls please, I think it's awesome what you're making. The day I can finally have a decent SMTP daemon in the default install will be a very happy day for me.
      >
      > Also, can I use this to make a small feature request? I've gotten rather used to postfix' plus-hack. You know, the one where mail to user+foo@example.com gets delivered to 'user', with 'foo' as extra information to be optionally supplied to, say, procmail. If opensmtpd would support that out of the box that would be great.
      >
      > Thanks for the good work!
      >
      >

      Hi,

      The "+ hack" is already supported, however Qmail-style "- hack" is not (and will not be) supported as OpenBSD usernames may contain them.

      Gilles

      1. By ckm (214.3.17.38) on


        > The "+ hack" is already supported, however Qmail-style "- hack" is not (and will not be) supported as OpenBSD usernames may contain them.
        >
        > Gilles

        Your reasoning makes sense. Would it be too much trouble to allow the seperation character (or characters) to be defined in a configuration file?

        Thanks.

        1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

          >
          > > The "+ hack" is already supported, however Qmail-style "- hack" is not (and will not be) supported as OpenBSD usernames may contain them.
          > >
          > > Gilles
          >
          > Your reasoning makes sense. Would it be too much trouble to allow the seperation character (or characters) to be defined in a configuration file?
          >
          > Thanks.

          This is trickier than it looks, say the config file allows "-", then what if a mail comes with recipient "foo-bar@bleh.org" while the system has a foo and a foo-bar user ? who gets it ? This will need extra code and I don't really understand in which case one has to use "-" rather than "+".

          Gilles

          1. By ckm (214.3.17.37) on

            > This is trickier than it looks, say the config file allows "-", then what if a mail comes with recipient "foo-bar@bleh.org" while the system has a foo and a foo-bar user ? who gets it ? This will need extra code and I don't really understand in which case one has to use "-" rather than "+".
            >
            > Gilles

            I'd say the sys admin can make the call whether to allow user names to have a "-" or not and whether to use a "-" or a "+" within email addresses. A config file would just allow her to have an option.

            Several years ago (so my memory is a bit dim on the specifics), I was using Sun's smtp server product, which defaulted to the "+" separator. I was testing out the functionality and some companies' email systems would not accept email addresses containing a "+", even though it is a valid character. But they would accept a "-". So the use case would be for compatibility with other smtp servers. Unfortunately, I don't have specifics to offer up, but I hope that in the intervening years things have gotten better.

            Anyway, I fully respect the work you're doing on smtpd within OpenBSD and as the developer, you have the final say on what gets implemented. Thanks for the responses and I look forward to putting it to work.

            1. By Anonymous Coward (2a01:348:108:100:20e:cff:fe2e:c35a) on

              > I was testing out the functionality and some companies' email
              > systems would not accept email addresses containing a "+", even
              > though it is a valid character. But they would accept a "-". So the
              > use case would be for compatibility with other smtp servers.
              > Unfortunately, I don't have specifics to offer up, but I hope that
              > in the intervening years things have gotten better.

              It's very common for websites to disallow email addresses containing a +, and this feature is ideally suited to creating throwaway addresses you can use to register on websites (so you can work out who sold your address, lart the site admins and block the address).

    2. By Sebastian (Sebastian) on

      I'd like to second that: Gilles please leave bashing the trolls to those of us that don't have the required knowledge to assist you codewise (namely me) and spend your precious (free) time on continuing the work you started on smtpd.

      On the point of sendmail configuration files: I feel your pain. I recently (as in last week) started tinkering with OpenBSD + Sendmail + DBMail and due to my inexperience with sendmail configuration files and a bit spotty documentation on de DBMail website I lost a few hours trying to get it all to (not) work. I then left it lying only to pick it up a few hours later and, to my surprise, make it work in about half an hour.

      *I* (emphasis mine, feel free to disagree) am of the opinion that the sendmail configuration syntax is fairly close to being moronic for its intended purpose, though not unlearnable.

      As I said I'm not able to help you codewise (yet), but I am going to look into compiling smtpd and tinkering with it to see how it works and I'll try to provide feedback.

      On a feature request/side note (DBMail related), is something like the following already possible/planned for smtpd?

      accept domain "foo.org" hand of to "/usr/local/sbin/dbmail-smtp"

      I would be happy to donate for said functionality and for work on smtpd in general to you, the OpenBSD project in general, or via you to the project in general (no strings attached).

      P.S.: This news about smtpd has got me so excited I just had to register. :-)

      1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

        > On a feature request/side note (DBMail related), is something like the following already possible/planned for smtpd?
        >
        > accept domain "foo.org" hand of to "/usr/local/sbin/dbmail-smtp"
        >

        you mean something like the following ?

        accept for domain "foo.org" deliver to mda "/usr/local/sbin/dbmail-smtp"

        Cause this is already implemented ;-)
        It needs more work though to protect the smtpd from being locked if the external MDA stops reading.


        > I would be happy to donate for said functionality and for work on smtpd in general to you, the OpenBSD project in general, or via you to the project in general (no strings attached).
        >

        Well, I have a wishlist at amazon in case you want to make me personally happy, and/or you can make a donation to the OpenBSD project which is always appreciated ;-)

        Gilles

        1. By Sebastian (Sebastian) on

          > > I would be happy to donate for said functionality and for work on smtpd in general to you, the OpenBSD project in general, or via you to the project in general (no strings attached).
          > >
          >
          > Well, I have a wishlist at amazon in case you want to make me personally happy, and/or you can make a donation to the OpenBSD project which is always appreciated ;-)
          >
          > Gilles

          I chose both options. Expect delivery in 8-16 days. I turned the rest into a donation. :-)

  14. By Chas (147.154.235.52) on

    Is there any intention to create a portable release for other architectures, a la ssh, cvs, ntpd, et al?

    1. By Anathae (96.52.186.131) on

      > Is there any intention to create a portable release for other architectures, a la ssh, cvs, ntpd, et al?

      re: openssh, if the kind of people behind the port are available for opensmtpd, i'm sure it will happen

      1. By Anonymous Coward (96.21.15.58) on

        > > Is there any intention to create a portable release for other architectures, a la ssh, cvs, ntpd, et al?
        >
        > re: openssh, if the kind of people behind the port are available for opensmtpd, i'm sure it will happen

        Is it/will it be opensmtp[d] or is that something people are wanting to call it?

    2. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

      > Is there any intention to create a portable release for other architectures, a la ssh, cvs, ntpd, et al?

      work in progress by chl@ ;-)

  15. By James (jturner) james@bsdgroup.org on http://bsdgroup.org

    Quick question about syntax. I've been playing with smtpd and working on getting it to accept mail for bsdgroup.org and rely mail from localhost.

    --

    listen on 0.0.0.0 port 25
    hostname console.bsdgroup.org

    local = "( 127.0.0.1, ::1 )"

    accept from 0.0.0.0 for domain "bsdgroup.org" deliver to mbox "/var/mail/%u"
    accept from $local for all relay

    --

    My question is with the "accept from 0.0.0.0" line, when I left out the "from 0.0.0.0" it would accept mail for bsdgroup.org only from localhost, I also tried "accept from any for domain" ... which didn't throw a syntax error but again didn't seem to accept mail. If one wants to accept mail for a domain from anyone is "accept from 0.0.0.0" the correct/only way to do it?

    With that, I've been really enjoying exploring smptd. Thanks for all your work!

    1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

      > Quick question about syntax. I've been playing with smtpd and working on getting it to accept mail for bsdgroup.org and rely mail from localhost.
      >

      As long as you are aware its not production ready ... ;-)


      > listen on 0.0.0.0 port 25
      > hostname console.bsdgroup.org
      >
      > local = "( 127.0.0.1, ::1 )"
      >
      > accept from 0.0.0.0 for domain "bsdgroup.org" deliver to mbox "/var/mail/%u"
      > accept from $local for all relay
      >
      > --
      >
      > My question is with the "accept from 0.0.0.0" line, when I left out the "from 0.0.0.0" it would accept mail for bsdgroup.org only from localhost, I also tried "accept from any for domain" ... which didn't throw a syntax error but again didn't seem to accept mail. If one wants to accept mail for a domain from anyone is "accept from 0.0.0.0" the correct/only way to do it?
      >

      Yeah, basically not specifying "from" default to an implicit "from { 127.0.0.1, ::1 }" as a mean to provide a safe default and a shortcut for local host rules. Your second accept rule can therefore also be written as:

      accept for all relay

      I think I will add a shortcut such as "from any" or "from all" to expand to empty ipv4 and ipv6 masks so that you can later write your first accept rule as:

      accept from any for domain "bsdgroup.org" deliver to mbox "/var/mail/%u"

      Gilles

  16. By Mayuresh Kathe (59.182.230.200) kathe.mayuresh@gmail.com on http://kathe.in/

    Gilles, you've been attacked on Undeadly by morons/ignoramuses.

    Please ignore them and do continue your good work.

    I personally believe that having software pieces which take advantage of OpenBSDisms is good.
    In OpenBSD, we have a good OS, why not also have good applications.

    Wish you "all the best". :-)

  17. By Peter (62.75.160.180) on http://solarscale.de

    Actually this is good. We need more smtpd's if anyone else has the time write your own as well. When developers reach a point where they say "we need feature X from smtpd A and feature Y from smtpd B " and stick it together in yet another smtpd that's a good time because there is working examples. You don't need a technical reason to create diversity and perhaps a few good hooks come out of it all.

  18. By fernandotcl (201.81.193.91) on

    Impressive, this post is by far much more popular than, for example, the OpenBSD 4.4 release announcement.

    Goes to show how frustrated people are with the available solutions. I think this is a epic win. OpenBSD-quality software is always welcome, and the world needs simpler, better-designed software.

    I really appreciate your work, gilles.

  19. By Anonymous Coward (80.56.213.224) on

    Hi Gilles,

    keep on the good work! I'm impressed with the solutions OpenBSD always comes with and if one time we can see this in base OpenBSD (replacing sendmail), It would really kick ass.

    How could we donate?

    Thanks
    (a FreeBSD user, who is eying OpenBSD for his server needs)

    1. By Gilles CHEHADE (gilles) on http://www.poolp.org/~gilles/

      > Hi Gilles,
      >
      > keep on the good work! I'm impressed with the solutions OpenBSD always comes with and if one time we can see this in base OpenBSD (replacing sendmail), It would really kick ass.
      >
      > How could we donate?
      >
      > Thanks
      > (a FreeBSD user, who is eying OpenBSD for his server needs)

      Hi,

      chl@ is working on portable OpenSMTPD so you will see it running on FreeBSD at some point ;-)

      If you want to make a donation, you can do so through paypal@openbsd.org

      Thanks !

  20. By Anonymous Coward (142.104.60.167) on

    I'm really happy to hear this, Good luck in your endeavors!

  21. By kiriakos simon (94.71.121.84) on

    short, simple & straightforward implementation + configuration for smtp also ..

    the developer himself discussing so openly with openbsd users .. accepting suggestions.. even considering imaginary configuration file examples.

    OpenBSD is like a family, that's why we love it.

    - kiriakos

  22. By Frank Sullivan (fsullivan1948) fsullivan1948@yahoo.com on

    I'll say what everyone is probably thinking: Please, for the love of all that's holy, let's try to build a user community that is a bit more pleasant than Wietse, Victor, and their band of "me-too" cronies. I'd say the bar is quite low in that regard... If every request for help was immediately replied to with "I hate you", it would STILL be more pleasant than the "postfix-users" mailing list.

    -Frank

  23. By Alexander (sasha) sashabsd@rur.dyndns.biz on

    It's my first post, I am very bad speak English :(
    In my opinion OpenSMTPD one of best SMTP daemon's available on this day. Very very simple configure, ultra security, fast work! Thank's a lot for all developers! We do OpenBSD the best of best operating system! I love OpenBSD!

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]