I think we are at a double-edged sword here.  I say that because I
definitely want it the old way, but I can understand why people would
not.  The reason I say I would want it the old way is that I have a TON
of account aliases to one account which I grab via an IMAP store.  Now,
when I go to reply to a mail in that store, the from is always the one
address instead of figuring out which address the message is ACTUALLY
sent to.  But, at the same time, I could see how some people might want
it another way.

I _HATE_ to say this, but any chance of making it a configuration option
(since you said both sets of code are in there already)?

Skadz

On Mon, 2002-07-29 at 13:57, Jeffrey Stedfast wrote:
> In Evolution 1.0.x, we searched the recipients of a message until we
> found one that matched one of your accounts email addresses and used
> that one by default in the composer. If we failed to find your account,
> we would use the X-Evolution-Source header to figure out which account
> it had been downloaded from. Unfortunately, a lot of people complained
> that they wanted it to use the account it was downloaded from, and so we
> now have the 1.1.x behavior:
> 
> If the X-Evolution-Source header exists, we use that to find out which
> account the message was downloaded from, failing that we fall back to
> the searching the recipients.
> 
> If you go back to probably even last week or the week before in the
> archives for this list, you'll find numerous messages complaining about
> 1.0.x "find my account from this message" behavior. In fact, every week
> there are lots of complaints. All of them wanted it the way it is now.
> You're actually the first person that wants it the old way :-)
> 
> Jeff
> 
> On Mon, 2002-07-29 at 08:51, Nigel Metheringham wrote:
> > I've recently switched to the 1.1.x development snapshots, and the
> > process evolution uses to determine the outgoing account/identity used
> > when sending messages has changed.
> > 
> > I have one receiving account defined - an IMAP server - and around 5
> > other accounts with no receive option, and the sending information all
> > the same other than the email address field.  Mail from all of those
> > accounts ends up on the same IMAP server (although in different
> > folders).
> > 
> > With evolution 1.0.x the appropriate sending account was normally picked
> > when replying to messages, presumably by matching the accounts against
> > information in the To/Cc fields in the messages being replied to.
> > 
> > With evolution 1.1.x a new message has the default account applied to
> > it.  Any replies or forwards use the account which matches the IMAP
> > server.
> > 
> > I can modify messages on delivery to add headers etc if needed, so if
> > there is a header I can tweak to "persuade" evo to pick the right
> > outgoing account that would help.
> > 
> > Otherwise can someone give me a clue as to how evo chooses the outgoing
> > identity.
> > 
> >     Nigel.
> > -- 
> > [ Nigel Metheringham           [EMAIL PROTECTED] ]
> > [ - Comments in this message are my own and not ITO opinion/policy - ]
> > 
> > 
> > _______________________________________________
> > evolution maillist  -  [EMAIL PROTECTED]
> > http://lists.ximian.com/mailman/listinfo/evolution
> -- 
> Jeffrey Stedfast
> Evolution Hacker - Ximian, Inc.
> [EMAIL PROTECTED]  - www.ximian.com
> 
> 
> _______________________________________________
> evolution maillist  -  [EMAIL PROTECTED]
> http://lists.ximian.com/mailman/listinfo/evolution
-- 
-----------------------------------------------------------------------
 Ryan P Skadberg                          E: [EMAIL PROTECTED]
 Director of Technology                   U: http://www.mindstorm.com/
-----------------------------------------------------------------------
  GPG fingerprint = 38A2 FF47 8FE3 B86A 7C68  6ECF 947D 4E9F 5FA9 637C
-----------------------------------------------------------------------



_______________________________________________
evolution maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution

Reply via email to