reply from the sent-to address

People normally use vm-pcrisis for doing this kind of thing. Please feel free to explore that. It is a very powerful rule-based system, but it is easy to get burned.

When I first tried to program it, I wasn't careful and I was sending out replies as if they came from other people (probably the first recipient in the "To" header). I haven't gotten back to it ever since.

I am not entirely sure whether vm-pcrisis is the right tool for this kind of thing or whether we need to build it in. If we do build it in, we need something like *profiles* used in Thunderbird and Gnus.

hmm, this seems quite complicated to do a simple thing. Maybe people never do this, in which case I can struggle with that myself, but it seems other mailers make this simple. Perhaps an approach could be to use the Delivered-To header (if present) for the From field so long as it is in a vm-valid-mail-sending-addresses list. If it is not present (delivered-to header or valid mails variable), simply do the default which is not adding a from header.

This is more from the accessibility point of view, its a little clunky seeming to rely on external packages to do these seemingly simple everyday things. For more complicated on the fly actions pcrisis (or custom hooks) may be suitable. I also wonder whether profiles would strictly be necessary. Virtual folders, auto-folders etc are already equipped to handle this (based on headers). Maybe I'm overlooking other profile based actions that are like this and would be desirable.

Although it does seem complicated, pcrisis works really well. It has a lot
of functionality - once you come to grips with it, it is quite
straigh-forward.

I think the problem is that this seems like a simple thing when you first
look at it, but once you begin to look at the details, it quickly becomes
more complicated than you initially think. For example, the deliver-to filed
is no good as this can vary depending on how you collect hour mail. All the
mail I recieve via fetchmail has the same delivered-to header regardless of
where it was retrieved from (i.e. sent to address). In fact, Im not sure you
always have a delieverd-to header.

One of the nice things about pcrisis is that your not restricted to just
using various headers in mails you reply to. It is able to set headers based
on the address your sending to - this is handy when you need to initiate a
message to someone and want it to appear to have come form a specific mail
adress. I use this from home when using VM and need to send person, work and
list messages and want them to all appear distint (I don't want my personal
email being circulated at work etc).

If we did decide to integrate this sort of functionality into VM, we need to
make sure it works regardless of the individual setup i.e. handle mixture of
local and imap/pop, thunderbird mail boxes, multiple smtp servers, etc.
While we might be able to build on pcrisis and/or borrow ideas from gnus (I
like its posting-styles setup) or thunderbird, we need to also acknowledge
that getting this right is not a quick or simple task.

Tim

On Tue, Mar 29, 2011 at 12:19 PM, Arik <email address hidden> wrote:

> hmm, this seems quite complicated to do a simple thing. Maybe people
> never do this, in which case I can struggle with that myself, but it
> seems other mailers make this simple. Perhaps an approach could be to
> use the Delivered-To header (if present) for the From field so long as
> it is in a vm-valid-mail-sending-addresses list. If it is not present
> (delivered-to header or valid mails variable), simply do the default
> which is not adding a from header.
>
> This is more from the accessibility point of view, its a little clunky
> seeming to rely on external packages to do these seemingly simple
> everyday things. For more complicated on the fly actions pcrisis (or
> custom hooks) may be suitable. I also wonder whether profiles would
> strictly be necessary. Virtual folders, auto-folders etc are already
> equipped to handle this (based on headers). Maybe I'm overlooking other
> profile based actions that are like this and would be desirable.
>
> --
> You received this bug notification because you are subscribed to VM.
> https://bugs.launchpad.net/bugs/744001
>
> Title:
> reply from the sent-to address
>
> Status in VM (View Mail) for Emacs:
> Triaged
>
> Bug description:
> This is a feature request. It would be useful to have an option like
> vm-reply-from-recipient-address (or so) that will insert a "From:"
> header with the address to which the email was sent. This is useful in
> cases where a vm user has multiple mailboxes for different addresses
> in the same session, where only one can be the 'user-mail...

Hey Tim,

Thanks for the info. I will take a closer look at pcrisis and see what I can do with it. Your right that the Delivered-To header is unreliable, but its true too that the To: and Cc: could be unreliable in this sense too (additionally there would need to be a sanity check that it is choosing a sensible address from the To: lists - one you own), for instance if I got a mail to both addresses but I was looking at it in the mailbox associated with one and wanted to reply from there I would have a 50% chance of disappointment. Not sure if that's really a common real world example...

What are your thoughts, as a user of this functionality, on whether they should be absorbed? Is there a need for a better interface to them?

One of the nice things about pcrisis is that in addition to being able to
apply some heuristics to determine who the mail should appear from, you can
also choose a specific 'profile' per message or easily change what pcrisis
is automatically using.

Aa to the interface - well, I think its fine if your customizing it via ..vm
(thats how I did it). I would need to look at its support for customize to
determine if we could provide an easier wayt o do a basic configuration.
With respect to its interface with VM, I've had no problems with it - it
just sort of works for me. I cannot think of any issues I have had which I
thought needed to be improved. A lot may depend on what individual
requirements are - I wouldn't say I'm a power user of the package.

