If supporting one port is y hours of time and headache, then two ports is closer to y*2 than y (some might argue y-squared). 587 has some validity for providers of roaming services, but who else? Why not implement 587 behavior (auth from the outside coming in, and accept all where destin == this system) on 25 and leave the rest alone? -Jim P. On Thu, 2005-02-24 at 16:51 -0500, andrew2@one.net wrote:
owner-nanog@merit.edu wrote:
On Thu, 24 Feb 2005 16:08:42 EST, Nils Ketelsen said:
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587?
Give a good reason. That is still the missing part.
If you're a roaming user from that provider, and you're at some other site that blocks or hijacks port 25, you can still send mail by tossing it to your main provider's 587. If that's not a good enough reason to motivate the provider to support it, nothing will (except maybe when the users show up en masse with pitchforks and other implements of destruction...)
There seem to be many who feel there is no overwhelming reason to support 587. I can certainly see that point of view, but I guess my question is what reasons do those of you with that viewpoint have *not* to implement it? I just don't see the harm in either configuring your MTA to listen on an extra port, or just forward port 587 to 25 at the network level. Other than a few man-hours for implementation what are the added costs/risks that make you so reluctant? What am I missing?
Andrew