On Oct 26, 2011, at 8:07 PM, Scott Howard wrote: > On Tue, Oct 25, 2011 at 2:49 AM, Owen DeLong <o...@delong.com> wrote: > Interesting... Most people I know run the same policy on 25 and 587 these > days... > > to-local-domain, no auth needed. > relay, auth needed. > > auth required == TLS required. > > Anything else on either port seems not best practice to me. > > RFC 5068 covers the best practice, and it's not what you've got above. > > Allowing unauthenticated inbound mail on port 587 defeats the entire purpose > of blocking port 25 - the front door is now closed to spammers, but you've > left the back door open! (Security through obscurity saves you here in that > spammers rarely use port 587 - yet). There isn't a single situations where > you should be expecting an unauthenticated inbound message on the > 'Submission' port (is, 587) > I still believe that that RFC is not correct. That blocking port 25 has too much collateral damage and is not a best practice.
As such, you are correct, I am not following RFC 5068. A certain amount of spam does hit my system, but, the hosts that deliver it are identified and blocked reasonably quickly. > As much as some ISPs still resist blocking port 25 for residential customers, > it does have a major impact on the volume of spam leaving your network. I've > worked with numerous ISPs as they have gone through the process of blocking > port 25 outbound. In every case the number of end-user complaints has been > low enough to be basically considered background noise, but the benefits have > been significant - including one ISP who removed not only themselves but also > their entire country from most of the 'Top 10 Spammers' list when they did it! > Blocking outbound port 25 would not reduce the already infinitesimal volume of spam leaving my network in the least. It would, however, block a lot of legitimate traffic. No thanks. Owen
