----- 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. Regards, M
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
participants (2)
-
matthew＠sorbs.net -
Michael Thomas