in reply to SMTP Server - which module

I have used neither and I would really look towards exim4 or one of the other mail frontends to do all the queueing etc., especially if this is going to be a hurried replacement.

Later on, you can still implement forwarding rules to a (local) different mailserver written in Perl.

I'd look at qpsmtpd (old, but likely still usable), and AnyEvent::SMTP, but both parse the complete mail before handing it off to you.

Alternatively, as long as you can assume that all incoming mail will be well-behaved, maybe just faking the SMTP protocol from a plain socket is Just Enough - but I'd still look towards a proven mail server first and gradually replace it by forwarding selected mails to other servers.

Replies are listed 'Best First'.
Re^2: SMTP Server - which module
by cavac (Prior) on Dec 13, 2011 at 10:33 UTC

    Yeah, i can pretty much assume the mail senders are well behaved. Except that i have to make sure the mailserver is in a catch-all configuration (doesn't care about sender and reciever beeing "known" to it).

    Also, the volume is pretty small, on the order of 100-300 mails per day.

    Later on, you can still implement...

    No i can't. From experience i just know that in my company any temporary setup that actually works stays the temporary setup until it just has to be replaced. That's how i inherited the old mail server in the first place. So i want to get it more or less right from the beginning (minor and major bugfixes on the other hand are much easier to implement).

    The problem is that my production plant pretty much runs 24/7. So unless something actually breaks, it's hard to get a time window to replace it. The old hardware is actually breaking (finally!) and i got an additional time window from 27.12 to 30.12. That opportunity wont come again any time soon...

    BREW /very/strong/coffee HTTP/1.1
    Host: goodmorning.example.com
    
    418 I'm a teapot

      If it is only a small volume, I would especially stay with a proven and implemented solution for the MTA instead of rolling my own in a week or two. If your clients are well-behaved, they might queue the status mails themselves and retry after some time so you get a chance to fix your code.

      Consider that you can set up the MTA to forward all mail to a Perl script anyway through a .forward file. I would avoid the risk of introducing an unproven component. The mailserver handles queueing and the complete protocol for you - why put that hassle on yourself if the usage is only 300 mails per day?

        Your argumentation was flawless.

        But i have to bow my head in shame because i have a confession to make: After all this good advice about using a proven product, ... i uh still went ahead and wrote my own MTA. (Ok, what do you expect of some guy who wrote his own webserver just because he didn't like to configure Apache?)

        So far, i works quite nicely and it turns out we have more like 3000-5000 Mails per Day, except that the old mailserver i replaced just "lost" most of them.

        While i'm rather pleased with the result (so far, anyway), i still feel a little guilty about asking the question and then ignore all the advice i got.

        I'd like to hereby thank you for the advice, because i did take a look at various MTA's and saw what features i liked or didn't like. You could say i was inspired by the effort.

        BREW /very/strong/coffee HTTP/1.1
        Host: goodmorning.example.com
        
        418 I'm a teapot