Hello, > However, any smtp implementation would still need to talk to rbl's, > spamassassin or other spam plugin and anti-virus. There should also be ways > to block incoming (such as the sendmail access file). Of course sendmail's > access file has its limitations. You would think that with paid programmers > working on it, that it could read 192.168.0/26 and expand that as its > reading the hash table into memory. I digress.
I think these are features Eelco was referring to when he said, "This will not be a full smtp server implementation (no relaying and stuff like that) but pureley an smtp reception daemon." Most people, with needs like yours, will likely not use it, but the lmtp daemon or message injector. The planned stripped-down, high-speed smtp daemon would be more suited for on an internal server, not Internet visible, that is fed from multiple other smtp servers running full-blown mta software (eg. postfix and the others you mentioned). As Eelco said, they both have their own place, with distinct advantages and disadvantages. Like you said, there's no point in re-inventing the wheel, and I don't think that's what is planned. Jesse -- Jesse Norell jesse (at) kci.net
