STARTTLS offered on one port and not another

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

STARTTLS offered on one port and not another

Jim Wagner-4
I have a Unix box running Postfix to provide e-mail to employees at my
company.  I have everything set up and running with one small oddity
that I'm hopeful that somebody will be able to help me solve.

I can send e-mail using port 2225, whether I use TLS or not.  (I have
this configured as a backup SMTP port because many employees' home ISPs
block port 25 for any but their own mail server.  One of the reasons I
built this machine was so that we could respond to customers from home
without using personal accounts.)  If I send mail using port 25, I can
do so as long as I do NOT use TLS.  If I try, I get the following
message from Thunderbird when connecting to the SMTP server:

Sending of message failed.
An error occurred sending mail: Unable to connect to SMTP server
mail.****sales.com via STARTTLS since it doesn't offer STARTTLS in EHLO
response.
Please verify that your Mail/News account settings are correct and try
again.

The ONLY thing I changed between two tests is the port number that
Thunderbird uses for SMTP.  The PC that I'm using for this test is
Slackware 10.2.

I did see in the mailing list archives that some anti-virus software
will strip out the STARTTLS advertisement from an SMTP server response.  
(Yeah, *that*'s a great design... let's break a security feature because
it's not used by everyone. :roll eyes:)  However, I have no active virus
protection on my Slackware box.  I called my ISP and they aren't aware
of any virus software filtering traffic over the line.  I'd also think
that this would put an unacceptably tremendous drain on whatever system
was used - they concurred with this opinion.

Incidentally, I don't know if it's related or not, but I was unable to
get SquirrelMail working with TLS on either 25 or 2225.  I later read to
set it to use 127.0.0.1 as the outbound server, tried this, and all was
well.

This isn't a huge problem, but I would like to correct it if possible.  
I don't even know where to look any more; Postfix doesn't seem to have
anything in the way of port specific configuration outside of master.cf
and the firewall is obviously allowing the connection because I can send
mail if I don't use TLS.

I appreciate any advice.




I replaced part of my domain names with **** in these config files.  
Here is my machine configuration:

Hardware

AMD Athlon 2800+
1 gig of RAM
2 x 400 gig hard drives in a mirrored RAID
1 onboard NIC connected to the Internet via ADSL w/static IP
1 PCI NIC that connects to WiFi routers to allow the customers to use the
Internet via NAT
1 PCI NIC hard-wired directly to my office for administration



I have the following software packages installed from the ports system to
provide the related services:

        FreeBSD 7.0                Operating system
        ppp                        Used to connect to ADSL service
        pf                        Firewall to keep out everybody else
        BIND                        DNS server for name lookups
        Apache 2.2                Web server for SquirrelMail & web pages
        webmin                        Administration when I feel lazy
        telnet                        Administration when I want full
control
        postfix                        MTA
        courier-imap                POP3 / IMAP access for users
        postgrey                Greylisting of incoming mail
        amavisd-new                Mail filtering - allows use of ClamAV
        clam-av                        Virus scanning
        SquirrelMail                WebMail



Here are the pertinent lines from /usr/local/etc/postfix/master.cf

smtp      inet  n       -       n       -       -       smtpd
smtp2     inet  n       -       n       -       -       smtpd



cat /etc/services |grep smtp

smtp             25/tcp    mail         #Simple Mail Transfer
smtp             25/udp    mail         #Simple Mail Transfer
smtps           465/tcp    #smtp protocol over TLS/SSL (was ssmtp)
smtps           465/udp    #smtp protocol over TLS/SSL (was ssmtp)
smtp2            2225/tcp          mail         #Simple Mail Transfer
smtp2            2225/udp          mail         #Simple Mail Transfer



postconf -n

broken_sasl_auth_clients = no
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
content_filter = smtp-amavis:127.0.0.1:10024
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
default_destination_concurrency_limit = 10
home_mailbox = Maildir/
html_directory = no
local_destination_concurrency_limit = 2
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 20000000
mydestination = ****sales.com, ****service.com, ****collision.com,
****admin.com, ****bodyshop.com, ****parts.com localhost
mydomain = ****sales.com
mynetworks = 127.0.0.1/32
mynetworks_style = host
myorigin = $mydomain
newaliases_path = /usr/local/bin/newaliases
readme_directory = no
relay_domains = ****sales.com, ****service.com, ****collision.com,
****admin.com, ****bodyshop.com, ****parts.com, 127.0.0.1, localhost
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtp_tls_cert_file = /usr/local/etc/postfix/cert.pem
smtp_tls_key_file = /usr/local/etc/postfix/key.pem
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,  check_helo_access
hash:/usr/local/etc/postfix/helo_access,  reject_invalid_hostname,  permit
smtpd_recipient_restrictions = reject_unauth_pipelining,
reject_non_fqdn_recipient,  reject_unknown_recipient_domain,
permit_mynetworks,  permit_sasl_authenticated,  reject_invalid_hostname,
reject_non_fqdn_hostname,  reject_non_fqdn_sender,
reject_unknown_sender_domain,  reject_unauth_destination,
reject_rbl_client zen.spamhaus.org,  check_policy_service
inet:127.0.0.1:10023,  permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_mynetworks,  
permit_sasl_authenticated, reject_non_fqdn_sender,  
reject_unknown_sender_domain,  permit
smtpd_tls_CAfile = /usr/local/etc/postfix/cacert.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /usr/local/etc/postfix/cert.pem
smtpd_tls_key_file = /usr/local/etc/postfix/key.pem
smtpd_tls_loglevel = 0
smtpd_tls_received_header = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
unknown_client_reject_code = 450
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550



/etc/pf.conf

# Set variables.
ext_if = "tun0"
lcl_if = "lo0"
lcl_ip = "127.0.0.1/32"
int_if = "rl0"
int_ip = "192.168.20.1/24"
int_sip = "192.168.20.1/32"
adm_if = "vr0"
adm_ip = "192.168.5.2/32"
adm_sip = "192.168.5.1/32"

pop3_ports = "{ 110, 995 }"
imap_ports = "{ 143, 993 }"
smtp_ports = "{ 25, 2225 }"
bind_ports = "{ 53 }"
webs_ports = "{ 80, 443 }"
admn_ports = "{ 22, 10101 }"
icmp_types = "echoreq"

# Set defaults.
set block-policy return
set loginterface $ext_if
set skip on $lcl_if
scrub in on { $ext_if, $int_if }

# Allow internal interfaces to get to the internet.
nat on $ext_if from $int_ip to any -> ($ext_if)
nat on $ext_if from $adm_ip to any -> ($ext_if)

# Block everything unless later explicitly allowed.
block in

# Keep state for established connections.
pass out keep state

# Protect against IP spoofing on local network segments.
antispoof quick for { $lcl_if $int_if $adm_if }

# Block inbound traffic from IPs not valid for each interface.
block in quick on ! $int_if inet from $int_ip to any
block in quick on ! $adm_if inet from $adm_ip to any

# Nobody else is me - block attempts to make us think so.
block in quick on $int_if inet from $int_sip to any
block in quick on $adm_if inet from $adm_sip to any

# Assume administrator knows what he is doing.  Not necessarily true...
pass in quick on $adm_if from $adm_ip

pass in on $ext_if inet proto tcp from any to ($ext_if) port $pop3_ports
flags S/SA keep state
pass in on $ext_if inet proto tcp from any to ($ext_if) port $imap_ports
flags S/SA keep state
pass in on $ext_if inet proto tcp from any to ($ext_if) port $smtp_ports
flags S/SA keep state
pass in on $ext_if inet proto { tcp, udp } from any to ($ext_if) port
$bind_ports
pass in on $ext_if inet proto tcp from any to ($ext_if) port $webs_ports
flags S/SA keep state
pass in on $int_if inet proto tcp from any to any port $pop3_ports flags
S/SA keep state
pass in on $int_if inet proto tcp from any to any port $imap_ports flags
S/SA keep state
pass in on $int_if inet proto tcp from any to any port $smtp_ports flags
S/SA keep state
pass in on $int_if inet proto { tcp, udp } from any to any port $bind_ports
pass in on $int_if inet proto tcp from any to any port $webs_ports flags
S/SA keep state
pass in inet proto icmp all icmp-type $icmp_types keep state



sockstat -4 |grep master

root     master     1089  11 tcp4   *:25                  *:*
root     master     1089  16 tcp4   *:2225                *:*
root     master     1089  90 tcp4   127.0.0.1:10025       *:*





(Apologies if this is posted more than once.  I subscribed to the list,
confirmed the subscription, then sent this message.  A few minutes
later, I received the subscription confirmation.  After 20 minutes and I
didn't see my message come through, so I guessed my timing was just
right so the system didn't see me as a list member yet and junked the
first sending.  I re-sent it 8 hours later and it still didn't post, so
I contacted the list manager.  After no response for a few days, I'm
trying again; I dunno what's going on.)

Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS offered on one port and not another

Charles Marcus
On 6/23/2008, Jim Wagner ([hidden email]) wrote:
> Incidentally, I don't know if it's related or not, but I was unable
> to get SquirrelMail working with TLS on either 25 or 2225.  I later
> read to set it to use 127.0.0.1 as the outbound server, tried this,
> and all was well.

Why 2525 instead of the submission port (587)? This is precisely its
purpose...

--

Best regards,

Charles
Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS offered on one port and not another

Brian Evans - Postfix List
In reply to this post by Jim Wagner-4
Jim Wagner wrote:

> I have a Unix box running Postfix to provide e-mail to employees at my
> company.  I have everything set up and running with one small oddity
> that I'm hopeful that somebody will be able to help me solve.
>
> I can send e-mail using port 2225, whether I use TLS or not.  (I have
> this configured as a backup SMTP port because many employees' home
> ISPs block port 25 for any but their own mail server.  One of the
> reasons I built this machine was so that we could respond to customers
> from home without using personal accounts.)  If I send mail using port
> 25, I can do so as long as I do NOT use TLS.  If I try, I get the
> following message from Thunderbird when connecting to the SMTP server:
>
> Sending of message failed.
> An error occurred sending mail: Unable to connect to SMTP server
> mail.****sales.com via STARTTLS since it doesn't offer STARTTLS in
> EHLO response.
> Please verify that your Mail/News account settings are correct and try
> again.
>
> The ONLY thing I changed between two tests is the port number that
> Thunderbird uses for SMTP.  The PC that I'm using for this test is
> Slackware 10.2.
>
> I did see in the mailing list archives that some anti-virus software
> will strip out the STARTTLS advertisement from an SMTP server
> response.  (Yeah, *that*'s a great design... let's break a security
> feature because it's not used by everyone. :roll eyes:)  However, I
> have no active virus protection on my Slackware box.  I called my ISP
> and they aren't aware of any virus software filtering traffic over the
> line.  I'd also think that this would put an unacceptably tremendous
> drain on whatever system was used - they concurred with this opinion.
>
> Incidentally, I don't know if it's related or not, but I was unable to
> get SquirrelMail working with TLS on either 25 or 2225.  I later read
> to set it to use 127.0.0.1 as the outbound server, tried this, and all
> was well.
>
> This isn't a huge problem, but I would like to correct it if
> possible.  I don't even know where to look any more; Postfix doesn't
> seem to have anything in the way of port specific configuration
> outside of master.cf and the firewall is obviously allowing the
> connection because I can send mail if I don't use TLS.
>
> I appreciate any advice.

Do you have the Sendmail MTA installed and running and not know it?
Capture a transaction's log and post it here.

Also look over http://www.postfix.org/DEBUG_README.html#logging

>
>
>
>
> I replaced part of my domain names with **** in these config files.  
> Here is my machine configuration:

Better to use example.(com|org|net).

>
>
> Here are the pertinent lines from /usr/local/etc/postfix/master.cf
>
> smtp      inet  n       -       n       -       -       smtpd
> smtp2     inet  n       -       n       -       -       smtpd
>
>
>
> cat /etc/services |grep smtp
>
> smtp             25/tcp    mail         #Simple Mail Transfer
> smtp             25/udp    mail         #Simple Mail Transfer
> smtps           465/tcp    #smtp protocol over TLS/SSL (was ssmtp)
> smtps           465/udp    #smtp protocol over TLS/SSL (was ssmtp)
> smtp2            2225/tcp          mail         #Simple Mail Transfer
> smtp2            2225/udp          mail         #Simple Mail Transfer
>
>
>
> postconf -n
>
> broken_sasl_auth_clients = no
> command_directory = /usr/local/sbin
> config_directory = /usr/local/etc/postfix
> content_filter = smtp-amavis:127.0.0.1:10024
> daemon_directory = /usr/local/libexec/postfix
> data_directory = /var/db/postfix
> debug_peer_level = 2
> default_destination_concurrency_limit = 10
> home_mailbox = Maildir/
> html_directory = no
> local_destination_concurrency_limit = 2
> mailq_path = /usr/local/bin/mailq
> manpage_directory = /usr/local/man
> message_size_limit = 20000000
> mydestination = ****sales.com, ****service.com, ****collision.com,
> ****admin.com, ****bodyshop.com, ****parts.com localhost
> mydomain = ****sales.com
> mynetworks = 127.0.0.1/32
> mynetworks_style = host
Setting mynetworks makes mynetworks_style be ignored
> myorigin = $mydomain
> newaliases_path = /usr/local/bin/newaliases
> readme_directory = no
> relay_domains = ****sales.com, ****service.com, ****collision.com,
> ****admin.com, ****bodyshop.com, ****parts.com, 127.0.0.1, localhost
Setting relay_domains here is pointless if relay_domains = mydestination.
Postfix will default to relay things to your internal network.

> sample_directory = /usr/local/etc/postfix
> sendmail_path = /usr/local/sbin/sendmail
> setgid_group = maildrop
> smtp_tls_cert_file = /usr/local/etc/postfix/cert.pem
> smtp_tls_key_file = /usr/local/etc/postfix/key.pem
> smtp_tls_note_starttls_offer = yes
> smtp_use_tls = yes
> smtpd_delay_reject = yes
> smtpd_helo_required = yes
> smtpd_helo_restrictions = permit_mynetworks,  check_helo_access
> hash:/usr/local/etc/postfix/helo_access,  reject_invalid_hostname,  
> permit
> smtpd_recipient_restrictions = reject_unauth_pipelining,
> reject_non_fqdn_recipient,  reject_unknown_recipient_domain,
> permit_mynetworks,  permit_sasl_authenticated,  
> reject_invalid_hostname, reject_non_fqdn_hostname,  
> reject_non_fqdn_sender, reject_unknown_sender_domain,  
> reject_unauth_destination, reject_rbl_client zen.spamhaus.org,  
> check_policy_service inet:127.0.0.1:10023,  permit
Put reject_unauth_destination right after permit_sasl_authenticated.  
This will save a lot of expensive network checks.
reject_unauth_pipelining is reduced here.  It's best to use in
smtpd_data_restrictions.

> smtpd_sasl_auth_enable = yes
> smtpd_sasl_security_options = noanonymous
> smtpd_sender_restrictions = permit_mynetworks,  
> permit_sasl_authenticated, reject_non_fqdn_sender,  
> reject_unknown_sender_domain,  permit
> smtpd_tls_CAfile = /usr/local/etc/postfix/cacert.pem
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /usr/local/etc/postfix/cert.pem
> smtpd_tls_key_file = /usr/local/etc/postfix/key.pem
> smtpd_tls_loglevel = 0
> smtpd_tls_received_header = no
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_timeout = 3600s
> strict_rfc821_envelopes = yes
> tls_random_source = dev:/dev/urandom
> unknown_client_reject_code = 450
> unknown_hostname_reject_code = 554
> unknown_local_recipient_reject_code = 550
>
>
>
> /etc/pf.conf
>
> # Set variables.
> ext_if = "tun0"
> lcl_if = "lo0"
> lcl_ip = "127.0.0.1/32"
> int_if = "rl0"
> int_ip = "192.168.20.1/24"
> int_sip = "192.168.20.1/32"
> adm_if = "vr0"
> adm_ip = "192.168.5.2/32"
> adm_sip = "192.168.5.1/32"
I see you have no public IP listed.  If this is an MX behind a firewall
NAT, you should have proxy_interfaces set to avoid loop errors.

As Charles Marcus pointed out, it's recommended to use the submission
port (with AUTH required) instead of making up your own.
That said, there's nothing wrong with it, though spammers think like
this too.

Brian
Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS offered on one port and not another

Jim Wagner-4

> Do you have the Sendmail MTA installed and running and not know it?
> Capture a transaction's log and post it here.
I disabled sendmail completely on this machine before installing
Postfix.  Good thought though.

> Also look over http://www.postfix.org/DEBUG_README.html#logging
This is what gave me the indicator of what the problem was.  I feel real
stupid not thinking of using a packet sniffer before scrolling through
that document (I've used them many times before for a variety of
applications), but using tcpdump to capture the transaction on both the
client side and server side revealed that the server is responding with
a 250-STARTTLS, but the client receives 250-XXXXXXXA instead.  There
must be something being done by my ISP to the traffic being passed on
port 25 related to this.  Given that I have a workaround (simply setting
the sending port to my backup), I'm just going to drop it.  (My ISP is
such that they don't know what I'm talking about 1/2 the time anyways.  
They're nice and try, but simply don't have the knowledge required to
understand what I'm saying when I have a problem I can't solve on my
own.)  It is nice to know that it's not something on my box though.

>> smtpd_recipient_restrictions = reject_unauth_pipelining,
>> reject_non_fqdn_recipient,  reject_unknown_recipient_domain,
>> permit_mynetworks,  permit_sasl_authenticated,  
>> reject_invalid_hostname, reject_non_fqdn_hostname,  
>> reject_non_fqdn_sender, reject_unknown_sender_domain,  
>> reject_unauth_destination, reject_rbl_client zen.spamhaus.org,  
>> check_policy_service inet:127.0.0.1:10023,  permit
> Put reject_unauth_destination right after permit_sasl_authenticated.  
> This will save a lot of expensive network checks.
> reject_unauth_pipelining is reduced here.  It's best to use in
> smtpd_data_restrictions.
Thank you for the tip - I just changed it in my config.

> I see you have no public IP listed.  If this is an MX behind a
> firewall NAT, you should have proxy_interfaces set to avoid loop errors.
The reason I don't have a public IP listed is because it's assigned to
the PPPoE interface dynamically upon connection.  I do have a static
address, but for some reason if I use it, various servers (bind, apache)
stop working correctly.

> As Charles Marcus pointed out, it's recommended to use the submission
> port (with AUTH required) instead of making up your own.
The reason I made up my own is because if it's well-known to use the
submission port for this reason, home ISPs may block this as well.  (It
was initially blocked on the DSL line I had this box connected to, which
is what led me to this conclusion.)  Also, there's a small amount of
"security through obscurity" by using a non-standard port number.  This
isn't a school of thought that I necessarily ascribe to, but figured it
wouldn't hurt either.

> That said, there's nothing wrong with it, though spammers think like
> this too.
By this do you mean that doing this will make me more susceptible to
spammers or that spammers don't think there's anything wrong with
annoying the living hell out of as many people as possible?


Thanks for your time and advice guys - I appreciate it.

Jim


Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS offered on one port and not another

Victor Duchovni
On Mon, Jun 23, 2008 at 04:43:20PM -0400, Jim Wagner wrote:

> This is what gave me the indicator of what the problem was.  I feel real
> stupid not thinking of using a packet sniffer before scrolling through
> that document (I've used them many times before for a variety of
> applications), but using tcpdump to capture the transaction on both the
> client side and server side revealed that the server is responding with
> a 250-STARTTLS, but the client receives 250-XXXXXXXA instead.  There
> must be something being done by my ISP to the traffic being passed on
> port 25 related to this.

If it is your ISP, you should this behaviour when choosing any MTA that
supports TLS, otherwise the problem is near your server.

What happens when you try to connect to the primary MX for MessageLabs
(large enough to surely not mind one more random connection):

    $ telnet cluster6.eu.messagelabs.com 25
    Trying 195.245.230.67...
    Connected to cluster6.eu.messagelabs.com.
    Escape character is '^]'.
    220 server-18.tower-50.messagelabs.com ESMTP
    ehlo amnesiac.local
    250-server-18.tower-50.messagelabs.com
    250-STARTTLS
    250-PIPELINING
    250 8BITMIME
    quit
    221 server-18.tower-50.messagelabs.com
    Connection closed by foreign host.

Do you see STARTTLS there?

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS offered on one port and not another

Jim Wagner-4
Victor Duchovni wrote:

> If it is your ISP, you should this behaviour when choosing any MTA that
> supports TLS, otherwise the problem is near your server.
>
> What happens when you try to connect to the primary MX for MessageLabs
> (large enough to surely not mind one more random connection):
>
>     $ telnet cluster6.eu.messagelabs.com 25
>     Trying 195.245.230.67...
>     Connected to cluster6.eu.messagelabs.com.
>     Escape character is '^]'.
>     220 server-18.tower-50.messagelabs.com ESMTP
>     ehlo amnesiac.local
>     250-server-18.tower-50.messagelabs.com
>     250-STARTTLS
>     250-PIPELINING
>     250 8BITMIME
>     quit
>     221 server-18.tower-50.messagelabs.com
>     Connection closed by foreign host.
>
> Do you see STARTTLS there
Very good idea as a check to verify my hypothesis.  I indeed do not see
the 250-STARTTLS command when connecting to that box, but instead see
the 250-XXXXXXXA as I did when connecting to my own mail server.  I
tried doing the same from my mail server and was able to see the
250-STARTTLS response.  From what I can see, this isolates the problem
to my ISP scanning for and stripping out the STARTTLS response from mail
servers.

Now for an obvious question, why would any ISP implement such a system
to purposely scan for and disable what's basically a security feature?

Jim

Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS offered on one port and not another

Victor Duchovni
On Mon, Jun 23, 2008 at 05:11:52PM -0400, Jim Wagner wrote:

> Victor Duchovni wrote:
> >If it is your ISP, you should this behaviour when choosing any MTA that
> >supports TLS, otherwise the problem is near your server.
> >
> >What happens when you try to connect to the primary MX for MessageLabs
> >(large enough to surely not mind one more random connection):
> >
> >    $ telnet cluster6.eu.messagelabs.com 25
> >    Trying 195.245.230.67...
> >    Connected to cluster6.eu.messagelabs.com.
> >    Escape character is '^]'.
> >    220 server-18.tower-50.messagelabs.com ESMTP
> >    ehlo amnesiac.local
> >    250-server-18.tower-50.messagelabs.com
> >    250-STARTTLS
> >    250-PIPELINING
> >    250 8BITMIME
> >    quit
> >    221 server-18.tower-50.messagelabs.com
> >    Connection closed by foreign host.
> >
> >Do you see STARTTLS there
> Very good idea as a check to verify my hypothesis.  I indeed do not see
> the 250-STARTTLS command when connecting to that box, but instead see
> the 250-XXXXXXXA as I did when connecting to my own mail server.  I
> tried doing the same from my mail server and was able to see the
> 250-STARTTLS response.  From what I can see, this isolates the problem
> to my ISP scanning for and stripping out the STARTTLS response from mail
> servers.
>
> Now for an obvious question, why would any ISP implement such a system
> to purposely scan for and disable what's basically a security feature?

Perhaps instead of port 25 blocking, they are doing port 25 scanning,
and if they detect sufficient quantities of spam, they block your IP
from using port 25.

This is not unreasonable, you may have to pay for a business connection
to get a static IP and no STARTTLS suppression. They could block
port 25 outright, this may be a compromise.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS offered on one port and not another

Jorey Bump
In reply to this post by Jim Wagner-4
Jim Wagner wrote, at 06/23/2008 04:43 PM:

> The reason I made up my own is because if it's well-known to use the
> submission port for this reason, home ISPs may block this as well.  (It
> was initially blocked on the DSL line I had this box connected to, which
> is what led me to this conclusion.)  Also, there's a small amount of
> "security through obscurity" by using a non-standard port number.  This
> isn't a school of thought that I necessarily ascribe to, but figured it
> wouldn't hurt either.

As long as the submission service (port 587) is configured properly,
there's no reason to block it. It shouldn't be a carbon copy of the SMTP
service running on port 25; it should only accept messages from
authenticated users (and/or possibly machines in $mynetworks), and
ideally should be encrypted. It should not act as an MX, accepting
messages from anywhere on the Internet to domains for which it acts as a
destination.

Properly implemented, port 587 solves far more problems for ISPs than it
causes. Blocking it would be somewhat boneheaded. I don't know of any
that block outgoing SSH (port 22) connections and that's abused far more
often.

Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS offered on one port and not another

/dev/rob0
In reply to this post by Jim Wagner-4
On Mon June 23 2008 15:43:20 Jim Wagner wrote:
> > As Charles Marcus pointed out, it's recommended to use the
> > submission port (with AUTH required) instead of making up your own.
>
> The reason I made up my own is because if it's well-known to use the
> submission port for this reason, home ISPs may block this as well.

Granted, it is not hard to find cluelessly-administered ISPs, but home
users are the entire purpose for submission. Any ISP which would block
outbound submission should be avoided with extreme prejudice.

There are good reasons why ISPs block outbound smtp: almost all that
traffic is abuse, and much of it results in complaints and punitive
action against the ISP. A properly-configured submission service (and
indeed, the same caveat as above applies) is not easily abused by
spammers, and if it is, complaints won't come to the ISP of the
submitter -- they will go to the submission service provider.

> (It was initially blocked on the DSL line I had this box connected
> to, which is what led me to this conclusion.)  Also, there's a small

Hmmm, I have never encountered this.

> amount of "security through obscurity" by using a non-standard port
> number.  This isn't a school of thought that I necessarily ascribe
> to, but figured it wouldn't hurt either.

In the case of port 22 (which as Jorey mentioned, is heavily abused)
we're in agreement. Moving your sshd off of 22 avoids the abuse. Ports
25 & 80, likewise, are heavily scanned. I'm not aware of any attack
bots on 587, however. There is little to be gained from it, probably
nothing that can't also be had on port 25.
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header
Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS offered on one port and not another

Brian Evans - Postfix List
In reply to this post by Jim Wagner-4
Jim Wagner wrote:

> Victor Duchovni wrote:
>> If it is your ISP, you should this behaviour when choosing any MTA that
>> supports TLS, otherwise the problem is near your server.
>>
>> What happens when you try to connect to the primary MX for MessageLabs
>> (large enough to surely not mind one more random connection):
>>
>>     $ telnet cluster6.eu.messagelabs.com 25
>>     Trying 195.245.230.67...
>>     Connected to cluster6.eu.messagelabs.com.
>>     Escape character is '^]'.
>>     220 server-18.tower-50.messagelabs.com ESMTP
>>     ehlo amnesiac.local
>>     250-server-18.tower-50.messagelabs.com
>>     250-STARTTLS
>>     250-PIPELINING
>>     250 8BITMIME
>>     quit
>>     221 server-18.tower-50.messagelabs.com
>>     Connection closed by foreign host.
>>
>> Do you see STARTTLS there
> Very good idea as a check to verify my hypothesis.  I indeed do not
> see the 250-STARTTLS command when connecting to that box, but instead
> see the 250-XXXXXXXA as I did when connecting to my own mail server.  
> I tried doing the same from my mail server and was able to see the
That response is a common reply for Cisco PIX (botched ESMTP
implementation) or similar firewalls/gateways/filters.
Investigate where that reply is being created and you solve your problem.

Brian
> 250-STARTTLS response.  From what I can see, this isolates the problem
> to my ISP scanning for and stripping out the STARTTLS response from
> mail servers.
>
> Now for an obvious question, why would any ISP implement such a system
> to purposely scan for and disable what's basically a security feature?
>
> Jim
>