Re: [qmailtoaster] Re: how to SMTPS submission/port 587

Sun, 22 Jan 2012 11:34:01 -0800

There are many "fundamental issues" with Internet Mail -- we've (as a community) been grappling with them for decades now. The fact that users CAN submit SMTP messages (to be relayed elsewhere) is 1/2 of the function of an MTA as defined in the ORIGINAL spec (ca. 1980)... The fact that everything CAN be done on a single IP and over a single port (25) is why e-mail administration is NOT the simple thing most users assume it must be (I've known many a web server admin who thought they could handle email and eventually threw in the towel -- esp now that there are so many nearly-free hosted solutions out there -- do y'all know that yahoo mail is a QMail installation??) 

The solution that I choose to use for security is:
1) I block port 25 on my mail server from my user's home LAN -- even from the WAN IP of their router -- users MUST submit outbound mail via port 465 1a) I don't implement port 587 -- AUTH over in insecure channel is of no value to me... just my opinion... 1b) I don't permit other outbound port 25 traffic from their LAN either -- either use my mail server as the relay (MTA) or use a secure port provided by your ISP (most surprisingly do allow port 465) 2) As implied above, all outbound (user submitted mail) must be submitted over an SMTPS connection (port 465) -- that is, AUTH is required, but over a SECURE channel 3) All users must use either POP3S or IMAP4S (ports 995 & 993 respectively) -- with a strong preference for IMAP to retrieve mail (even the webmail is configured to use IMAPS) 3a) I do not run POP or IMAP services on ports 110 or 143... not at all... 3b) I do NOT block these insecure ports for LAN users -- they can RETRIEVE mail using insecure protocols, they just can't SEND mail that way! 4) To make all of this seamless, I purchase a REAL SSL certificate for each client -- so that handhelds and "temporary" computers (like users checking mail from home) can do so without anything special (other than using the SSL versions for everything!) 


With those restrictions on user access, I can focus my attentions on 
port 25 knowing that connections there are (must be) inbound mail for 
one of my domains.



I seldom have issues pertaining to SPAM emanating from my users -- even 
virus infected users -- because of these precautions (and most malware 
writers assume that SMTP ports will be open on your defined mail servers!)



NOTE: Just because it's how *I* do it, doesn't mean it'll work for you 
-- for example, I have to pay about $50/year for the signed SSL 
certificate for each server/customer.


Dan
IT4SOHO

On 1/21/2012 12:31 PM, Michael J. Colvin wrote:



I'm not sure having any advantage was the issue...  The OP just didn't 
want them to do it. J  I personally don't see where it matters either 
way.  For me, I just want customers using a specific server.


Mike

*From:*Tonix (Antonio Nati) [mailto:[email protected]]
*Sent:* Saturday, January 21, 2012 3:16 AM
*To:* [email protected]
*Subject:* Re: [qmailtoaster] Re: how to SMTPS submission/port 587

Correction: :-)
I don't understand *why* a user should have adavantage using it.

Tonino

Il 21/01/2012 12:08, Tonix (Antonio Nati) ha scritto:

There is something I don't understand.


An autenticated user, using relay, has no spam control, no grey list, 
as he is already authenticated. Only antivirus check.
If the same user wants to send using MX, he gots spam control, grey 
list, etc...


So, which is the advantage of using public mx?

public mx is the most controlled.... I don't understand which a user 
should have adavantage using it.


Tonino

Il 21/01/2012 03:19, Michael J. Colvin ha scritto:


If I understand you correctly though....  If I was clever enough of a 
user

to figure out the IP of your incoming e-mail server, either on purpose or
simply by accident, I could user port 25, authenticate, and send mail...
Now, this isn't a big deal, I understand, but it provides the opportunity
for someone to circumvent (Either intentionally or by accident) what the
original poster was trying to block.

Mike


-----Original Message-----
From: Tonix (Antonio Nati) [mailto:[email protected]]
Sent: Friday, January 20, 2012 5:11 PM

To: [email protected] 
<mailto:[email protected]>

Subject: Re: [qmailtoaster] Re: how to SMTPS submission/port 587

