Apple Mail and Exchange Servers

EROSLONIEC wrote:
> Our University has decided it is time to switch all E-mail to an
> Exchange Server, and has tried to tell us that Apple Mail will not
> work with this server. We of course know that this is not true, and
> that all they have to do is enable the IMAP function and it works.
> They are declining to do it. So how do I convince them to do this? We
> are not a Mac minority either, more than 50% of the scientist use
> Macs, but the administration does not.
>
> If you are using Exchange with Apple's Mail, or have fought this
> battle, we would greatly appreciate hearing your story. Also, we
> would appreciate hearing about any of the technical reasons why or
> why not using the IMAP feature in Exchange is a problem. Knowledge is
> power. -- If you want to unsubscribe or change your address, use this
> link: http://emperor.tidbits.com/webx?unsub.3c3f6899!u=3054478e

Apple Mail.app's IMAP has problems and has had problems for several
years now. It seems that having a "good" IMAP client isn't high on
Apple's priority list.

Exchange Server in the past has had bugs in it's IMAP implementation. MS
went years saying it would be fixed in the "next" release, which
introduced new bugs.

Neither of these issues were BANG, BIFF, POW, in your face bugs but
subtle ones like Mail not always showing new IMAP email unless you quit
and started the program back up.

All of this is take from my participation on other technically oriented,
mail admin oriented mail lists.

Which is which I've never used either product in my client situations.

On 10/19/06 13:06, "EROSLONIEC" <erosloniecutmem.edu> wrote:

> Our University has decided it is time to switch all E-mail to an Exchange
> Server, and has tried to tell us that Apple Mail will not work with this
> server. We of course know that this is not true, and that all they have to do
> is enable the IMAP function and it works. They are declining to do it. So how
> do I convince them to do this? We are not a Mac minority either, more than 50%
> of the scientist use Macs, but the administration does not.

Actually, they have to enable IMAP, SMTP, DAV and LDAP.

>
> If you are using Exchange with Apple's Mail, or have fought this battle, we
> would greatly appreciate hearing your story. Also, we would appreciate hearing
> about any of the technical reasons why or why not using the IMAP feature in
> Exchange is a problem.

Other than personal preference, you're going to have a hard time coming up
with a valid technical reason for this. If they enable DAV and LDAP, then
there is an Exchange client for the Mac that will work with Exchange far
better than Mail. Entourage. Is E'rage as good as Outlook as an Exchange
client? Nope, but it's FAR better than Mail, and unless you plan on using
Outlook Web Access exclusively for your calendaring, you're spending some
money to get iCal to work with Exchange anyway, and you'll still have less
functionality than Entourage.

If you have a current version of Entourage, then Sync Services allows you to
sync notes, tasks, contacts and events with Address Book and iCal.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 10/19/06 at 11:06 AM, EROSLONIEC <erosloniecutmem.edu> wrote:

> If you are using Exchange with Apple's Mail, or have fought this
> battle, we would greatly appreciate hearing your story. Also, we
> would appreciate hearing about any of the technical reasons why or
> why not using the IMAP feature in Exchange is a problem. Knowledge
> is power.

I'm stunned to hear a university would implement Exchange and not
implement the open standards it supports for mail access. The Mac/Apple
Mail issue isn't relevant in my mind; supporting open standards ought to
be mandatory in an educational/research setting. (Why? Well for one,
it's almost impossible to predict the requirements of a research
community, and maintaining an I.S. infrastructure based on open
standards virtually guarantees compatibility and interoperability with
whatever project or technology might come along, and enables the
flexibility and creativity that should be the hallmark of an institution
of higher learning. But I digress...)

We use Exchange with Apple Mail (and Outlook, Entourage, Thunderbird,
Eudora, Netscape, Mozilla, and whatever else) at my place of employ.
Exchange IMAP support works fine with Apple Mail and, to my knowledge,
nearly all IMAP clients. Exchange also supports TLS/SSL encryption of
IMAP, POP, and SMTP, so if they're worried about passwords passing in
the clear, they need to get back to Exchange training and flip the
appropriate switches. (And yes, Apple Mail supports encryption of these
protocols as well.)

In a nutshell:

