Re: How to send a return receipt
=- Derek Martin wrote on Sun 21.Oct'07 at 20:55:07 -0400 -=
> {...} with its major goal being to suck less than the other mail
> clients. It says the latter explicitly on its home page. Inasmuch
> as it does not implement standard features offered by other
> clients, it is a failure in that goal.
Uhm ... not all that is widely supported is good.
> PLEASE NOTE: a power user of e-mail is not necessarily a power
> user of *anything else*.
Aye, agree, but then ... mutt is not for the faint of heart
either. :)
If a not hardcoded solution is offered ready to "source", let them
have it.
> > ... as stated elsewhere: adding up has more of an effect than
> > just the sum of its parts.
>
> This is not a reason not to do something.
Right, that's why I gave solutions.
> > And this total effect can be bad despite all the partial good
> > effects.
>
> This also is not a reason not to do something... It is, however, a
> good reason not to do something badly. Integrating support for
> this feature into Mutt is, from the user's standpoint,
> unquestionably the better way than relying on hacks which are not
> well-implemented or poorly integrated into Mutt.
Remeber the "mh" solution?
Actually, if mutt were a complete CORBA constructable tool, I'd be
happy with it letting everybody construct it's components as
desired, all "hardcoded" if you prefer.
That is, if CORBA were anywhere practicable or in wide use.
> That's not the point at all. The point is that the feature being
> missing in Mutt is forcing some people who use Mutt in business,
> and want to continue to do so, to move to something else, because
> the features they NEED -- features supported by virtually every
> other mailer in the known universe -- are missing from Mutt.
Ok, they _are_ missing, until somebody implements my (and other
mutters') suggestions.
> Some of those users might be willing and able to implement the
> needed functionality themselves... But you would (obviously) be
> surprised by the number of people who use Mutt who can not or
> don't want to.
Can not: why? Once the solution is published, simply "source".
Want not: tough luck for them, no loss when they switch.
> They exist so that the receiver can say, "I know you saw my
> e-mail, I have the return receipt." It's about accountability...
> it's the same reason the post office offers registered/certified
> mail. Mail (both kinds) is inherently unreliable -- you send off
> your e-mail, and you have no way to know if the recipient actually
> received it... unless they're using some return receipt feature.
> Then, the recipient can not say, "hey, I never received your
> mail." The sender has proof that he did.
... if this were about legal cases, easy forging such
return-receipts makes it vulnerable, you'd need more for that.
But then DSN and server logfiles do the same service.
> MUTT DOES NOT HAVE RETURN RECEIPT SUPPORT. Mutt has support for
> letting the user customize and extend mutt in a variety of ways. This
> is very much NOT the same thing as having return receipt support.
Has mutt complete ssl and curses support? Is relying on external
binary libs any better than relying on external unix tools?
> It means it's already there, waiting for the user to use it. If it
> requires the user to code logic (as opposed to simply turning on
> settings), then it is not supported.
source path-to/contrib/rr.mutt
done
That's how it works with pgp, too.
> On an individual (per-solution) basis, it needs roughly as much
> maintenance as it would need if it were implemented in Mutt directly;
Right, so this no reason to switch to hardcode.
> But, your method will not require just 2 or 3 developers to
> maintain it... instead it will require hundreds or perhaps
> thousands of users to maintain it individually.
Uh, when you have to upgrade the mutt binary for RR, this isn't
anything less of a burden than to adjust a little source'ed script
included in /contrib.
> This discussion is not about those features. It's about return
> receipts. Decisions about whether to add a feature can only
> logically be made on a case-by-case basis.
> Discussions about drawing lines are pointless and fruitless. From
> the standpoint of the user, none of your arguments against
> allowing this feature to be added to mutt are compelling.
By this line all other features should be included, too.
Definitely a no-go.
Once you look at every individual case isolatedly, mutt will
eventually become a cross-breed clone of all the other bulky
software out there: Lotus, OL, TB, Pine all in one.
> You haven't come up with a single technical or logical reason
> besides this why Mutt shouldn't have this feature.
You've nailed it: there is more to coding than just code.
> It appears that the only valid concern you have is that you simply
> don't like the feature. But this is not a defensible reason for
> denying the feature from the portion of the user community who
> NEED it.
I don't like it: true.
I deny it for those needing: false.
I deny it being hardcoded: true.
> > Just because stuff hasn't anything to do with _your_ definition
> > (or mine) of what belongs to a mail client, this doesn't mean
> > others want to have it included nevertheless, because it makes
> > their lives _much more_ convenient when it's all done out of
> > _one_ box for them.
>
> Exactly the reason to implement features. The only reasons against
> implementing features which have been brought to bear in this
> thread are largely emotional, dogmatic, Chicken Little BS that
> don't hold true in the modern computing world.
Hum, switch to OL or TB then. Ah wait ... you need a TUI rather than
a GUI. How about starting a TUI project for TB?
If it is so well coded and modular as rumors say, shouldn't be too
hard.
> Many people (myself included) have been interested in writing code
> to improve Mutt, but have not done so precisely because the
> developers are against implementing any new features of any
> substance (and often even smaller features that require little
> code or maintenance). Rado, you yourself have fallen into this
> category in the past.
I know, and it was a hard lesson, but at the same time it's
different from the "usual" candidates in that it doesn't change
functionality (features, codewise or interface handling).
This means, despite the delay (yah, there is still hope! :) with my
"pet project", overall I'm happy with what is possible with mutt now
(even was before SMTP ;), so that's why I don't see the need to put
more code when it works elsewise.
> The only thing that gets in these days are small featurelets,
> unless it happens to be something that one of the main committers
> particularly cares about.
> Why is it that virtually all of the major distributions include
> patches to Mutt that have not been integrated?
Beyond policy/ philosophy decisions there is even more the time
factor, I guess.
> I believe Mutt would have a much bigger development community if the
> the current maintainers were to foster discussion about how to design
> features so that it *can* be integrated into mutt properly, rather
> than automatically arguing against new features.
Michael has started the "plug-ins" project, maybe it will solve all
your/ our technical/ feature problems/ requests when it works.
(but it won't solve mine, a pity *sob* )
> The addition of SMTP support has, in my mind, proven that the
> nay-sayers are just like Chicken Little.
... or true to an ideal not fully compatible with all kinds of or
total convenience.
> > I don't see why a soft-coded solution is less reliable, lesser
> > than any of the other soft-coded (external) solutions.
>
> It's less robust. It's less well-tested. It's less
> well-maintained.
Your answers base on what???
--
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.