Yours is the top voted comment at the moment, so dumb or not, it seems a common question.
Looking just at the two examples on the main page, it's an implementation of the SMTP protocol so you can either send mail directly to recipients' servers, or run a mail server.
Sending mail directly is often useful when you need to deliver a message to a lot of recipients. IIRC, this doesn't always work, because many servers reject messages unless they can reverse resolve the ip to the sender's domain.
A server for receiving messages is basic infrastructure. The reason for using a simple solution with clear source code, instead of established daemons, like postfix, is that you can tune it to implement filters or notifications.
As an example: some time ago I had the idea of putting a bayesian spam filter directly in the server code, eliminating the problem of false positives: the mail is either accepted or rejected, in which case the sender gets to know that the message has not arrived its recipient, instead of silently trashing it as spam.
The problem with rejecting mail as spam explicitly rather than silently dropping it into the spam bin is that it makes it really easy to tune spam so that it gets past your filter. Maybe it doesn't matter so much if it's just for a few people, but if something like that was popular there would be people figuring out how to work around it.
If this were even a tiny bit of an issue then way more spam would hit people's inboxes. Rejecting explicitly is the right thing to do. It's not always possible, but it's definitely preferred.
Source: I wrote some of the original SpamAssassin and worked in anti-spam for over 10 years.
Looking just at the two examples on the main page, it's an implementation of the SMTP protocol so you can either send mail directly to recipients' servers, or run a mail server.
Sending mail directly is often useful when you need to deliver a message to a lot of recipients. IIRC, this doesn't always work, because many servers reject messages unless they can reverse resolve the ip to the sender's domain.
A server for receiving messages is basic infrastructure. The reason for using a simple solution with clear source code, instead of established daemons, like postfix, is that you can tune it to implement filters or notifications.
As an example: some time ago I had the idea of putting a bayesian spam filter directly in the server code, eliminating the problem of false positives: the mail is either accepted or rejected, in which case the sender gets to know that the message has not arrived its recipient, instead of silently trashing it as spam.