- Exchange supports secure IMAP, POP, and SMTP
- Open standards enable maximum compatibility and interoperability
- Implementation of secure IMAP, POP, and SMTP on Exchange is easy and
straightforward
- There are no technical reasons why enabling IMAP would be a problem
(just human knowledge-gap issues, which should be easy to close)

And finally, Outlook is mediocre, so all their users should be using
other mail clients anyway. ;-)

Cheers,

- Todd
--
"People who read Cosmopolitan magazine are very different from those who do not."
- Donald Berry, Statistics: A Bayesian Perspective

On 10/19/06 2:06 PM, "EROSLONIEC" <erosloniecutmem.edu> wrote:

> Our University has decided it is time to switch all E-mail to an Exchange
> Server, and has tried to tell us that Apple Mail will not work with this
> server. We of course know that this is not true, and that all they have to do
> is enable the IMAP function and it works. They are declining to do it. So how
> do I convince them to do this? We are not a Mac minority either, more than 50%
> of the scientist use Macs, but the administration does not.
>
> If you are using Exchange with Apple's Mail, or have fought this battle, we
> would greatly appreciate hearing your story. Also, we would appreciate hearing
> about any of the technical reasons why or why not using the IMAP feature in
> Exchange is a problem. Knowledge is power.

If they're not enabling IMAP then they're not only cutting off Apple Mail
but all non-Microsoft mail clients, leaving Entourage 2004 for Mac and
Outlook for Windows as the only options (I would hope they're enabling
WebDAV so Entourage can work!) I can think of two reasons for choosing this,
security and support costs.

The security reason boils down to this, if you don't use IMAP, you don't
have to secure it. If there's an Exchange exploit that works via IMAP, they
don't have to worry about it. They also don't have to worry about brute
force password cracking attempts through IMAP authentication. Frankly, these
seem like minor issues for a university to deal with.

I also wonder what they're doing with SMTP. Of course they need SMTP to send
and receive mail to/from other mail servers but they might not let mail
clients use it since Entourage and Outlook don't. This can help keep their
server from being used to send spam but it is bad news for servers and other
systems that send reports, warnings and alerts by mail.

The more likely argument the typical upside to monoculture one; it's cheaper
to standardize what everyone uses and to support only those options. A
software monoculture can increase security risks but for mail clients only,
I'm not sure it's a significant concern. The bigger problem with the
monoculture is it assumes the same tool is suitable for every person and
job.

If there are people who *can't* use Entourage or Outlook, because they don't
use OS X or Windows, because their funding is insufficient to have a good
enough computer, their plight is an argument for enabling IMAP. Examples of
real things people use a different mail client for that can't be done with
Microsoft clients will help. The cost of Office probably isn't a significant
factor for employee use but if students are also using the Exchange system,
it could be for them. I don't know the mechanics of how it works but faculty
cries about impinging on academic freedom* also seem to be effective in a
wide range of circumstances.

It'll probably help to find out where various groups stand on the issue.
Who's idea was this? If this policy started with someone lower in the
hierarchy, the next person up may be easier to convince. However if this
policy came from the CIO or whoever is the top person for IT, it's probably
too small an issue for a university president to get into but a Dean of
Faculty could go to the CIO about it. Was it the server administrators
themselves? If not, there could be allies there. If it was a higher-up
decision, desktop support or other IT staff who might appear to benefit may
not actually be in favor of it and could affect change from within
(supporting a monoculture is relatively boring, is bad for career building,
and makes them look less competent).

* I work in higher ed and consider academic freedom an important principle
but after hearing it invoked by a professor when asked not to share their
passwords, it's taken on a "cried wolf" quality for me.

On 10/20/06 14:07, "Todd Ruston" <toddhackneyponies.com> wrote:

>> If you are using Exchange with Apple's Mail, or have fought this
>> battle, we would greatly appreciate hearing your story. Also, we
>> would appreciate hearing about any of the technical reasons why or
>> why not using the IMAP feature in Exchange is a problem. Knowledge
>> is power.
>
> I'm stunned to hear a university would implement Exchange and not
> implement the open standards it supports for mail access. The Mac/Apple
> Mail issue isn't relevant in my mind; supporting open standards ought to
> be mandatory in an educational/research setting. (Why? Well for one,
> it's almost impossible to predict the requirements of a research
> community, and maintaining an I.S. infrastructure based on open
> standards virtually guarantees compatibility and interoperability with
> whatever project or technology might come along, and enables the
> flexibility and creativity that should be the hallmark of an institution
> of higher learning. But I digress...)

