> We don't use Exchange in-house, but my understanding is that Exchange

> distribution lists are basically just aliases that mail to some subset of your active

> directory users.



Picture the GUI you use to add people to a file ACL in Windows. This is basically what Exchange 2007 offers in terms of mailing lists (I haven't migrated to 2010 so there might be more, but if so I couldn't find it on their web site). The big upside, as I see it, is if your organization already has a comprehensive internal structure with all sorts of nested distribution groups and what not. Then you can just drag and drop these groups and create your internal lists in minutes (you could do it with a DQL in LISTSERV but it is more work of course). The problem is when someone wants to be removed from one of the lists and he is in via a nested list - no can do. Unless he is an employee, it could be illegal to refuse. You can explode the groups and remove the user of course, but it negates the benefit.



There is also supposedly some sort of synergy with public Exchange folders. Public folders are basically like a shared Windows directory but inside Exchange, so ACL options are limited, but the upside is that it is handled like e-mail so Outlook will cache it on your laptop. This sounds very cool until your Outlook mailbox file reaches 4G (or was it 8G?) and Outlook engages bullet time. Then it gets *extremely* cool for maybe around 20 seconds as you see Outlook making individual draw/paint operations. Finally you realize that you are going to spend the remainder of your mortal life in bullet time ;-( They released a patch that improved handling of large mailbox files but "improved" is the key. With the second patch and an SSD, it is actually quite ok but what's wrong with regular shared Windows folders? My problem of course is that I am over the limit even without public folders :-( This is a client issue though, Exchange seems to have no problem with large mailboxes.



Other than these special cases, I was about to say that:



> Sort of like the mail aliases that LISTSERV was designed to replace back in the 1980s :)



But Liam beat me to it :-) I am surprised that anyone would seriously consider this sort of system for external mailing lists. It could be entertaining to ask the MS sales guy what product Microsoft is using for external lists.



All this being said, I use Exchange myself and it is a pretty good product otherwise (since 2007). It requires a ridiculous amount of RAM for the work done and is very painful to manage if you need to use one of the functions that aren't implemented in the management GUI, which seems to be 75% of the functions, but hey I have managed sendmail so I can handle a PowerShell prompt ;-) Once you get it working and fix all the AD problems its setup program created without even telling you, it is surprisingly reliable and enables new functionality in Outlook. And you won't have to worry that your new smartphone may not support it because every phone pretty much has to support Exchange (I cannot tell you which major IT research company has bought brand new smartphones for every employee that unfortunately do not connect to the mail system they use - nobody had thought to research this ahead of time since they bought a leading smartphone and use a major e-mail system). Maybe I had low expectations for Exchange but they were exceeded and the non-technical users love it. The main gripe is that it "eats" mail headers so this is not the right mail system for people working in support. Exchange will decode MIME attachments and store them in some kind of binary form or whatever, and toss the envelope in the trash, so if you need to debug an error in MIME headers generated by your software product... Not Good. I just use VM for that.



  Eric