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