I think that buying exchange as an IMAP/POP/SMTP server is an astounding
waste of money and capabilities. Why would you waste the very real cash for
Windows Server and Exchange if all you're going to do with it is replicate
what you can get for free on any linux distro or open solaris that will run
for free on the same hardware.

I'm surprised such a thing passed the laugh test. Exchanges very real value
comes not from email, but from its groupware featureset, which is something
that only now is getting any real competition in the open source space, and
even then, the only non-web client supported is Outlook. If you want offline
groupware clients, the options OUTSIDE of Exchange drop to less than a
handful. (No, I am most certainly not counting Notes. That UI is beyond
horrid, and is inflicted upon people you wish to hate you.)

> And finally, Outlook is mediocre, so all their users should be using
> other mail clients anyway. ;-)

Outlook is mediocre as an internet only client. If you use Exchange as it
should be used, then Outlook is really quite nice. The uses you describe
limiting Exchange to are a complete waste of money for that product.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 10/20/06 14:09, "Curtis Wilcox" <tidbitscognize.org> wrote:

>> Our University has decided it is time to switch all E-mail to an Exchange
>> Server, and has tried to tell us that Apple Mail will not work with this
>> server. We of course know that this is not true, and that all they have to do
>> is enable the IMAP function and it works. They are declining to do it. So how
>> do I convince them to do this? We are not a Mac minority either, more than
>> 50%
>> of the scientist use Macs, but the administration does not.
>>
>> If you are using Exchange with Apple's Mail, or have fought this battle, we
>> would greatly appreciate hearing your story. Also, we would appreciate
>> hearing
>> about any of the technical reasons why or why not using the IMAP feature in
>> Exchange is a problem. Knowledge is power.
>
> If they're not enabling IMAP then they're not only cutting off Apple Mail
> but all non-Microsoft mail clients, leaving Entourage 2004 for Mac and
> Outlook for Windows as the only options (I would hope they're enabling
> WebDAV so Entourage can work!) I can think of two reasons for choosing this,
> security and support costs.

Incorrect. Evolution on Linux, etc. will work quite nicely with Exchange
servers, via DAV.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 19 okt 2006, at 20:06, EROSLONIEC wrote:

> Greetings,
>
> Our University has decided it is time to switch all E-mail to an
> Exchange Server, and has tried to tell us that Apple Mail will not
> work with this server. We of course know that this is not true, and
> that all they have to do is enable the IMAP function and it works.
> They are declining to do it. So how do I convince them to do this? We
> are not a Mac minority either, more than 50% of the scientist use
> Macs, but the administration does not.
>
> If you are using Exchange with Apple's Mail, or have fought this
> battle, we would greatly appreciate hearing your story. Also, we would
> appreciate hearing about any of the technical reasons why or why not
> using the IMAP feature in Exchange is a problem. Knowledge is power.

Do they enable POP? I am using Apple Mail with the POP-server
functionality of our university Exchange server. I prefer that over
IMAP.

Kees

On 10/23/06 5:34 AM, "John C. Welch" <jwelchbynkii.com> wrote:

> I think that buying exchange as an IMAP/POP/SMTP server is an astounding
> waste of money and capabilities. Why would you waste the very real cash for
> Windows Server and Exchange if all you're going to do with it is replicate
> what you can get for free on any linux distro or open solaris that will run
> for free on the same hardware.

I agree that using Exchange for email only is very much a waste. The same
hardware used to run an Exchange server can handle many, many more clients
if the server instead runs some flavor of Unix and open source IMAP/POP/SMTP
services. However, there was nothing in the original message that said they
*weren't* going to use Exchange for more than email.
 
> I'm surprised such a thing passed the laugh test. Exchanges very real value
> comes not from email, but from its groupware featureset, which is something
> that only now is getting any real competition in the open source space, and
> even then, the only non-web client supported is Outlook. If you want offline
> groupware clients, the options OUTSIDE of Exchange drop to less than a
> handful. (No, I am most certainly not counting Notes. That UI is beyond
> horrid, and is inflicted upon people you wish to hate you.)

This reminded me of a third justification for not enabling IMAP. By not
running IMAP (or presumaby, POP), they force everyone to use a client which
supports not only email but also features like group calendaring, which are
probably the reason they're switching to Exchange in the first place.

