Second, the email address in each recipient's certificate must match
the email address in the To:/CC:/BCC: line. In addition, the case
must match for the username portion (i.e., email@hidden
<mailto:email@hidden> does not match email@hidden <mailto:email@hidden>,
but email@hidden <mailto:email@hidden> *does* match email@hidden
<mailto:email@hidden>). The reason for this is buried deep in
RFC2822. It's annoying, but technically is correct behavior.
Third, *you* are always an unstated recipient of every mail you
send, so the second point applies to your own email address and
certificate as well.
Wouldn't be able to digitally sign if any of this were incorrect, right?
Address matching only applies to your own certificate when sending a
signed message. If you can sign, your cert & mail config is fine.
If you can't encrypt, then it's one of the other recipients.
Most likely, anyway. And under the DoD PKI, most probably. We don't
tend to update signing and encryption certificates because of email
address changes--there are a *lot* of these changes, and it makes the
CRLs more unmanageable than they already are. Outlook has an option to
suppress this checking, so that's used instead.
I've tried to cajole Apple into implementing a similar option to no avail.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/fed-talk/email@hidden
This email sent to email@hidden
