port 587 or 25?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

port 587 or 25?

Mauro Sanna
What are the advantages of using port 587 rather than 25?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: port 587 or 25?

Mark Watts

On Monday 12 May 2008 10:12:26 Mauro Sanna wrote:
> What are the advantages of using port 587 rather than 25?

Port 587 usually requires users to authenticate in order to send mail wheras
port 25 does not.

As a result, institutions that wish to limit email users to a known group may
choose to issue login credentials to those users and configure their mail
system such that they will not relay mail mail destined for external
addresses unless it had been submitted via (authenticated) port 587.

Mark.

--
Mark Watts BSc RHCE MBCS
Senior Systems Engineer
QinetiQ Applied Technologies
GPG Key: http://keyserver.veridis.com:11371/search?q=0x455420ED

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: port 587 or 25?

mouss-2
In reply to this post by Mauro Sanna
Mauro Sanna wrote:
> What are the advantages of using port 587 rather than 25?
>
>  

- viruses and spamware that use port 25 can be blocked and detected.

- you don't get smtp transactions from MUAs that are not configured. A
user who sees "cannot connect to mail server" is reportedly happier than
one who sees "blah blah rejected blah blah". In the first case, he will
ask admin and admin knows what is heppening. in the second case, he will
spend an hour trying to click everywhere and then ask the admin without
saying that he never configured his MUA, so admin will also spend 15
minutes before realizing that the MUA is not configured.

- if you run an MTA on port 25 on the same machine, you don't need
complex configurations to differentiate between submitted mail and other
mail.

- it is the standard. It is hoped that next generations of MUAs will be
"submission-friendly".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: port 587 or 25?

Mauro Sanna
In reply to this post by Mark Watts
Il giorno lun, 12/05/2008 alle 10.19 +0100, Mark Watts ha scritto:
> On Monday 12 May 2008 10:12:26 Mauro Sanna wrote:
> > What are the advantages of using port 587 rather than 25?
>
> Port 587 usually requires users to authenticate in order to send mail wheras
> port 25 does not.

I'm using sasl over tls and in my main.cf I have smtpd_tls_auth_only =
yes. It's not enought?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: port 587 or 25?

Bill Cole-3
At 11:27 AM +0200 5/12/08, Mauro Sanna wrote:
>Il giorno lun, 12/05/2008 alle 10.19 +0100, Mark Watts ha scritto:
>>  On Monday 12 May 2008 10:12:26 Mauro Sanna wrote:
>>  > What are the advantages of using port 587 rather than 25?
>>
>>  Port 587 usually requires users to authenticate in order to send mail wheras
>>  port 25 does not.
>
>I'm using sasl over tls and in my main.cf I have smtpd_tls_auth_only =
>yes. It's not enought?

It *MAY* be. You have not said anything about what your system is
used for, so no one else can really say.

The 25/587 question in the context of running a mail server (i.e. on
topic here) is not simply about using one port or the other. The
reason for a distinct mail submission protocol being defined and
given its own port distinct from SMTP is that as support for mail
submission as defined in RFC2476 and refined in RFC4409  in MUA's
becomes ubiquitous, it becomes possible for people whose mail servers
have traditionally operated as both MTA's and MSA's to split those
functionalities and effectively run two distinct services configiured
optimally for each rather than a unified MSA/MTA with a configuration
that has to make allowances for the different types of use. Postfix
actually reduces that advantage if you are willing to work on the
configuration and use restriction classes, but that does not get all
of the advantages you can get from having mail submission on a
distinct port. For example, in addition to being able to require
encryption and SMTP authentication for port 587 sessions, if you are
willing to set up your own PKI (or already have one) you can
distribute client certs to users and require that sessions on port
587 use those certs, pushing authentication lower in the stack and
making it harder to attack than simple anonymous TLS encryption with
password-based authentication, and potentially eliminating SASL
altogether. With MSA and MTA traffic on different ports, you can also
push some forms of access control and rate limiting out to the
network rather than having to do it on the mail server host itself,
e.g. with ipf/ipfw/iptables and/or anvil. Some systems trust their
users enough (perhaps wisely) that they can eliminate spam filtering
altogether on MSA traffic, while others can take advantage of the
fact that the MSA is not being pounded with very high volumes by
random strangers, and do deeper high-cost content analysis on MSA
traffic than they would want to do on the huge volume that hits a
MTA. because one presumably knows more about what sort of mail ones
own users intentionally send, one can do more reliable detection and
prevention of illegitimate mail in an MSA.

