Great! i got it now. you guys rocks.
by this we will have 3 separate network classes.
1, unauth/local LAN
2. Auth but only to Allowed IP (such as Verison USA 108.44.155.0/24)
3. and rest of them will be excluded from relaying or blocked.
yes i am aware of geo ip list. will try this too.
Thanks again,
MYK
On Mon, Apr 6, 2015 at 5:43 PM, Sebastian Nielsen <sebast...@sebbe.eu>
wrote:
> What I meant is that if your users are on a dynamic IP from a “outside”
> net, you can allow that net *in combination* with authentication.
> Thus, you will both need to be from the correct net, but also have a valid
> username and password.
>
> For example, lets say you have a internal company network on
> 192.168.0.0/16 and then all your external users have ISP accounts from
> Comhem Sweden.
> Then you put your internal company network inside “mynetworks” so internal
> users can relay without authentication.
>
> But then, you put the whole Comhem network ( 151.177.0.0/16 ) that
> “permit_sasl_authenticated, reject_unauth_destination” all users inside
> 151.177.0.0/16, and does only “reject_unauth_destination” those outside
> that net.
> This means that anyone from the comhem network will be able to
> authenticate & relay (but not relay without authentication), but those
> outside comhem network wont be able to relay at all, not even as
> authenticated.
> Thus, a spammer hacker that does have a good dictionary list or a decent
> password cracking software, will not gain any success anyways, because it
> wont matter how much good accounts that hacker does have, he will still not
> be able to relay through that server because he must be from
> 151.177.0.0/16 aswell.
>
> If you know that all your users are from a specific country, you could
> download a GeoIP database and put into the access table.
>
> Basically, you set your server to:
> allow relay for internal users (192.168.0.0/16 or similiar) without
> authentication.
> allow relay for authenticated users but ONLY if the authenticated users
> come from a specific country or ISP network.
>
> Then you have a good protection against dictionary hackers/bruteforcers.
>
> Many ISPs in sweden do this, they BOTH require authentication, but you
> aswell need to use a IP from that particular ISP.
> Users outside that network simply has to use their webmail, which does
> have more protections in form of captchas and such.
>
> *From:* Muhammad Yousuf Khan <sir...@gmail.com>
> *Sent:* Monday, April 06, 2015 2:27 PM
> *To:* Peter <pe...@pajamian.dhs.org>
> *Cc:* Postfix users <postfix-users@postfix.org>
> *Subject:* Re: port 25 465 and 587 confusion.
>
> @Peter
>
>> Right, you really should not be allowing submission on port 25 at all.
>>
>>
>
>> > and is this segregation is a good thought of mine or practical?
>>
>> Yes
>>
>> > isn't 465 is useless and can i close this if yes then how?
>>
>> That depends on if you have users that have very old versions of Outlook
>> which don't support STARTTLS. In this case you should encourage or even
>> require them to upgrade to a newer email client, but in case you can't
>> do that then you might have to support port 465 for them.
>>
>> You close it by commenting out the smtps section in master.cf.
>>
>>
> in light of your above suggestions. i enabled
>
> smtp inet n - - - - smtpd
> #smtp inet n - - - 1 postscreen
> #smtpd pass - - - - - smtpd
> #dnsblog unix - - - - 0 dnsblog
> #tlsproxy unix - - - - 0 tlsproxy
> submission inet n - - - - smtpd
> -o syslog_name=postfix/submission
> -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
> #smtps inet n - - - - smtpd
> # -o syslog_name=postfix/smtps
> # -o smtpd_tls_wrappermode=yes
> # -o smtpd_sasl_auth_enable=yes
> # -o smtpd_client_restrictions=permit_sasl_authenticated,reject
> # -o milter_macro_daemon_name=ORIGINATING
>
> main.cf, i enabled "smtpd_tls_security_level=encrypt" (i know master.cf
> entry will override but i set encryption in both files)
>
> by disabling smtps. i disabled the 465 port. and also forced submission by
> this line " submission inet n - - - - smtpd"
>
> however my clients can still submit emails on port 25. and also on 587
> port. both work the same.
> can you please guide?
>
>
>
>
>
> @Sebastion Nielsen
> >IMHO I find it better to only allow submission from trusted nets. Better
> to disable authentication completely, and completely >disable mail
> submission ("relaying") from the "outside".
> >Thus closing 587 completely.
> >465 can be good to allow old (or misconfigured) SMTPS servers to send
> incoming mail to you.
>
>
> Thanks its a good idea i will also read and try to implement this in
> separate environment though i think this approach is applicable when you
> know your client IPs. if they are dynamic and can be anywhere thoughout the
> word it is a headache to note down and allow all the IP. i think simple TLS
> may do the job. i could be wrong but i am very new to mailing thing and
> this is the point which makeing me stop doing it.
>
>
>
>
