Re: ingress SMTP

[Michael Thomas <mike () mtcc com>]

matthew () sorbs net wrote:
> ----- Original Message -----
> From: Michael Thomas <mike () mtcc com>
> 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