Subject: ssmtp 2.38 revisited - DSN
From: Jeff <[email-masked]>
To: [email-masked]
Date: Tue, 13 Apr 2004 14:28:27 -0700

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.

--
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/