Possibly the main improvement would be to add to the documentation - maybe
add some basic recipes for setting up a really basic configuration and maybe
some examples of more advanced configurations. The pcrisis package is
extremely powerful - what took me the longest was just understanding how it
all fit together and realizing for my setup, I didn't need all the bells and
whistles. Once I broke it down to just what I needed, it was surprisingly
simple - initially, it was a little hard to see the wood for the trees.
Maybe a basic recipe or two would help with that. However, I must point out
that it was over 6 years ago that I did this setup and I've not had to
change it since (actually, in recent months I removed my pcrisis
configuration to maintain a stripped down config while I worked on other VM
issues). One of the problems with packages that are this reliable is that
you tend to forget the gory details!

Note that I'm not saying we should not add this sort of functionality into
core VM, only that doing so in a reliable and clean way is non-trivial and
that currently, VM does have this functionality via pcrisis, which is/has
been used by a number of people for quite some time. My recommendation would
be to use pcrisis for a while. This is likely to give a better position for
evaluating whether we can either integrate it better or add a 'light-weight'
solution that may be easier to use (possibly by borrowing ideas from pcrisis
and improving on them). I will try to find time to restore my old
configuraiton and see if there are any issues with current VM or Emacs 24
and try to refresh my memory regarding the package and some of the issues
involved in getting this right.

Tim

On Tue, Mar 29, 2011 at 2:54 PM, Arik <email address hidden> wrote:

> Hey Tim,
>
> Thanks for the info. I will take a closer look at pcrisis and see what I
> can do with it. Your right that the Delivered-To header is unreliable,
> but its true too that the To: and Cc: could be unreliable in this sense
> too (additionally there would need to be a sanity check that it is
> choosing a sensible address from the To: lists - one you own), for
> instance if I got a mail to both addresses but I was looking at it in
> the mailbox associated with one and wanted to reply from there I would
> have a 50% chance of disappointment. Not sure if that's really a common
> real world example...
>
> What are your thoughts, as a user of this...

So I got the customization of basic pcrisis variables working in such
a way as to give me what I was originally looking for (In fact it just
did some nice work on this email!)

Like you said, after you get past the initial "what the hell is this
and why is it done that way?", it actually ends up making some good
sense.

I do agree that the docs could use a couple of full examples (they
seem rather piece-wise at present) for the most common uses, with some
caveats for the headers to use. I think the biggest thing is to have a
better tie in to the main VM documentation, which is the first place a
user would think to look. There is only a brief mention in the Preface
to Add-ons, but if this package is the way to go, then the docs should
reference it in more useful places like the "composing mail" sections,
or even have a section on profiles directing the user toward specific
sections of the pcrisis manual.

Also, the customize interface is not as good as it could be. For
instance the vmpc-conditions has no type when it should be customized
as a repeat list. I'm also not sure why the customize stuff (and
everything else) is vmpc and not vm-pcrisis, which makes the
customization not as obvious.

So, in conclusion, perhaps some extra setup recipes, a more obvious
name and a place in the vm-docs that say these things can be attained
by putting (require 'vm-pcrisis) in your vm/emacs startup file would
make this an even more powerful addition to vm.

Cheers,
-Arik

Arik writes:

> Like you said, after you get past the initial "what the hell is this
> and why is it done that way?", it actually ends up making some good
> sense.

Great. Congratultions, Arik!

> I do agree that the docs could use a couple of full examples (they
> seem rather piece-wise at present) for the most common uses, with some
> caveats for the headers to use. I think the biggest thing is to have a
> better tie in to the main VM documentation, which is the first place a
> user would think to look. There is only a brief mention in the Preface
> to Add-ons, but if this package is the way to go, then the docs should
> reference it in more useful places like the "composing mail" sections,
> or even have a section on profiles directing the user toward specific
> sections of the pcrisis manual.

I have always felt that the main thing VM-Pcrisis needs is better
documentation. I get the feeling that it was written by a clever MSc
student, and the manual tends to be "theoretical". If you can make
the Vm-Pcrisis manual more readable, I will take care of putting hooks
in the VM manual.

The rule-based system technology that Pcrisis implements is extremely
powerful. In the long run, we probably want to use it for all kinds
of things in VM, including mail filtering, archiving, expiration etc
etc.

Cheers,
Uday

Agreed. Even something as simple as making the "profile names" more
descriptive of the action. For instance, instead of "Foo on the hill"
or the like, "message-to-account-1" as a condition and then
"send-from-account-1" as an action would generate a very descriptive
and readable reply mapping:

("message-to-account-1" "send-from-account-1")

Anyhow, I will see if I can take a go at cleaning up the docs. I was
thinking another main section dedicated to full examples/recipes, as
Tim suggested, would be a place many would think to start.

Thanks,
-Arik

Arik to work on improving the documentation.

Coding issues continued in Bug 909344.