Skip Menu |
 

This queue is for tickets about the Jifty CPAN distribution.

Report information
The Basics
Id: 70876
Status: new
Priority: 0/
Queue: Jifty

People
Owner: Nobody in particular
Requestors: fschlich [...] zedat.fu-berlin.de
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: please use Email::Sender instead of Email::Send ("out of favour")
Download (untitled) / with headers
text/plain 1.3k
Since several years, Email::Send carries a big fat warning: ------------ WAIT! ACHTUNG! Email::Send is going away... well, not really going away, but it's being officially marked "out of favor." It has API design problems that make it hard to usefully extend and rather than try to deprecate features and slowly ease in a new interface, we've released Email::Sender which fixes these problems and others. ------------ and in a review (http://cpanratings.perl.org/dist/Email-Send), the maintainer states: ------------ Email::Send is reasonable for sending off a message if your needs are very, very simple. It has numerous issues, though, and should be avoided in favor of its replacement, Email::Sender. Examples: * you can't specify envelope (smtp/sendmail) sender/rcpts distinct from message header * the return values are bizarre and confusing (Return::Value) * SMTP will always send even if some recipients are refused * "message modifiers" are called cumulatively instead of on message clones * transports generally have no state and cannot be persistent * the default behavior is to try every mailer available, including the Test mailer, potentially losing mail Many of these problems can't be fixed without significant problems or backwards incompatibility. Please consider using Email::Sender (and Email::Sender::Simple) instead. -----------


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.