[[!tag wishlist plugins/passwordauth]] For sending out password reminder emails, the [[plugins/passwordauth]] plugin currently uses the *[Mail::Sendmail](http://search.cpan.org/perldoc?Mail::Sendmail)* module. This module, however, has the limitation that it can only talk *SMPT*, but can't use the standard Unix *sendmail* (command-line) interface. I don't want to have an MTA with a SMTPd running on my web server system. Would it be possible to switch to using one of the existing Perl modules that support the *sendmail* interface? From doing a quick search, these might be some candidates: * * * * None of them are packaged for Debian so far, but that should be doable easily, as far as I know. ikiwiki might perhaps even try to use all of them in turn until it finds a working one. I'd offer to work on a patch for the [[plugins/passwordauth]] plugin and other places in the ikiwiki source code, where emailing is done. --[[tschwinge]] > One that is in Debian is [[!cpan Email::Send]], which can do SMTP and > sendmail and some other methods and falls back through methods until one > succeeds. I haven't tried to use it but it looks like a feasable > candidate. > > I don't much like the idea of supporting a lot of different email sending > modules. --[[Joey]] OK, so I'll have a look at replacing all email handling with *Email::Send*. [[!tag patch]] ** Remaining TODOs: * Resolve TODOs as denoted inside the patch. * Is it worthwhile to use and depend on [[!cpan Return::Value]] just for this bit of functionality? * Debian news file. * ikiwiki news file. --[[tschwinge]] > BTW, I think you recently sent a patch improving mail logging, but I've > lost it. --[[Joey]] Resent. --[[tschwinge]] > Debian now has Mail::Sender, Mail::SendEasy, and Email::Sender > (which, according to its dpkg description, "replaces the old and sometimes > problematic Email::Send library, which did a decent job at handling very > simple email sending tasks, but was not suitable for serious use, for a > variety of reasons"). Are any of those any better? It's unfortunate that > there doesn't seem to be a clear "best practice"... --[[smcv]]