Scott Haneda a écrit : > Hello. I am looking for clarification on RFC 5068 3.2 or any > related/updated/replaced RFC's. Outside of those, general best practice > ideas for moving forward would be appreciated. > > In regards to AUTH on ports 25 and 587, I was under the impression we > should be trying to migrate all clients to 587 for AUTH when in > submission. Does this also mean best practice would be to close AUTH on > 25 in order to more aggressively pursue this? > > What administrative plusses are there by doing so, if any. I would think > at the least, being able to disable 25 when under attack but still allow > users to sumbit would be one reason. Are there other benefits? >
if you use different machines, you can build postfix without SASL for use with inbound mail (25). (you can do that on a single machine, but it's much more work than you want). other than that, I don't see much benefits from disabling AUTH on 25. It is however good to migrate users to port 587. This way, you can have different configurations, which is easier to setup and maintain. to encourage users to move to 587, you can parse your logs and send them mail or whatever. you can start by providing incentives: features that are only available on 587, or limitations on port 25. note that it is good to only allow AUTH with STARTTLS. This protects passwords, which are the most widely used method for authentication. (BTW. cram-md5 is no more considered secure). > Is there another RFC that addresses this? I'm being told that disabling > AUTH on 25 would be in violation of the above RFC, though that is not > how I read it. I see no violation. AUTH is an optional extension, so can be enabled or disabled whenever you like it. > > In regards to opportunistic TLS, a quick telnet to 10 random MX's shows > STARTTLS after ehlo in about 50% of the cases. Disabled AUTH was in 90%. > Is there RFC for opportunistic TLS? > RFC 3207. > I'm running it now, but wonder what your experiences are. good. A side effect is that bots/ratware don't use TLS, so it could be used as a "hint" in spamassassin for instance (but spammers using real MTAs do use STARTTLS). > It's certainly > nice to see a 50% use rate, but I worry I may have delivery problems. don't require client certificates and it's ok. > Is > there general high reliability to this? Is there a way to disable > opportunistic TLS coming from specific senders if I do run into problems? > you can disable any ESMTP extension: http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps but there should be no reason to disable STARTTLS. > I am looking to "do the right thing" moving forward, and want to be sure > I am not implementing bad internal policy as a result of > misunderstanding RFC and best practices for moving forward. > > Thank you postfixers. > -- > Scott > Iphone says hello.