Group calendaring is only as useful as there are people using it for their
individual calendars. Scheduling meetings by email is slow and tedious while
doing so through group calendaring is quick and easy but only if all
attendees have an up-to-date calendar in the system. Even when everyone is
using the "right" client, it can be hard to for them to change or create new
habits. If they're using email-only clients and have to run Entourage,
Outlook, or login to Outlook Web Access for calendaring only, they're much
less likely to take that extra step.

While I think an IT department could reasonably state that they only support
Entourage and Outlook, they should still provide IMAP for unsupported use.

On 10/23/06 15:56, "Curtis Wilcox" <tidbitscognize.org> wrote:

>> I think that buying exchange as an IMAP/POP/SMTP server is an astounding
>> waste of money and capabilities. Why would you waste the very real cash for
>> Windows Server and Exchange if all you're going to do with it is replicate
>> what you can get for free on any linux distro or open solaris that will run
>> for free on the same hardware.
>
> I agree that using Exchange for email only is very much a waste. The same
> hardware used to run an Exchange server can handle many, many more clients
> if the server instead runs some flavor of Unix and open source IMAP/POP/SMTP
> services. However, there was nothing in the original message that said they
> *weren't* going to use Exchange for more than email.

Saying that is called "Predicting the future". I find that to be unreliable
at best.

>
>> I'm surprised such a thing passed the laugh test. Exchanges very real value
>> comes not from email, but from its groupware featureset, which is something
>> that only now is getting any real competition in the open source space, and
>> even then, the only non-web client supported is Outlook. If you want offline
>> groupware clients, the options OUTSIDE of Exchange drop to less than a
>> handful. (No, I am most certainly not counting Notes. That UI is beyond
>> horrid, and is inflicted upon people you wish to hate you.)
>
> This reminded me of a third justification for not enabling IMAP. By not
> running IMAP (or presumaby, POP), they force everyone to use a client which
> supports not only email but also features like group calendaring, which are
> probably the reason they're switching to Exchange in the first place.

But then, they aren't using calendaring, right?

>
> Group calendaring is only as useful as there are people using it for their
> individual calendars. Scheduling meetings by email is slow and tedious while
> doing so through group calendaring is quick and easy but only if all
> attendees have an up-to-date calendar in the system. Even when everyone is
> using the "right" client, it can be hard to for them to change or create new
> habits. If they're using email-only clients and have to run Entourage,
> Outlook, or login to Outlook Web Access for calendaring only, they're much
> less likely to take that extra step.

That's based on an erroneous assumption, which is, work habits won't change
to use expanded capabilities, based on the current non-existence of those
capabilities. That's a bad way to go, and tends to bit you in the butt. Even
a half-hearted education attempt will mitigate most of the client
infamiliarity issues.

>
> While I think an IT department could reasonably state that they only support
> Entourage and Outlook, they should still provide IMAP for unsupported use.

There's no such thing as "unsupported, but allowed". Eventually, someone
gets the pull to force support of <client>. So basing judgement on that is
not a great idea

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 10/23/06 at 2:34 AM, John C. Welch <jwelchbynkii.com> wrote:

> I think that buying exchange as an IMAP/POP/SMTP server is an
> astounding waste of money and capabilities.
[...]
> Outlook is mediocre as an internet only client. If you use
> Exchange as it should be used, then Outlook is really quite nice.
> The uses you describe limiting Exchange to are a complete waste of
> money for that product.

Hi John,

Where did I describe limiting Exchange to IMAP/POP/SMTP? I agree
wholeheartedly with your points about cheaper ways to implement
email-only solutions. The OP was asking for info regarding reasons for
or against implementation of IMAP on an existing Exchange installation,
and that's what I was addressing.

My point regarding open standards (to perhaps make it more clear) is
that a research institution (e.g. university) may have projects that
require an open messaging system (e.g. e-mail) for remote assest data
communication. If the university's sole e-mail system (or at least the
one that serves the scientists, as described by the OP) is Exchange
without IMAP/POP/SMTP support enabled, that presents a barrier to such
projects that is unconscionable, IMO.

I still think Outlook is mediocre, no matter how it's used... ;-)

- Todd

On 10/24/06 14:42, "Todd Ruston" <toddhackneyponies.com> wrote:

