Re: non-alpha HELO
LuKreme wrote: Authentication is another matter, but as I recall, that is outside postfix purview and I need to go dink with cyrus-sasl-saslauthd for that. Mar 15 12:54:40 mail submit/smtpd[7403]: Anonymous TLS connection established from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51]: TLSv1 with cipher AES128-SHA (128/128 bits) Mar 15 12:54:41 mail submit/smtpd[7403]: warning: SASL authentication failure: no user in db And I'm also seeing successful TLS connections with other mailservers. Yes, it appears your TLS is working correctly. You may start a new thread here about your AUTH failures. Include "postconf -n" and output from the saslfinger tool. -- Noel Jones
Re: non-alpha HELO
On 14-Mar-2009, at 22:53, Noel Jones wrote: But you should really be testing with telnet and openssl s_client before you start testing with a MUA. Yep. Like I said this was just a "let's see what we get in the logs" little test. Mucking about some more with it, TLS at least is working now. Authentication is another matter, but as I recall, that is outside postfix purview and I need to go dink with cyrus-sasl-saslauthd for that. Mar 15 12:54:40 mail submit/smtpd[7403]: Anonymous TLS connection established from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51]: TLSv1 with cipher AES128-SHA (128/128 bits) Mar 15 12:54:41 mail submit/smtpd[7403]: warning: SASL authentication failure: no user in db And I'm also seeing successful TLS connections with other mailservers. So, postfix config is done. -- The Steve is seen, rightly or wrongly, as the visionary, the leader, the savant. Bill is the Boswell to The Steve's Johnson, but lacking Boswell's wit, charm, and dynamic personality.
Re: non-alpha HELO
LuKreme wrote: On 14-Mar-2009, at 13:02, mouss wrote: test the connection manually: $ telnet yourserv 587 ... EHLO yourclienthostname ... QUIT Right, I do know that. Sorry if I wasn't clear, my only point was that what was actaully logged under submit was not useful and expressing disappointment that there wasn't something like "TLS failed" "AUTH failed" or "Hey, dumbass, you forgot to create a valid cert". Something along those lines. The logging is the same. You can increase logging with debug_peer_list, but it's not clear that will help... Setting smtpd_tls_log_level = 1 will show if the client established TLS. But you should really be testing with telnet and openssl s_client before you start testing with a MUA. Turn off TLS and test AUTH with a telnet session. Use openssl s_client just to test TLS connectivity - if you get the 220 greeting banner TLS is working correctly. The instructions at http://www.postfix.org/TLS_README.html#quick-start are about the simplest for setting up a self-signed certificate that will work with postfix. Follow them carefully. You can distribute the cacert.pem root public key so others can verify your cert, but that isn't usually necessary; they can just click the "trust this server" or whatever in their mail client after the initial "untrusted certificate" message. -- Noel Jones
Re: non-alpha HELO
On 14-Mar-2009, at 13:02, mouss wrote: test the connection manually: $ telnet yourserv 587 ... EHLO yourclienthostname ... QUIT Right, I do know that. Sorry if I wasn't clear, my only point was that what was actaully logged under submit was not useful and expressing disappointment that there wasn't something like "TLS failed" "AUTH failed" or "Hey, dumbass, you forgot to create a valid cert". Something along those lines. Appears so. Its default setting is "Use default ports (25, 465, 587)" this would be only at setup time (when you add an account...). No, that is the setting, unless you change it, for the outgoing server (outgoing servers in Mail.app are separate from accounts), but it does appear to actaully default to the first one that succeeds, and doesn't like if if taht port (25) stops working. or maybe if connection to the configured port doesn't work anymore. otherwise, it would be a nuisance. Yes, it can be a nuisance... Oh, and someone asked what ISPs would ever block p587? I had a user who was unable to access the mail server from Darfur until I opened up a port above 1024 to SMTP. He was able to CHECK mail, but not send on either 25 or 587. I think I setup 2025 for him and everything worked fine, albeit at glacial speed. Then he discovered Squirrelmail and it's not been a problem since. It was almost like the Sudan had a single 128K DSL connection to the rest of the world -- Incredible! One of the worst performances of my career and they never doubted it for a second.
Re: non-alpha HELO
LuKreme a écrit : > On 13-Mar-2009, at 14:51, Jorey Bump wrote: >> submission inet n - n - - smtpd >> -o smtpd_tls_security_level=encrypt >> -o smtpd_sasl_auth_enable=yes >> -o smtpd_client_restrictions=permit_sasl_authenticated,reject > > Yeah, once I get TLS setup. I am running 2.5.6. I did change the > submission port to > >> o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes >> -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject >> -o syslog_name=postfix/submit > > Just to see what would get logged, I went ahead and tried to use this. > I knew it wouldn't work, but I was hoping for useful error messages. I > got this: > > submit/smtpd[32686]: connect from > c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] > submit/smtpd[32686]: lost connection after EHLO from > c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] > submit/smtpd[32686]: disconnect from > c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] > submit/smtpd[32686]: connect from > c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] > submit/smtpd[32686]: timeout after UNKNOWN from > c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] > submit/smtpd[32686]: disconnect from > c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] > > Not that useful... > test the connection manually: $ telnet yourserv 587 ... EHLO yourclienthostname ... QUIT then check the response of EHLO. if it contains STARTTLS but not AUTH, then it means a client must use TLS before it can authenticate. if your MUA is configured to do AUTH but not TLS, this may be a problem. >>> I wish more clients were like Mail.app in this respect, its default is >>> to try 25, 465, and 587, so if all my users were using Mail.app, I could >>> just switch things and it would 'do the right thing'. >> >> Is that true after initial configuration? It would be odd for a client >> to start probing alternate ports outside of a configuration wizard. > > Appears so. Its default setting is "Use default ports (25, 465, 587)" > this would be only at setup time (when you add an account...). or maybe if connection to the configured port doesn't work anymore. otherwise, it would be a nuisance.
Re: non-alpha HELO
On 14-Mar-2009, at 11:05, Jorey Bump wrote: LuKreme wrote, at 03/14/2009 12:19 PM: submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: lost connection after EHLO from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: timeout after UNKNOWN from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] Not that useful... Actually, the specially designated syslog_name can be very useful, especially for troubleshooting & migration. To see who's using the new port, use something like this: grep sasl /var/log/maillog | grep submit To see who's not: grep sasl /var/log/maillog | grep -v submit Oh no, THAT will be useful. I mean tthe specific errors in this case didn't give any clue as to what in my current setup was missing. -- Rule #5: Get Kirsten Dunst Wet
Re: non-alpha HELO
On Mar 14, 2009, at 12:20 PM, LuKreme wrote: On 13-Mar-2009, at 14:51, Jorey Bump wrote: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject Yeah, once I get TLS setup. I am running 2.5.6. I did change the submission port to o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit Just to see what would get logged, I went ahead and tried to use this. I knew it wouldn't work, but I was hoping for useful error messages. I got this: submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] If you really set syslog_name=postfix/submit, the above log entry would look more like: postfix/submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] Not that useful... How do you define 'useful' in this context? What were you expecting to see? I wish more clients were like Mail.app in this respect, its default is to try 25, 465, and 587, so if all my users were using Mail.app, I could just switch things and it would 'do the right thing'. Is that true after initial configuration? It would be odd for a client to start probing alternate ports outside of a configuration wizard. Appears so. Its default setting is "Use default ports (25, 465, 587)" In my experience this feature is unreliable; once Mail.app succeeds in relaying via one of those ports (25, for example), I don't see that it *always* polls 465 and 587 if SASL fails on 25. But this is off-topic anyway. :) -- Sahil Tandon
Re: non-alpha HELO
LuKreme wrote, at 03/14/2009 12:19 PM: > On 13-Mar-2009, at 14:51, Jorey Bump wrote: >> submission inet n - n - - smtpd >> -o smtpd_tls_security_level=encrypt >> -o smtpd_sasl_auth_enable=yes >> -o smtpd_client_restrictions=permit_sasl_authenticated,reject > > Yeah, once I get TLS setup. I am running 2.5.6. I did change the > submission port to > >> o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes >> -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject >> -o syslog_name=postfix/submit > > Just to see what would get logged, I went ahead and tried to use this. > I knew it wouldn't work, but I was hoping for useful error messages. I > got this: > > submit/smtpd[32686]: connect from > c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] > submit/smtpd[32686]: lost connection after EHLO from > c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] > submit/smtpd[32686]: disconnect from > c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] > submit/smtpd[32686]: connect from > c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] > submit/smtpd[32686]: timeout after UNKNOWN from > c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] > submit/smtpd[32686]: disconnect from > c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] > > Not that useful... Actually, the specially designated syslog_name can be very useful, especially for troubleshooting & migration. To see who's using the new port, use something like this: grep sasl /var/log/maillog | grep submit To see who's not: grep sasl /var/log/maillog | grep -v submit
Re: non-alpha HELO
On 13-Mar-2009, at 14:51, Jorey Bump wrote: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject Yeah, once I get TLS setup. I am running 2.5.6. I did change the submission port to o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit Just to see what would get logged, I went ahead and tried to use this. I knew it wouldn't work, but I was hoping for useful error messages. I got this: submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: lost connection after EHLO from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: timeout after UNKNOWN from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] Not that useful... I wish more clients were like Mail.app in this respect, its default is to try 25, 465, and 587, so if all my users were using Mail.app, I could just switch things and it would 'do the right thing'. Is that true after initial configuration? It would be odd for a client to start probing alternate ports outside of a configuration wizard. Appears so. Its default setting is "Use default ports (25, 465, 587)" -- There is a tragic flaw in our precious Constitution, and I don t know what can be done to fix it. This is it: Only nut cases want to be president.
Re: non-alpha HELO
On 13-Mar-2009, at 14:51, Jorey Bump wrote: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject Yeah, once I get TLS setup. I am running 2.5.6. I did change the submission port to o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit Just to see what would get logged, I went ahead and tried to use this. I knew it wouldn't work, but I was hoping for useful error messages. I got this: submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: lost connection after EHLO from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: timeout after UNKNOWN from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] Not that useful... I wish more clients were like Mail.app in this respect, its default is to try 25, 465, and 587, so if all my users were using Mail.app, I could just switch things and it would 'do the right thing'. Is that true after initial configuration? It would be odd for a client to start probing alternate ports outside of a configuration wizard. Appears so. Its default setting is "Use default ports (25, 465, 587)" -- There is a tragic flaw in our precious Constitution, and I don t know what can be done to fix it. This is it: Only nut cases want to be president.
Re: non-alpha HELO
Sahil Tandon wrote, at 03/13/2009 08:36 PM: > Jorey Bump wrote: >> LuKreme wrote, at 03/13/2009 04:26 PM: >>> On 13-Mar-2009, at 10:49, Bill Cole wrote: >>> If you have a good port 587 config in master.cf, you may need no changes there. My submission entry for a server that accepts no port 25 submission from outside the LAN is: submissioninetn-n--smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit -o smtpd_milters= (If your main.cf doesn't define smtpd_milters, the last line is unnecessary) >>> That's nice to see. My master.cf is quite old, and the submission port >>> info is... lemme look >>> >>> Oh, my >>> >>> 587 inet n - n - - smtpd >>> >>> >>> That's it. Lemme at least change that. >> >> Here's an example for a recent Postfix: >> >> submission inet n - n - - smtpd >> -o smtpd_tls_security_level=encrypt >> -o smtpd_sasl_auth_enable=yes >> -o smtpd_client_restrictions=permit_sasl_authenticated,reject > > One point of clarification for others who may get tripped up by the > subtle difference between these two examples. In Bill's version, > smtpd_recipient_restrictions contains permit_sasl_authenticated, whereas > the latter is set in Jorey's smtpd_client_restrictions. I believe one > needs to permit_sasl in recipient_restrictions; at least in the context > of this thread, where it is suggested that "you remove permit_mynetworks > & permit_sasl_authenticated from your smtpd_*_restrictions in main.cf". > Otherwise SASL authenticated clients will be unable to relay (probably > blocked by reject_unauth_destination at RCPT TO). Quite right. My example is from a site that still has permit_sasl_authenticated in smtpd_recipient_restrictions in main.cf. If you remove that, you need to adjust the submission service accordingly: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING This is also true of smtps (port 465) if you need to support older clients: smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING It may also be unnecessary or undesirable to remove permit_mynetworks from smtpd_*_restrictions in main.cf, depending on how you're using it.
Re: non-alpha HELO
Jorey Bump wrote: LuKreme wrote, at 03/13/2009 04:26 PM: On 13-Mar-2009, at 10:49, Bill Cole wrote: If you have a good port 587 config in master.cf, you may need no changes there. My submission entry for a server that accepts no port 25 submission from outside the LAN is: submissioninetn-n--smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit -o smtpd_milters= (If your main.cf doesn't define smtpd_milters, the last line is unnecessary) That's nice to see. My master.cf is quite old, and the submission port info is... lemme look Oh, my 587 inet n - n - - smtpd That's it. Lemme at least change that. Here's an example for a recent Postfix: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject One point of clarification for others who may get tripped up by the subtle difference between these two examples. In Bill's version, smtpd_recipient_restrictions contains permit_sasl_authenticated, whereas the latter is set in Jorey's smtpd_client_restrictions. I believe one needs to permit_sasl in recipient_restrictions; at least in the context of this thread, where it is suggested that "you remove permit_mynetworks & permit_sasl_authenticated from your smtpd_*_restrictions in main.cf". Otherwise SASL authenticated clients will be unable to relay (probably blocked by reject_unauth_destination at RCPT TO). -- Sahil Tandon
Re: non-alpha HELO
LuKreme a écrit :
> I have the following helo restriction in a pcre file:
>
> !/[[:alpha:]]/REJECT helo non-alpha helo not allowed
>
> I ran it with WARN for quite a while and didn't see any legitimate
> messages that hit it, so I moved it to REJECT. However, my mailserver
> is starting to see more traffic now than it used to, and more varied. I
> had to remove my CIDR blocks on china and south korea, for example.
> True, most of that mail still hits zen or fails to pass greylisting, but
> where there used to be -zero- legit mail from those countries, now
> there's a little.
>
> So I thought I'd see if anyone else thought that a helo in the form
> [12.34.56.789] SHOULD be allowed. I mean, as far as I recall, this is
> still technically allowed, right?
>
a literal IP helo is allowed by the RFC. but:
- I have never seen this in legitimate inbound mail since very long
- the argument in the rfc says that literal ip is used when the clinet
can't get its name. in the case of inbound mail, this would mean that
the client couldn't get its name yet it could lookup your MX. ahem. a
long time ago, MTAs that used different routing paths tried this, but
it's no better than defining a domain name instead.
if you go this road, then you should also use
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
then you only need a check_helo_access that does:
/^[/REJECT literal IP helo not accepted here
if you think this is too aggressive, then
/^[/reject_unknown_client
is more "politically correct" (nobody can use the RFCs against you).
you can play on both sides with
/^[/reject_unknown_client, REJECT
> I've thought about simply going back to warn, but when I first
> implemented this check it hit a few dozen a day, and now it hits many
> hundreds, so searching for legitimate messages among the warnings will
> be considerably harder.
>
> My complete helo_checks.pcre looks like this:
> !/[[:alpha:]]/REJECT helo non-alpha helo not allowed
> to talk to me
> !/\.[[:alpha:]]{2,}$/ REJECT helo no TLD, invalid hostname
>
it looks like you're reinventing checks that are already available in
postfix. see above.
> # Block localhost (unusual in HELO)
> /^localhost(\.localdomain)?$/ REJECT helo Unacceptable hostname in helo
> /^unknown$/ REJECT helo No unknown hostnames
> /^75\.148\.117\.93/ REJECT helo Don't Spoof My IP
> /^\[75\.148\.117\.93\]/ REJECT helo Don't Spoof My IP
> /^covisp\.net$/ REJECT helo Don't spoof my hostname
> /^southgaylord\.com$/ REJECT helo Don't spoof my hostname
> /^kreme\.com$/ REJECT helo Don't spoof my hostname
> /^example\.com$/ REJECT helo Don't spoof my hostname
> /^example\.net$/ REJECT helo Don't spoof my hostname
better use a hash for the above. I personally use mysql.
> /\.(dsl|adsl|pool|dynamic|user|hsd|dyn|dial)/ REJECT helo Dynamic .
> addresses not allowed
> /^(dsl|adsl|pool|dynamic|user|hsd|dyn|dial)/ REJECT helo Dynamic ^
> addresses not allowed
>
Re: non-alpha HELO
LuKreme wrote, at 03/13/2009 04:26 PM: > On 13-Mar-2009, at 10:49, Bill Cole wrote: > >> If you have a good port 587 config in master.cf, you may need no >> changes there. My submission entry for a server that accepts no port >> 25 submission from outside the LAN is: >> >> submissioninetn-n--smtpd >> -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes >> -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject >> -o syslog_name=postfix/submit >> -o smtpd_milters= >> >> (If your main.cf doesn't define smtpd_milters, the last line is >> unnecessary) > > That's nice to see. My master.cf is quite old, and the submission port > info is... lemme look > > Oh, my > > 587 inet n - n - - smtpd > > > That's it. Lemme at least change that. Here's an example for a recent Postfix: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING > I wish more clients were like Mail.app in this respect, its default is > to try 25, 465, and 587, so if all my users were using Mail.app, I could > just switch things and it would 'do the right thing'. Is that true after initial configuration? It would be odd for a client to start probing alternate ports outside of a configuration wizard.
Re: non-alpha HELO
On 13-Mar-2009, at 10:49, Bill Cole wrote: Hi Bill! Postfix is a little more complicated than SIMS, isn't it :) If you have a good port 587 config in master.cf, you may need no changes there. My submission entry for a server that accepts no port 25 submission from outside the LAN is: submission inetn - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit -o smtpd_milters= (If your main.cf doesn't define smtpd_milters, the last line is unnecessary) That's nice to see. My master.cf is quite old, and the submission port info is... lemme look Oh, my 587 inet n - n - - smtpd That's it. Lemme at least change that. Forcing users into submission (or however you want to phrase that...) is really a main.cf issue, and depending on your network and users it may be more a matter of encouragement than force. Any measure you have in place in main.cf smtpd_*_restrictions entries solely in order to permit your users' initial submissions should be removed from there and instead be in the smtpd_*_restrictions definitions in the submission entry in master.cf. I wish more clients were like Mail.app in this respect, its default is to try 25, 465, and 587, so if all my users were using Mail.app, I could just switch things and it would 'do the right thing'. The generalized rule is that main.cf defines a baseline set of definitions, while the -o entries in the master.cf entry for a service replaces definitions as needed. For example, I define my smtpd_sasl_* settings in main.cf because that way they don't clutter master.cf, and without permit_sasl_authenticated in main.cf, those settings are operationally irrelevant to the port 25 smtpd. -- Charlie don't surf!
Re: non-alpha HELO
LuKreme wrote, On 3/13/09 11:53 AM: On 13-Mar-2009, at 09:04, Jorey Bump wrote: For the people still supporting the antiquated model of accepting mail submission via SMTP rather than a proper port 587 daemon, it is important to make allowances for the fact that MUA's frequently have no better choice for their HELO argument than an IP literal, and sometimes even that is pretty lousy (i.e. an ephemeral RFC1918 private IP) MUA HELOs are problematic in many ways. But you're absolutely right, this is best handled by delaying this sort of check_helo_access until smtpd_recipient_restrictions, after permit_mynetworks & permit_sasl_authenticated, if you support submission on SMTP port 25 on an MX server. OK, this piqued my interest. I have 587 setup, and I also have a couple of alternate ports in the 1025+ range to deal with any users unlucky enough to be behind draconian ISPs, but I do still accept mail on port 25. In fact, I wasn't even aware that you could force users to use the submission port. Where's the read me on configuring master.cf for this, as I think it might be worth looking at. If you have a good port 587 config in master.cf, you may need no changes there. My submission entry for a server that accepts no port 25 submission from outside the LAN is: submission inetn - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit -o smtpd_milters= (If your main.cf doesn't define smtpd_milters, the last line is unnecessary) Forcing users into submission (or however you want to phrase that...) is really a main.cf issue, and depending on your network and users it may be more a matter of encouragement than force. Any measure you have in place in main.cf smtpd_*_restrictions entries solely in order to permit your users' initial submissions should be removed from there and instead be in the smtpd_*_restrictions definitions in the submission entry in master.cf. The generalized rule is that main.cf defines a baseline set of definitions, while the -o entries in the master.cf entry for a service replaces definitions as needed. For example, I define my smtpd_sasl_* settings in main.cf because that way they don't clutter master.cf, and without permit_sasl_authenticated in main.cf, those settings are operationally irrelevant to the port 25 smtpd.
Re: non-alpha HELO
LuKreme wrote: On 13-Mar-2009, at 09:04, Jorey Bump wrote: For the people still supporting the antiquated model of accepting mail submission via SMTP rather than a proper port 587 daemon, it is important to make allowances for the fact that MUA's frequently have no better choice for their HELO argument than an IP literal, and sometimes even that is pretty lousy (i.e. an ephemeral RFC1918 private IP) MUA HELOs are problematic in many ways. But you're absolutely right, this is best handled by delaying this sort of check_helo_access until smtpd_recipient_restrictions, after permit_mynetworks & permit_sasl_authenticated, if you support submission on SMTP port 25 on an MX server. OK, this piqued my interest. I have 587 setup, and I also have a couple of alternate ports in the 1025+ range to deal with any users unlucky enough to be behind draconian ISPs, but I do still accept mail on port 25. In fact, I wasn't even aware that you could force users to use the submission port. You can't "prevent" them from connecting to port 25, but you can make it less useful by not allowing them to relay. Or you can be really draconian and reject your own domain as sender from unauthenticated/unauthorized clients. It's then usually enough to point them to a web page with instructions. usually... I don't know if I would go so far as to say this is a recommended setup, but it since it cleanly separates your traffic it makes applying separate policies (ie. spam/virus controls, DKIM, logs, whatever) to authenticated users easier. Where's the read me on configuring master.cf for this, as I think it might be worth looking at. No specific readme on this, just configure the existing restrictions to do what you want. Maybe this helps a little bit: http://www.postfix.org/master.5.html Just remove permit_sasl_authenticated from the port 25 listener (and maybe restrict mynetworks to only clients that can't authenticate). This is usually done by removing permit_sasl_authenticated from main.cf and adding -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject (and maybe other options such as syslog_name) to the master.cf submission listener. -- Noel Jones
Re: non-alpha HELO
LuKreme wrote, at 03/13/2009 11:53 AM: > On 13-Mar-2009, at 09:04, Jorey Bump wrote: >>> For the people still supporting the antiquated model of accepting mail >>> submission via SMTP rather than a proper port 587 daemon, it is >>> important to make allowances for the fact that MUA's frequently have no >>> better choice for their HELO argument than an IP literal, and sometimes >>> even that is pretty lousy (i.e. an ephemeral RFC1918 private IP) >> >> MUA HELOs are problematic in many ways. But you're absolutely right, >> this is best handled by delaying this sort of check_helo_access until >> smtpd_recipient_restrictions, after permit_mynetworks & >> permit_sasl_authenticated, if you support submission on SMTP port 25 on >> an MX server. > > OK, this piqued my interest. I have 587 setup, and I also have a couple > of alternate ports in the 1025+ range to deal with any users unlucky > enough to be behind draconian ISPs, but I do still accept mail on port > 25. In fact, I wasn't even aware that you could force users to use the > submission port. > > Where's the read me on configuring master.cf for this, as I think it > might be worth looking at. Forcing users to submit mail to port 587 basically means dropping support for relaying to external domains on port 25. This poses less of a problem now than it did in the past, since nearly all modern clients support STARTTLS on alternate ports. Essentially, you remove permit_mynetworks & permit_sasl_authenticated from your smtpd_*_restrictions in main.cf, so they will no longer be exempt from the more strict checks (although a handful may still be able to send directly to the domains you handle). If you configure port 587 properly (the default in master.cf is usually fine), you can notify your users to switch. Then it's basically rinse, lather, repeat until you have a minority that need to be targeted individually. Once you've migrated users to your satisfaction, remove support from main.cf. BTW, what ISPs are blocking port 587? This is disturbingly wrong.
Re: non-alpha HELO
On 13-Mar-2009, at 09:04, Jorey Bump wrote: For the people still supporting the antiquated model of accepting mail submission via SMTP rather than a proper port 587 daemon, it is important to make allowances for the fact that MUA's frequently have no better choice for their HELO argument than an IP literal, and sometimes even that is pretty lousy (i.e. an ephemeral RFC1918 private IP) MUA HELOs are problematic in many ways. But you're absolutely right, this is best handled by delaying this sort of check_helo_access until smtpd_recipient_restrictions, after permit_mynetworks & permit_sasl_authenticated, if you support submission on SMTP port 25 on an MX server. OK, this piqued my interest. I have 587 setup, and I also have a couple of alternate ports in the 1025+ range to deal with any users unlucky enough to be behind draconian ISPs, but I do still accept mail on port 25. In fact, I wasn't even aware that you could force users to use the submission port. Where's the read me on configuring master.cf for this, as I think it might be worth looking at. -- There is something to be said for grace and respect but humour alway helps - Toby Morris
Re: non-alpha HELO
Bill Cole wrote, at 03/13/2009 10:23 AM: > Jorey Bump wrote, On 3/13/09 8:51 AM: >> LuKreme wrote, at 03/13/2009 07:22 AM: >> >>> So I thought I'd see if anyone else thought that a helo in the form >>> [12.34.56.789] SHOULD be allowed. I mean, as far as I recall, this is >>> still technically allowed, right? >> >> A bracketed IP address is valid in a HELO/EHLO, but is so rare in >> legitimate mail that it's still worth blocking. > > It should be noted that this is true only for mail transport, not mail > submission. > > For the people still supporting the antiquated model of accepting mail > submission via SMTP rather than a proper port 587 daemon, it is > important to make allowances for the fact that MUA's frequently have no > better choice for their HELO argument than an IP literal, and sometimes > even that is pretty lousy (i.e. an ephemeral RFC1918 private IP) MUA HELOs are problematic in many ways. But you're absolutely right, this is best handled by delaying this sort of check_helo_access until smtpd_recipient_restrictions, after permit_mynetworks & permit_sasl_authenticated, if you support submission on SMTP port 25 on an MX server.
Re: non-alpha HELO
Jorey Bump wrote, On 3/13/09 8:51 AM: LuKreme wrote, at 03/13/2009 07:22 AM: So I thought I'd see if anyone else thought that a helo in the form [12.34.56.789] SHOULD be allowed. I mean, as far as I recall, this is still technically allowed, right? A bracketed IP address is valid in a HELO/EHLO, but is so rare in legitimate mail that it's still worth blocking. It should be noted that this is true only for mail transport, not mail submission. For the people still supporting the antiquated model of accepting mail submission via SMTP rather than a proper port 587 daemon, it is important to make allowances for the fact that MUA's frequently have no better choice for their HELO argument than an IP literal, and sometimes even that is pretty lousy (i.e. an ephemeral RFC1918 private IP)
Re: non-alpha HELO
LuKreme wrote, at 03/13/2009 07:22 AM:
> So I thought I'd see if anyone else thought that a helo in the form
> [12.34.56.789] SHOULD be allowed. I mean, as far as I recall, this is
> still technically allowed, right?
A bracketed IP address is valid in a HELO/EHLO, but is so rare in
legitimate mail that it's still worth blocking. At one point, it was
being heavily abused, but not so much recently, probably because it's
such an easily implemented, low cost check. Here's a simple (although
inexact) variation:
/^\[[\d\.]*\]$/ REJECT IP literal in HELO not accepted here
I've implemented this on a site that handles a substantial amount of
international email (including China) without any reports of false
positives. Few, if any, legitimate servers will use a bracketed IP
address as a default, so even a poorly managed server is unlikely to
present one.
> I've thought about simply going back to warn, but when I first
> implemented this check it hit a few dozen a day, and now it hits many
> hundreds, so searching for legitimate messages among the warnings will
> be considerably harder.
It seems to be a safe and effective block unless you have a need for
bracketed IP addressess in you own network.
> My complete helo_checks.pcre looks like this:
> !/[[:alpha:]]/REJECT helo non-alpha helo not allowed
> to talk to me
> !/\.[[:alpha:]]{2,}$/ REJECT helo no TLD, invalid hostname
Either of these will give you enough of a clue to investigate any
problem report. If you want a more specific error message, look at the
example I provided. It includes the brackets, so will narrow down the
results if you're still concerned about monitoring.
