Hi Jon,
Couple things here.
1) Authors don't have GUIDs. The class matches the table (t_authors).
2) MailInterface.ComposeMailMessage() references a SecurityUser, not an Author.
3) SecurityUsers do have GUIDs... But they're not available in the API. :/
So you'll need to fetch it from the database. t_secuser.UserLogin is unique (not sure if it's key in the schema, but two accounts can't share the same login name) and should correspond to SecurityUser.Login, while t_secuser.UserID holds the GUID.
I say "should" because I haven't tested it and SecurityUser is a little odd in that not only does it omit the GUID but it also has a .FullName property which doesn't appear in the database. Presumably it's a concatenation of .FirstName and .Surname, but I'd be interested to know if it actually works correctly given that the correct order for a person's name depends on the language. Or maybe that's actually a misnamed GUID property? Probably worth checking.
All that said, the Element.Author property is free text, not a reference. Furthermore, the value EA uses to set this property when you create an element is configured in the client. By default, it's set from the login data but it can be overridden. And if you import logins from the AD, whether t_author rows are created when importing users is selected during the import (so it's not even a project setting).
In other words, there is no guarantee that
a) you'll find Element.Author in t_authors, or that
b) you'll find it in t_secuser.
So if you want to send an in-EA mail to the author of an element, you'll need to take those cases into account.
HTH,
/Uffe
