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.

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?

All modern mail servers allow some configuration to handle incoming mails to other processes, for purposes like spam filtering.

So you could hijack that mechanism to write a custom "spam filter" that enters all the incoming emails into a database, and mark the all as spam, so that the mail server doesn't deliver them (unless you actually do want them delivered).

I don't have any first hand experience with it, but I'd expect the battle proven mail servers to be more robust than the SMTP server modules you'll find on CPAN. (Of course that might do them great injustice, but I know that exim works well in the real world).

I'd go with Postfix (non-Perl). Postfix (and most other decent SMTP servers I'm sure) can be easily configured to pipe incoming messages to a script. That can be your Perl.