[dev] "Recipient address does not match the currently selected identity"
Jan Schneider
jan at horde.org
Wed Jul 7 08:27:49 UTC 2010
Zitat von Michael M Slusarz <slusarz at horde.org>:
> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> This seems rather unfriendly. First of all the error message is
>> confusing; even knowing the code I didn't know what it could mean.
>> It might be okay if it was smart enough to somehow know which
>> addresses were list addresses and which weren't, but it's not. I've
>> seen this:
>
> Very confused by this statement. IMP isn't smart enough to figure
> out whether the message is a list message or not - more accurately,
> IMP doesn't care. It is the *user* who explicitly determines this
> via their identity preferences.
>
> This recipient checking feature has *nothing* to do with list
> addresses - it deals solely with tied addresses. OTOH, list
> addresses are probably the main thing tied addresses are useful for.
>
>> - when sending to one of my email addresses from another (why do I
>> need to do that? probably no reason, though pgp could be one. but
>> why should it ever fail, or require me to "tie" addresses? what
>> does tieing an address mean, anyway?). None of my personal
>> addresses are list addresses.
>
> As far as tied addresses - if you are unsure of what they are then
> this is probably bad news on our part re: documentation since tied
> addresses have been around for 6-7 years. A tied address indicates
> what identity to use when replying to a message. It is a list of
> From e-mail addresses that are used, at the time of replying, to
> determine what the default identity should be.
>
> IIRC, the recipient checking algorithm is as follows:
> 1. If the message is not being sent to a single e-mail, don't do
> identity check.
Why not? I'm not sure this is really what you meant, but of course we
need to pick the correct identity even if I am only one of many
recipients.
> 2. Generate a hash of addresses for each identity. The key is the
> identity e-mail address, the value is all of the e-mail addresses
> tied to the identity address **including the identity e-mail
> itself** (This is pseudo code - the actual code is optimized and an
> in-memory hash isn't created)
> 3. Find e-mail address in the hash generated in Step 2. If the
> identity is not the same as the identity used to send the message,
> output a warning.
This confuses me. This only makes sense if the message I'm replying to
is actually sent from *any* of my identities (tied or not), right?
In any case, this should really be a warning only, not an error like
on Chuck's screenshot.
> The issue you have raised has to do with including the identity
> e-mail itself in the the list of addresses for an identity. You've
> raised a case that seems to indicate that these e-mail addresses
> should be excluded from this list.
>
>> - when sending to my wife and my shared email address (which I also
>> have an identity to send from) - I suppose you could argue that
>> this is a "list" address, but I don't buy it.
>
> Sounds like the same issue as above.
>
>> - in the case already outlined. I can delete my identity for
>> core at horde.org, but going back to your explanation - I haven't set
>> up any of my identities to be tied to anything, as far as I know.
>> So why am I seeing this error?
>
> This still sounds like the same issue. Obviously, if no tied
> addresses are available, we shouldn't be doing this check so if
> that's not happening, it is a bug.
>
> But I firmly believe that if any tied addresses are being used, this
> check MUST be mandatory (i.e. no pref to turn this off) . That's
> kind of the whole purpose of using tied addresses in the first place.
>
> michael
>
> --
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
>
> --
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
More information about the dev
mailing list