[EMAIL PROTECTED] wrote:
----- Original Message -----
From: Michael Thomas <[EMAIL PROTECTED]>
Date: Monday, September 8, 2008 7:31 am
Subject: Re: ingress SMTP
Would that it were so easy :) You also have the more daunting task
of hooking up your auth/aaa infrastructure with your MTA's, and all
of the care and feeding that entails.
As a matter of interest, it took but a couple of person hours to sort
this out at my last place of work, the largest time chunk in equation
was the compiling of TLS and the various SASL modules into Postfix. The
second from largest chunk of time was to get the script to get the
information required from the various other back end mail servers on
campus, including, but not limited to, Lotus Notes, M$ Exchange, and
Sun/iPlanet messaging server and it's LDAP server. The only down side
to the system was password changed took up to 15 minutes to get to the
mail systems as there was no direct connection between the external
gateways and the internal auth systems.
Of course the above doesn't take into account the several weeks of
political badgering and grandstanding that we endured to get the
faculties to actually accept that that was the way it was going to be.
They couldn't stand that there would only be incoming and outgoing mail
via the central gateway. Such is life at Universities.
I don't have any experience in ISP or university environments, but
when we were trying to get DKIM running at Cisco, we thought that
it would be a whole lot better idea to at least have an idea who was
sending the mail if we were going to sign it as being ours. This proved
to be quite a bit more problematic than we imagined, owing partly
to getting the responsible group to want to take ownership to make the
change (we worked closely with them, and they were receptive), but
much more of not knowing what we didn't know were we to require
smtp auth on submission or anywhere else for that matter.
This may speak more to the way that the big old franken-company's
parts were put together, but I suspect that it's probably a pretty
common problem for any sort of company that's, oh say, grown
fast, or has lots of things going on, or where one hand doesn't
know what the other is doing :)
This is pretty much similar to DKIM itself: it's pretty easy to get the
bulk of your traffic doing the right thing, but it's pretty hard to get
the outliers brought in line such that you can make a strong policy
statement in the case of DKIM (cf draft-ietf-dkim-asp) or rejecting
unauthenticated traffic via 587, or whatever else.
Mike