Il 21/01/2012 01:39, Eric Shubert ha scritto:

On 01/20/2012 01:07 PM, Michael J. Colvin wrote:

I believe you could use SpamDyke to block your users from sending

via

    port
    25...  You could block via the domain name, you could block by IP
    address
    and rDNS, assuming your users have specific IP's (Or range of IP's)
    or rDNS
    information...  You could do all three too...  Or does

authentication

    bypass
    SpamDyke?  I forget.

Authenticated connections bypass all filters. Sorry. ;)


If it does, set up two servers...  One for incoming mail, one for
outgoing
mail.  Turn port 25 off on the outbound server, forcing users to use
a port
that's active, like 587.  Inbound mail will come in via port 25 from
outside
mail servers, use smtproutes to forward it to your "inside" mail
server via
port 587, use SpamDyke to block your users' domain's in the "From"

field

    (Works great for stopping a lot of SPAM too!) and then remove the
    ability to
    authenticate on 25 (No e-mail addresses on the server)...  If server
    count
    is an issue, use a VM and put both servers on one physical server...

    Mike

This took me a couple reads, but you know what? I think I get it, and
I kinda like it! :)

This definitely deserves to be hashed around a bit. Having 2 separate
(QMT) hosts, one for outbound (submission) and one for inbound (smtp)
makes some sense, if for no other reason than it's simply logical.

One of QMT's weaknesses in the past has been that everything is
tightly wound and interdependent, aka "highly coupled" (as we used to
say about modules in structured programs). This is clearly a place
where roles can, and probably should be delineated. Along the same
lines as MUA, MSA, MTA, MDA. (see Nov'07 RFC5068 entitled "Best
Current Practice - Email Submission:
http://tools.ietf.org/html/rfc5068)

While I was looking for that RFC specifically, I came across this

one:

http://tools.ietf.org/html/rfc6409 from Nov'11. It's not easy keeping
up with the times. :) I still need to read this one, but I'll go

ahead

and post this reply for the time being.

If you have a thought or idea you'd like to share about this, please
chime in!

Eric, while I like this model (and we are already using it), I don't
understand the request originatin this thread.

We simply told our customers which address they could use for relaying
(relay.yourdomain.com), with no antispam, and they all are using this
relay, with their internal communication faster and trouble free.

Probably our success point is we are using two different IP addresses
for this purpose:
- we receive mx on mx.yourdomain.com (free), port 25
- we accept relaying on relay.yourdomain.com (must auth), ports 25 and
587

Probably having two different addresses is much better then simply
using
different ports.
Just tell your customers which address must be used for relaying, and
use an mx name without telling them.

Regards,

Tonino






Thanks.


--
------------------------------------------------------------
          Inter@zioni            Interazioni di Antonio Nati

http://www.interazioni.it [email protected] 
<mailto:[email protected]>

------------------------------------------------------------


-----------------------------------------------------------------------
----------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com <http://www.vickersconsulting.com>)
     Vickers Consulting Group offers Qmailtoaster support and
installations.
       If you need professional help with your setup, contact them
today!
-----------------------------------------------------------------------
----------
      Please visit qmailtoaster.com for the latest news, updates, and
packages.

       To unsubscribe, e-mail: qmailtoaster-list-
[email protected] <mailto:[email protected]>
      For additional commands, e-mail: qmailtoaster-list-
[email protected] <mailto:[email protected]>




--------------------------------------------------------------------------------- 

Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com <http://www.vickersconsulting.com>)
     Vickers Consulting Group offers Qmailtoaster support and 
installations.

       If you need professional help with your setup, contact them today!

--------------------------------------------------------------------------------- 

      Please visit qmailtoaster.com for the latest news, updates, and 
packages.



       To unsubscribe, e-mail: 
[email protected] 
<mailto:[email protected]>
      For additional commands, e-mail: 
[email protected] 
<mailto:[email protected]>






--
------------------------------------------------------------
         Inter@zioni            Interazioni di Antonio Nati

    http://www.interazioni.it       [email protected]  <mailto:[email protected]>            
------------------------------------------------------------























					Reply via email to