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
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. Reformatted excerpts from Ben Walton''s message of 2009-05-31:> 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?You could just make it say "Bounce to #{to.size} recipients?". :) -- William <wmorgan-sup at masanjin.net>
Excerpts from William Morgan''s message of Fri Jun 05 12:02:17 -0400 2009:> I''m definitely interested in having this feature. But it does open > upGreat.> some complications because we have to be able to call the MTA in two > different modes.Nothing is free! :)> 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.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>
Excerpts from William Morgan''s message of Fri Jun 05 18:02:17 +0200 2009:> 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.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
Excerpts from Nicolas Pouillard''s message of Sat Jun 06 12:16:55 +0200 2009:> I don''t get the purpose of this, how it is different from hitting ''D'' to send > again the same message?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
Excerpts from Nicolas Pouillard''s message of Sat Jun 06 06:16:55 -0400 2009:> I don''t get the purpose of this, how it is different from hitting ''D'' to send > again the same message?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 -- 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/20090606/6730fbb2/attachment.bin>
Excerpts from Ben Walton''s message of Sat Jun 06 14:44:15 +0200 2009:> Excerpts from Nicolas Pouillard''s message of Sat Jun 06 06:16:55 -0400 2009: > > I don''t get the purpose of this, how it is different from hitting ''D'' to send > > again the same message? > > 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?It does! Thanks for the explanation. -- Nicolas Pouillard http://nicolaspouillard.fr