>> Outlook is mediocre as an internet only client. If you use
>> Exchange as it should be used, then Outlook is really quite nice.
>> The uses you describe limiting Exchange to are a complete waste of
>> money for that product.
>
> Hi John,
>
> Where did I describe limiting Exchange to IMAP/POP/SMTP? I agree
> wholeheartedly with your points about cheaper ways to implement
> email-only solutions. The OP was asking for info regarding reasons for
> or against implementation of IMAP on an existing Exchange installation,
> and that's what I was addressing.

IMAP is for data from the MTA to the MUA. Using IMAP for that is not any
better or worse than using DAV in this case.

> My point regarding open standards (to perhaps make it more clear) is
> that a research institution (e.g. university) may have projects that
> require an open messaging system (e.g. e-mail) for remote assest data
> communication. If the university's sole e-mail system (or at least the
> one that serves the scientists, as described by the OP) is Exchange
> without IMAP/POP/SMTP support enabled, that presents a barrier to such
> projects that is unconscionable, IMO.

You have a very odd idea about Exchange. You can have Exchange talk to the
outside world without needing POP/IMAP/SMTP to the clients. In fact, I'm
doing this today. We don't expose any of those three to our clients. It's
all DAV/MAPI/LDAP. Connectivity is achieved, with needed groupware
functionality

> I still think Outlook is mediocre, no matter how it's used... ;-)

That may be, but as a groupware client, it's better than the rest.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 10/25/06 at 5:06 AM, John C. Welch <jwelchbynkii.com> wrote:

> You have a very odd idea about Exchange. You can have Exchange
> talk to the outside world without needing POP/IMAP/SMTP to the
> clients. In fact, I'm doing this today. We don't expose any of
> those three to our clients. It's all DAV/MAPI/LDAP. Connectivity
> is achieved, with needed groupware functionality

Think more broadly. The "clients" in a research setting may be
automated, home-brewed, non-Microsoft, or legacy data collection tools
that don't speak DAV, MAPI, or LDAP. Think about scenarios of data
collection by field instruments that are e-mailing data via cell phones
or packet radio, with automated pickup and parsing of the messages by
software written by a scientist who is not a programming whiz but gets
the job done with Unix tools he learned as a grad student 15-20 years
ago, running on his office machine (Mac or not). Likewise, this system
may need to send messages (via SMTP) to the field instrument to adjust
sampling frequency, position, or what have you. POP, IMAP, and SMTP are
long standing, well understood, and widely supported by most messaging
tools and programming libraries, and researchers may need to use them to
accomplish their projects within their resource constraints.

