Subject: [sup-talk] [RFC] Bounce messages

From: [email-masked] (Ben Walton)
Date: Sun, 31 May 2009 20:54:08 -0400

Hi All,

I spent a few hours this evening putting together the basics of (I
think) the last feature of mutt that I miss in sup: Message bouncing.

It works in it's current form, but I think it needs a little further
tweaking before it is merge ready.

Currently it's pretty dumb wrt which sendmail command it calls.  It
simply calls sendmail with some sane (for my environment, anyway) args
and a list of recipients (skipping the -t flag which makes it read
recipients from headers in the input).  I didn't want to implement a
second mail variable per account, although that would solve the
problem, and I didn't want to use the default sendmail command with
the -t stripped from the args (although that would also work).

The other thing that I don't like presently is the confirmation UI.
Without resorting to a whole bounce-mode, is there a better way to
handle this in the face of (potentially) multiple recipients that may
make the question stretch outside the viewable area?

I'm interested in what others think is the right solution to these
problems...and whether others besides myself miss this feature of
mutt.

Thanks
-Ben

---

From: [email-masked] (William Morgan)
Date: Fri, 05 Jun 2009 09:02:17 -0700

Hi Ben,

I'm definitely interested in having this feature. But it does open up
some complications because we have to be able to call the MTA in two
different modes.

But this might not be such a big deal because most MTAs have basic
sendmail compatibility. Judging from the entries on the Sup Wiki for
msmtp, ssmtp, and putmail, we should be fine just calling the account's
sendmail command without -t and with the recipient email addresses.

> make the question stretch outside the viewable area?

You could just make it say "Bounce to #{to.size} recipients?". :)
-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Ben Walton)
Date: Fri, 05 Jun 2009 12:20:32 -0400

> I'm definitely interested in having this feature. But it does open

Great.

> some complications because we have to be able to call the MTA in two

Nothing is free! :)

> sendmail command without -t and with the recipient email addresses.

Ok, I'll rework the patch to call the default account's sendmail
command with any -t stripped out.

> You could just make it say "Bounce to #{to.size} recipients?". :)

That would work.  Still gives a chance to back out if things don't
look right but not too heavy either.

I'll rework this tonight.  I looked at refactoring against the
EditMessageMode send function the other night and that's not straight
forward since the shared code is a few classes up the object tree.
Moving the send message code higher in the tree isn't ideal, as it
doesn't really belong there...suggestions on that?

Thanks
-Ben
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090605/17101870/attachment.bin>

---

From: [email-masked] (Nicolas Pouillard)
Date: Sat, 06 Jun 2009 12:16:55 +0200

> some complications because we have to be able to call the MTA in two

I don't get the purpose of this, how it is different from hitting 'D' to send
again the same message?

-- 
Nicolas Pouillard
http://nicolaspouillard.fr

---

From: [email-masked] (Ben Walton)
Date: Sat, 06 Jun 2009 08:44:15 -0400

> I don't get the purpose of this, how it is different from hitting 'D' to send

Look at the From: header when you do that.  It gets set to _your_
address.  You could use D, edit the from address to that of the
original sender and then fire to achieve the same effect (although I'm
not sure how it handles attachments, etc), but that's a lot of typing
for a common action.  I also believe that with D, since you're
injecting a new message with original content, that you'd lose much of
the original header info.

The idea is that when you 'bounce' the message, it's akin to you
having had a .forward in place at MTA delivery time.  Redirect, not
forward.

My biggest use case for this is bouncing mail sent to me personally
asking for support into our ticket system.  The original sender will
see the autoreply with the ticket id, etc because the From: header
contained their address.  Colleagues using other mail clients lacking
this feature will forward mail to the ticket system which sees them
get the replies.  They then have to go into the ticket and set a
proper 'requester' address for further correspondence on the ticket.

I remember when I discovered this feature in mutt how weird I thought
it was.  It wasn't long before it was in common use for me though.

Does that make sense?

Thanks
-Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090606/6730fbb2/attachment.bin>

---

From: [email-masked] (Nicolas Pouillard)
Date: Sat, 06 Jun 2009 16:36:12 +0200

> it was.  It wasn't long before it was in common use for me though.

It does! Thanks for the explanation.

---

From: [email-masked] (Helge Titlestad)
Date: Sat, 06 Jun 2009 14:03:14 +0200

> I don't get the purpose of this, how it is different from hitting 'D' to send

One out of several differences: D doesn't include attachments.

My personal use case: I have a couple of mail accounts - this one for all my
normal private stuff, one gmail account mostly for sharing documents and so on.
If I get a mail with an attachment that I can't read in a terminal (typically
pdf) to my private account, I will bounce it to my gmail account. That 
preserves the whole message, and is different from both "D" (which I use
to re-send mail) and forward (which I use to forward interesting stuff to
other people).
-- 
alge