--
Bill Cole
[hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: port 587 or 25?

Mauro Sanna

> The 25/587 question in the context of running a mail server (i.e. on
> topic here) is not simply about using one port or the other. The
> reason for a distinct mail submission protocol being defined and
> given its own port distinct from SMTP is that as support for mail
> submission as defined in RFC2476 and refined in RFC4409  in MUA's
> becomes ubiquitous, it becomes possible for people whose mail servers
> have traditionally operated as both MTA's and MSA's to split those
> functionalities and effectively run two distinct services configiured
> optimally for each rather than a unified MSA/MTA with a configuration
> that has to make allowances for the different types of use. Postfix
> actually reduces that advantage if you are willing to work on the
> configuration and use restriction classes, but that does not get all
> of the advantages you can get from having mail submission on a
> distinct port. For example, in addition to being able to require
> encryption and SMTP authentication for port 587 sessions, if you are
> willing to set up your own PKI (or already have one) you can
> distribute client certs to users and require that sessions on port
> 587 use those certs, pushing authentication lower in the stack and
> making it harder to attack than simple anonymous TLS encryption with
> password-based authentication, and potentially eliminating SASL
> altogether. With MSA and MTA traffic on different ports, you can also
> push some forms of access control and rate limiting out to the
> network rather than having to do it on the mail server host itself,
> e.g. with ipf/ipfw/iptables and/or anvil. Some systems trust their
> users enough (perhaps wisely) that they can eliminate spam filtering
> altogether on MSA traffic, while others can take advantage of the
> fact that the MSA is not being pounded with very high volumes by
> random strangers, and do deeper high-cost content analysis on MSA
> traffic than they would want to do on the huge volume that hits a
> MTA. because one presumably knows more about what sort of mail ones
> own users intentionally send, one can do more reliable detection and
> prevention of illegitimate mail in an MSA.
>
Sorry for my ignorance.
I have set in master.cf
submission inet n       -       -       -       -       smtpd
  -o smtpd_enforce_tls=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

while some part of my postconf is:

smtp_tls_CAfile = /etc/ssl/certs/cacert.pem
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_banner = $myhostname NO UCE ESMTP
smtpd_data_restrictions = reject_unauth_pipelining,    permit
smtpd_helo_required = yes
smtpd_recipient_restrictions =
reject_non_fqdn_sender,    
reject_non_fqdn_recipient,    
permit_mynetworks,    
permit_sasl_authenticated,    
reject_unauth_destination,    
reject_invalid_hostname,    
reject_non_fqdn_hostname,    
reject_unknown_sender_domain,    
reject_rbl_client safe.dnsbl.sorbs.net,    
reject_rbl_client cbl.abuseat.org,    
reject_rbl_client list.dsbl.org,    
reject_rbl_client dnsbl.njabl.org,    
reject_rbl_client bl.spamcop.net,    
reject_rbl_client zen.spamhaus.org,    
check_policy_service inet:127.0.0.1:60000,    
permit
smtpd_reject_unlisted_sender = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_always_issue_session_ids = no
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/postfix-cert.pem
smtpd_tls_key_file = /etc/ssl/private/postfix-key.pem
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
virtual_alias_maps = hash:/etc/postfix/virtual-aliases
virtual_gid_maps = static:1004
virtual_mailbox_base = /var/vmail
virtual_mailbox_domains = hash:/etc/postfix/vmaildomains
virtual_mailbox_maps = ldap:/etc/postfix/ldap-vmail.cf
virtual_minimum_uid = 1004
virtual_uid_maps = static:1004

If I comment out permit_sasl_authenticated I can't relay.
But if I uncomment it i can relay by using port 587 and port 25 while I
want to permit relay only by port 587.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: port 587 or 25?

Bill Cole-3
At 5:13 PM +0200 5/12/08, Mauro Sanna  imposed structure on a stream
of electrons, yielding:
[...]
>Sorry for my ignorance.

There is no need to apologize. I suspect that to some degree nearly
everyone on this list is here in order to identify and eliminate our
own particular areas of ignorance.

>I have set in master.cf
>submission inet n       -       -       -       -       smtpd
>   -o smtpd_enforce_tls=yes
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>
>while some part of my postconf is:

[I've reduced this to the relevant part]

>smtpd_recipient_restrictions =
>reject_non_fqdn_sender,
>reject_non_fqdn_recipient,
>permit_mynetworks,
>permit_sasl_authenticated,
>reject_unauth_destination,
>reject_invalid_hostname,
>reject_non_fqdn_hostname,
>reject_unknown_sender_domain,
>reject_rbl_client safe.dnsbl.sorbs.net,
>reject_rbl_client cbl.abuseat.org,
>reject_rbl_client list.dsbl.org,
>reject_rbl_client dnsbl.njabl.org,
>reject_rbl_client bl.spamcop.net,
>reject_rbl_client zen.spamhaus.org,
>check_policy_service inet:127.0.0.1:60000,
>permit

>If I comment out permit_sasl_authenticated I can't relay.
>But if I uncomment it i can relay by using port 587 and port 25 while I
>want to permit relay only by port 587.

Your master.cf entry overrides the smtpd_client_restrictions setting
in main.cf, but it does not override the smtpd_recipient_restrictions
setting, which is applied after smtpd_client_restrictions. If you
change smtpd_client_restrictions in the submission entry in master.cf
to smtpd_recipient_restrictions  you should be able to remove
permit_sasl_authenticated from the smtpd_recipient_restrictions
section in main.cf and still allow port 587 relay when authenticated
without allowing port 25 relay when authenticated.





--
Bill Cole
[hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: port 587 or 25?

Victor Duchovni
On Mon, May 12, 2008 at 12:13:37PM -0400, Bill Cole wrote:

> >I have set in master.cf
> >submission inet n       -       -       -       -       smtpd
> >  -o smtpd_enforce_tls=yes

For Postfix 2.3 and later, use "smtpd_tls_security_level=encrypt"

    http://www.postfix.org/postconf.5.html#smtpd_tls_security_level

--
        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.
Loading...