I'm glad to see that someone is actively maintaining ssmtp. In the mean time, I'm still using the version which I patched up and posted to the list some time ago. I might eventually have a look at the new sources and send some suggestions, though I'm not sure I want to deal with all the OpenSSL stuff that's been added in.
Anyway, I thought it might be worth posting because I've added Delivery Status Notification (DSN) support to my little pet version of ssmtp. ESMTP MTA's which support DSN will, on request, send you an email to confirm that your message has been delivered to the addressee's mailbox. I've seen email dissappear into a "black hole" without generating any sort of "bounce" message often enough that I now want this added reassurance on important email. Lots of ISP's have MTA's installed that support it, but the feature is, I think, little known on the 'net because most MUA's don't (Netscape's mailer is one of the few that's supposed to, but I've never been able to get it to work). One of the RFC's mentions including a 'Return-Receipt-To:' header in your message to invoke DSN, but most MTA's don't scan for it (IIRC, qmail is reported to do it). The only sure way to get DSN is to add the extra parameters to the "MAIL FROM:" and "RCPT TO:" commands when message transmission is being negotiated, that are described in RFC1891. To invoke DSN in my ssmtp version, include a 'Return-Receipt-To: <your addy>' header to your outgoing email in those messages where you want the service. If your mail hub supports DSN, ssmtp will tell you that it detected the request by printing "Return Receipt Requested" to stderr; if your hub doesn't support it, ssmtp will print a warning and continue to deliver the message. As an added sidelight, some MUA's respond to the presence of a 'Disposition-Notification-To:' header in incoming email by sending a message when your email is opened, but most of them prompt the user first before sending it. To the current ssmtp maintainer: please feel free to pluck any and all enhancements from the attached sources and add them to your version. I might eventually get around to doing it myself, but no promises. In the mean time, if anyone wants to try out my ssmtp, just unpack the attached sources in a directory and run 'make.' In addition to those bug fixes and enhancements previously mentioned (and repeated below), I added my own fix to the 'To: ' header problem, and 'Bcc: ' headers (including multi-line ones) are properly removed before the message is forwarded to the mail hub. Enjoy. :) Jeff -------------- If your mail server requires authenticatiion (like mine), you can now put your userid and password in the config file. Of course, I'm sure that no one wants such info in the clear in a text file, so I wrote a little utility to encode it, and incorporated that utility into the config file generator script. You can still put your userid and password on the command line, if you wish. Added a bit of code to explicitly handle <CRLF> line terminators in the input stream, as per an earlier thread. Shouldn't matter now what mount strategy you're using, how your MUA hands off an outgoing message to SSMTP, etc. Implemented dynamic memory allocation for the headers and recipient list buffers. These can now be any size up to available memory. Swatted a few bugs (eg. a malloc() without a free()), merged and simplified a few functions, reorganized the code so you can read it and actually figure out what's going on, and pretty much brought everything up to ANSI C.
ssmtp-2.38.7-4-patched-src.tar.bz2
Description: Binary data
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/