wlalias 1.0 released - Create email aliases for Domains for Windows Live
Well, in less than 72 hours after having David convince me to write the tool, I've already published version 1.0 of wlalias. Actually, it was closer to 48 hours, but who's counting? Really though, it isn't all that impressive. I had most of the core code already written all I had to do was add command line parameters, fluff, error checking, fluff, and licensing. In case you're wondering, I personally call it wail-lias even though that's not how it's written. If you're not interested in the rest of this text and want to download it, the compiled binary is available in the project's download section.
Speaking of licensing, my previous post about that was a bit off. I decided to keep using the Microsoft Public License (Ms-PL) as my license and keeping within my other projects. As usual, the license comes with no warranty or guarantees and pretty much lets you do what you want with it, including selling it. I'll admit, I'd be very sad if someone did that, but it's not like I could stop them anyway.
All right, getting down to it, the tool is very basic and can handle herself in the basic situations in which she was designed to run. The output and printed help are both very basic and things in which I plan on improving in the future. I promise (not legally binding though!) that there are no bugs or viruses and that no communication is sent back to me or any of that stuff (take a look for yourself if you want). The three basic situations that the tool is designed for are:
Listing known aliases for a member.
Adding a new alias for a member (up to 15, Microsoft's rule).
Removing an alias for a member.
Administrative Credentials
This isn't explained very well in the program itself, but you'll need to provide some admin credentials to use the remote service. By administrative credentials I mean that you'll need to use an account that not only manages the domain the user's account logs in with but it will also need to manage the domain of the alias. If the alias you're adding or removing exists in the same domain as the user's login domain, you'll generally be fine. If you're adding or removing a domain that is not related to the login domain, you'll need to make sure your admin account can manage both (i.e. both domains are listed when you log in to domains.live.com).
Listing known alaises
Ok, this one is pretty straight forward, you'll run
wlalias list email@address to show the currently assigned aliases
for the user. The documentation states that the parameter is the "fully
qualified member's name" which I've found to be their login email
address. If the user is found and is a part of your managed domains the
aliases will be printed.
Adding a new alias
Creating an alias is just as straightforward as the rest of the
application. In this case you'll run
wlalias add login@email newalias@email and provide the admin
credentials as usual. Just as a note, both the login email and the new
alias must be "fully qualified" as described above. Sadly the
application has to do a little guess work here since Microsoft is lying.
When calling the CreateAlias method the documentation says:
Return Value
An XML block that contains a list of alternative names. The following is an example of the XML block. [...]
Well, as much as I'd love to believe that, I've never, ever received an XML block of alternative names. All I get back s a hash of some sort that doesn't correlate with anything that I know of. I've followed all of their directions as best I could and can't seem to find where the problem might be. I suppose I can use Fiddler and see if it's actually returning the wrong data or if it's the implementation, but that's for another day. Instead, the application will then call to list the aliases a second after creation and see if the alias is in the list and let you know accordingly.
C:\wlalias\bin>wlalias add test_user@gibixonline.com test_user6@gibixonline.com Adding alias test_user6@gibixonline.com to account test_user@gibixonline.com. If this is incorrect, press ^C or press escape in the password entry. Please provide administrative credentials for the domain to manage. Username: teehee.heehee@gibixonline.com Password: Creating alias...done. The server returned: 0003CEEB822590A9 According to the docs the server should've returned the alias as the result. Since it didn't, I'm checking the alias list of the user name to see if it's listed. The alias was found.
Removing an alias
After the previous two sections, this one will be the shortest. It's
very close to the previous command except that you give it the address
to remove, wlalias remove login@address alias@address. It takes two
parameters: the fully qualified login name and the alias to remove.
There is no return value from this call so all I have to go on is the
fact that the server didn't return an error when being called.
C:\wlalias\bin>wlalias remove test_user@gibixonline.com test_user5@gibixonline.com Removing alias test_user5@gibixonline.com from account test_user@gibixonline.com . If this is incorrect, press ^C or press escape in the password entry. Please provide administrative credentials for the domain to manage. Username: maybe?.nahnope@gibixonline.com Password: C:\wlalias\bin>
That's it, there's no output. Well, it'll mention something if it failed via HTTP. I suppose it could've checked like it did during creation but I didn't add it this time.
Future
While the tool is functionally complete, I do plan on making a few modifications in the future. As I was testing, I got tired of typing in the password and realized that this tool cannot be easily automated at this time. I was thinking of allowing you to store the username and password in envrionment variables and using those if they exist. Honestly, I just didn't want to deal with handling a password coming in via the command line. Also, with my current method, your password is secured and only exists in a readable format for less than a second (during the Authentcation() call). If I allow automation, that means your password will exist as a full string in memory that I won't be able to clear when I'm done. My other thought is to clean up the output and make it a bit easier to read. I was also thinking of expanding this to allow some other management of Windows Live, but we'll see.
If you made it this far, I congratulate you. You must have missed the download link I put in the first paragraph. The official download source of the application will always be on the project's repository, so be sure to download it from there.
If you have any issues, please feel free to create a new issue on wlalias' issue tracker. If I remember right, you won't need to sign up to create one. If you want, you can also contact me through my blog and I'll try to respond.
I can only hope that you find this tool useful. Once again, download wlalias 1.0 and create aliases with (relative) ease!
Imported Comments
Marius on Monday, September 24, 2012 at 10:02 AM wrote:
Worked like a charm. Thanks
Tony Gray on Tuesday, October 30, 2012 at 9:52 AM wrote:
This is fantastic. Thanks!
Pim van de Vis on Thursday, November 1, 2012 at 4:05 AM wrote:
Briljant! You're a real lifesaver. I created separate mailboxes for my aliassen and created forwarding rules, but that's not perfect.
When I tried to create the aliasses I got an error, because the adressen already existed. When I deleted the forwarded-mailboxes, I could instantly create new aliasses using the same name.
I'm happy, and thanx for the great tool.
Funny thing is: Microsoft doesn't expose the alias-feature in their interface, but it is a supported feature, because I received confirmation mails that I succesfully created some alliasses. And I can now choose which alias to use when sending new email, just my clicking on a dropdown box.
Joseph on Monday, November 5, 2012 at 5:27 AM wrote:
Great - worked brilliantly. But now it is showing me a Passport error?
Jim on Wednesday, November 7, 2012 at 12:20 AM wrote:
Thanks for the great tool! Was gonna write one myself but found your tool. Now the last obstacle of moving from Google Apps to Windows Live is removed.
Steven on Friday, November 16, 2012 at 10:29 AM wrote:
Fantastic!! Thanks for the coding effort Josh. It would have taken me a lot longer to figure this out.
Manuel on Tuesday, December 4, 2012 at 9:18 AM wrote:
Thanks for sharing this tool, it's working perfectly! (and saves me from a big headache) Greetings, Manuel
Phil on Monday, December 10, 2012 at 11:01 AM wrote:
Can this tool be used to direct an alias to any email address? For instance if I own domain.com and I want to create the alias test@domain.com that goes to the email address test@hotmail.com (on a domain I don't own) is it possible? I know other email applications allow you to setup an alias using any domain you own to go to any email address.
The reason I ask is our is looking at using domains.live.com to manage our clients email. Our clients will often have us setup an alias like info@domains.com, but want it to go to their personal address like example@aol.com. Google Aps allows you to direct the alias to any email address, even if it's not on the same domain. This tool doesn't appear to do that.
Joshua on Friday, December 14, 2012 at 11:56 AM wrote:
Phil, to my knowledge you can set an alias for any domain name managed by the same domain administrator account under https://domains.live.com. So if you add both example.com and example.org and have an admin account with permissions to both, you can create an alias for you@example.com and you@example.org. (The domain names can be anything obviously, I just chose example for safety).
As for redirecting mail, no, the alias must be attached to an existing account under your control. You could, however, create an account with that name and set up mail forwarding. I'm not sure if inactive expiration rules apply to managed accounts though.
Joshua on Monday, December 24, 2012 at 11:15 PM wrote:
For those of you following from home, an update has been released to provide more helpful error information. wlalias 1.5 released - Create email aliases for Domains for Windows Live
Sid on Thursday, January 10, 2013 at 10:10 PM wrote:
Thanks Josh!! Very cool. I must admit I was a bit nervous punching in the admin credentials into a tool just downloaded "off the internet". I opened the source in VS2012 and stepped though the entire core (even compared against the class created by the SOAP service' WSDL!). Didn't notice anything hanky-panky :). You even used the SecureString class! BTW, if you store the credentials into isolated storage, why do I need to type them everytime (Windows 8)? I built the binary myself in VS2012 (unsigned though, key isn't in hg)
Joshua on Monday, January 14, 2013 at 11:38 AM wrote:
Sid,
The credential storage should work without much issue once you run the "store" command. Since you're running an unsigned version, the isolated storage space chosen by .Net will vary based on the location you're running the executable. Try copying the resulting binary to a new location, run the store command, then try running one of the other commands and it should work.
You should be able to verify the credentials are stored by looking in your isolated storage directory at %localappdata%\IsolatedStorage. The directory path it'll live under is random (based off the strong name if available, or the executing path otherwise). Dig deep until you find the "AssemFiles" directory and you should see "key" and "credentials", the contents of which are encrypted of course.
I also use VS2012 and run on Windows 8, so let me know if you aren't able to get stored credentials working for you! Joshua
DB on Saturday, July 13, 2013 at 5:06 PM wrote:
Thank you. It just works, and that's what's good about it.