If this is odd, so be it, and perhaps I am championing an unusually rare
case. But at the institution of my employ, this kind of research
activity is commonplace, and our IT group can't pretend to predict every
potential scenario, or offer programming help to every research group to
implement a MAPI/DAV (or other newer protocol) interface to their tools.
Their primary focus is to offer the most interoperable infrastructure
possible. The sysadmin effort to enable these protocols (POP et al.) on
Exchange is negligible, and not doing so artificially limits the
capability of the messaging infrastructure to accommodate potential use
cases. If Exchange is the messaging infrastructure platform selected by
a research institution (for whatever reasons, including the groupware
features you've focused on), it ought to have its universal messaging
hub features turned on.

- Todd

On 10/26/06 15:14, "Todd Ruston" <toddhackneyponies.com> wrote:

>> You have a very odd idea about Exchange. You can have Exchange
>> talk to the outside world without needing POP/IMAP/SMTP to the
>> clients. In fact, I'm doing this today. We don't expose any of
>> those three to our clients. It's all DAV/MAPI/LDAP. Connectivity
>> is achieved, with needed groupware functionality
>
> Think more broadly. The "clients" in a research setting may be
> automated, home-brewed, non-Microsoft, or legacy data collection tools
> that don't speak DAV, MAPI, or LDAP. Think about scenarios of data
> collection by field instruments that are e-mailing data via cell phones
> or packet radio, with automated pickup and parsing of the messages by
> software written by a scientist who is not a programming whiz but gets
> the job done with Unix tools he learned as a grad student 15-20 years
> ago, running on his office machine (Mac or not). Likewise, this system
> may need to send messages (via SMTP) to the field instrument to adjust
> sampling frequency, position, or what have you. POP, IMAP, and SMTP are
> long standing, well understood, and widely supported by most messaging
> tools and programming libraries, and researchers may need to use them to
> accomplish their projects within their resource constraints.

POP, IMAP and SMTP have nothing to do with email leaving the server out into
the internet. That's MTA to MTA communication, and Exchange does that
nicely, REGARDLESS of what your MUA to MTA communication is. Your field
instrument scenario is MTA to MTA communication, and is going to work with
Exchange REGARDLESS of how the MUA talks to it. As well, the rest of your
scenarios are not dependent on the MUA to MTA connection, but rather what's
happening on the computer running the MUA. That's a completely separate
issue.

Again, server to server, (MTA to MTA) is NOT the same as client to server,
(MUA to MTA). Really.
--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 10/27/06 at 6:04 PM, John C. Welch <jwelchbynkii.com> wrote:

> Again, server to server, (MTA to MTA) is NOT the same as client to
> server, (MUA to MTA). Really.

Yes John, I understand that. I must have confused you with too much
information about the source of the data messages (the field
instruments). The key part is the software that is picking up the data
messages from mailboxes (software acting as MUA's directly, POPing the
messages from Exchange). Likewise, outbound communication to <insert
science asset here> from a homegrown experiment management tool using
SMTP does need a smart mailer to route the messages. If Exchange is the
only mail infrastructure, it needs to accept SMTP from clients to
support this.

I'm sorry my description isn't fitting your world view, but that
actually helps demonstrate my point. It is nigh impossible for any
individual to fully envision all the potential activities a diversified
scientific research organization's scientists may engage in, and what
they may need in terms of infrastructure to accomplish their goals.

I suppose it comes down to a decision of where to place the burden of
this issue. Does the institution decide to not allow well known and
widely supported MUA<->MTA protocols such as POP/SMTP (and therefore
require researchers that use custom POP/SMTP based tools to learn to
code for MAPI/DAV/etc. and rework those tools to conform to this edict),
or does the institution ask the I.T. folks to check the boxes turning on
POP/IMAP/etc. on Exchange and save the science folks that work? (A
similar cost/benefit assessment can be made for simple mail client
choices and related training/conversion issues.)

The final choice will depend on institutional priorities.

- Todd

On 10/28/06 11:51, "Todd Ruston" <toddhackneyponies.com> wrote:

> Yes John, I understand that. I must have confused you with too much
> information about the source of the data messages (the field
> instruments). The key part is the software that is picking up the data
> messages from mailboxes (software acting as MUA's directly, POPing the
> messages from Exchange). Likewise, outbound communication to <insert
> science asset here> from a homegrown experiment management tool using
> SMTP does need a smart mailer to route the messages. If Exchange is the
> only mail infrastructure, it needs to accept SMTP from clients to
> support this.

No, it needs to accept email from clients. That does not require SMTP. It
requires a client that can communicate with Exchange in a way that Exchange
can understand. It may be SMTP, it may not be. But you've yet to show
anything that would absolutely FORCE smtp. If you need a programmable mail
client, Outlook and Entourage are quite capable there. If you need a mail
client that hasn't changed in twenty years, well, that's not Exchanges
problem. Maybe every couple of decades you should review your procedures.

>
> I'm sorry my description isn't fitting your world view, but that
> actually helps demonstrate my point. It is nigh impossible for any
> individual to fully envision all the potential activities a diversified
> scientific research organization's scientists may engage in, and what
> they may need in terms of infrastructure to accomplish their goals.

Considering I've worked for a couple, I've a better clue than most. However,
again, there's little you've come up with that forces SMTP.

>
> I suppose it comes down to a decision of where to place the burden of
> this issue. Does the institution decide to not allow well known and
> widely supported MUA<->MTA protocols such as POP/SMTP (and therefore
> require researchers that use custom POP/SMTP based tools to learn to
> code for MAPI/DAV/etc. and rework those tools to conform to this edict),
> or does the institution ask the I.T. folks to check the boxes turning on
> POP/IMAP/etc. on Exchange and save the science folks that work? (A
> similar cost/benefit assessment can be made for simple mail client
> choices and related training/conversion issues.)

What tools? Dude, you should really take a look at just how programmable
modern mail clients, even (shudder) exchange clients are. In fact, they
offer you quite a bit over the basic mail tools that existed twenty years
ago. Should an entire institution live two decades ago because a minority of
users refuse to consider change?

Whose budget pays for the extra time needed to maintain security on extra
protocols. My experience has been that the minority needing special
attention *rarely* is willing to part with the budget required to maintain
it.

>
> The final choice will depend on institutional priorities.

No, it will depend on who has the most pull and yells the loudest.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

>POP, IMAP and SMTP have nothing to do with email leaving the server out into
>the internet. That's MTA to MTA communication,

Which uses.... SMTP!

C'mon John, use your brain. You owe me a beer at expo for that slipup! =P


--

Chuck Goolsbee V.P. Technical Operations
_________________________________________________________________
digital.forest Phone: +1-877-720-0483, x2001
where Internet solutions grow Int'l: +1-206-838-1630
*** celebrating twelve years of service 7/12/1994 - 7/12/2006 ***
12101 Tukwila International Blvd Fax: +1-206-838-3749
Suite 410 http://www.forest.net
Seattle, WA 98168 email: cgforest.net

On 10/30/06 21:50, "chuck goolsbee" <chucklistforest.net> wrote:

>> POP, IMAP and SMTP have nothing to do with email leaving the server out into
>> the internet. That's MTA to MTA communication,
>
> Which uses.... SMTP!
>
> C'mon John, use your brain. You owe me a beer at expo for that slipup! =P

Heh...nope. I already pointed that out. Which is why griping about how
Exchange communicates with clients as some way of saying it can't send email
on the intarweb unless you enable pop/imap/smtp to the clients is silly.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 10/30/06 at 7:46 PM, John C. Welch <jwelchbynkii.com> wrote:

> Considering I've worked for a couple, I've a better clue than
> most. However, again, there's little you've come up with that
> forces SMTP.

Likewise, I'm not seeing a reason that forces denying SMTP et al.

> What tools?

Perl & Python POP/SMTP libraries, to name a couple. There are many.

> In fact, they offer you quite a bit over the basic mail tools
> that existed twenty years ago. Should an entire institution live
> two decades ago because a minority of users refuse to consider
> change?

No, it shouldn't. But I'm not advocating making IMAP/POP/SMTP the only
protocols Exchange supports in such a scenario.

> Whose budget pays for the extra time needed to maintain security
> on extra protocols. My experience has been that the minority
> needing special attention *rarely* is willing to part with the
> budget required to maintain it.

That's a key issue, and that incremental cost will likely vary from
institution to institution. If the cost to support SMTP et al. is
outweighed by the benefit of enabling them, that suggests doing so.

> > The final choice will depend on institutional priorities.
>
> No, it will depend on who has the most pull and yells the loudest.

LOL! Now there's something we agree on. :-)

- Todd
--
Computer haiku:
A file that big?
It might be very useful.
But now it is gone.

On 11/1/06 14:19, "Todd Ruston" <toddhackneyponies.com> wrote:

> Likewise, I'm not seeing a reason that forces denying SMTP et al.
>
>> What tools?
>
> Perl & Python POP/SMTP libraries, to name a couple. There are many.

I'm real sure that neither Perl nor Python lock you into POP/IMAP/SMTP.

>> In fact, they offer you quite a bit over the basic mail tools
>> that existed twenty years ago. Should an entire institution live
>> two decades ago because a minority of users refuse to consider
>> change?
>
> No, it shouldn't. But I'm not advocating making IMAP/POP/SMTP the only
> protocols Exchange supports in such a scenario.

No, but you are advocating creating a significant increase in the
maintenance and upkeep for an Exchange server without any real need.

The tools you talk about have the ability to act as an MTA, not just and
MUA. At that point, they can talk to Exchange without caring what the actual
MUA protocol is, and that's really a better scenario when you think about
it. It lets you be far more flexible in your implementation.

>> Whose budget pays for the extra time needed to maintain security
>> on extra protocols. My experience has been that the minority
>> needing special attention *rarely* is willing to part with the
>> budget required to maintain it.
>
> That's a key issue, and that incremental cost will likely vary from
> institution to institution. If the cost to support SMTP et al. is
> outweighed by the benefit of enabling them, that suggests doing so.

Again, SMTP isn't just for clients. Have your tools work as and MTA, and you
bypass the problem entirely.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com