Telnet auth

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

Telnet auth

Catalin Badirca


Hi,
I am breaking my head trying to solve the following thing. I have a Postfix server that accepts mail from $mydomain and delivers for standard $mydestination. I also have smtp_relay_redtriction to allow sasl and reject other destinations than $mydomain. Standard until now. The thing is: if i telnet to the machine and try to send mail from a valid address to another valid address in $mydomain i can do it without beeing forced to authenticate. I can easily force reject instead of reject_unauth_destination and tale care of this but then no emails for me.

Does anyone know a solution for this please ?

Thabk you for your help !


Reply | Threaded
Open this post in threaded view
|

Re: Telnet auth

/dev/rob0
On Mon, May 16, 2016 at 07:25:54PM +0300, Catalin Badirca wrote:
> I am breaking my head trying to solve the following thing. I have a
> Postfix server that accepts mail from $mydomain and delivers for

"From $mydomain" probably has nothing to do with it.

> standard $mydestination. I also have smtp_relay_redtriction to

smtpd_relay_restrictions, spelling DOES count, and be especially
aware of the "smtp_* != smtpd_" issue.

> allow sasl and reject other destinations than $mydomain. Standard

s/mydomain/mydestination/ , that is.

> until now. The thing is: if i telnet to the machine and try to send
> mail from a valid address to another valid address in $mydomain i
> can do it without beeing forced to authenticate. I can easily force
> reject instead of reject_unauth_destination and tale care of this
> but then no emails for me.
>
> Does anyone know a solution for this please ?

It's quite simple, actually.

Do not accept user submission on port 25.  Remove all permit_*
restrictions from the global configuration.  Don't advertise nor
accept AUTH on port 25.

Do not accept mail exchange on port 587.

main.cf:
...
smtpd_relay_restrictions = reject_unauth_destination
submission_relay_restrictions = permit_sasl_authenticated, reject
# smtpd_sasl_auth_enable is "no" by default, so omit that, but
# other smtpd_sasl_* settings can go here
...

master.cf:
...
submission inet  n       -       n       -       -       smtpd
    -o smtpd_tls_auth_only=yes
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_recipient_restrictions=
    -o smtpd_relay_restrictions=$submission_relay_restrictions
    -o milter_macro_daemon_name=ORIGINATING
    -o syslog_name=postfix/submission
...

(That example assumes that TLS is set up for smtpd.)

Yes, someone can still  "telnet" to port 25 and send mail to your
addresses/users.  That's what mail exchange is.  Nothing is magic
about telnet, it is just one of many ways to make a TCP connection.
That's the same thing a MTA client will do when delivering mail on
behalf of their user to one of your addresses.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: Telnet auth

Catalin Badirca
Thank you very much for your time and sorry for the long response time.

I've tried your suggestion and the issue remains. Someone could telnet into postfix and would be allowed to send mails from a valid address to another valid address in mydomain without authentication.

Is there any way I can stop potential spam for mydomain ?

Thabk you !

Sent from my iPhone

> On 16 May 2016, at 20:21, /dev/rob0 <[hidden email]> wrote:
>
>> On Mon, May 16, 2016 at 07:25:54PM +0300, Catalin Badirca wrote:
>> I am breaking my head trying to solve the following thing. I have a
>> Postfix server that accepts mail from $mydomain and delivers for
>
> "From $mydomain" probably has nothing to do with it.
>
>> standard $mydestination. I also have smtp_relay_redtriction to
>
> smtpd_relay_restrictions, spelling DOES count, and be especially
> aware of the "smtp_* != smtpd_" issue.
>
>> allow sasl and reject other destinations than $mydomain. Standard
>
> s/mydomain/mydestination/ , that is.
>
>> until now. The thing is: if i telnet to the machine and try to send
>> mail from a valid address to another valid address in $mydomain i
>> can do it without beeing forced to authenticate. I can easily force
>> reject instead of reject_unauth_destination and tale care of this
>> but then no emails for me.
>>
>> Does anyone know a solution for this please ?
>
> It's quite simple, actually.
>
> Do not accept user submission on port 25.  Remove all permit_*
> restrictions from the global configuration.  Don't advertise nor
> accept AUTH on port 25.
>
> Do not accept mail exchange on port 587.
>
> main.cf:
> ...
> smtpd_relay_restrictions = reject_unauth_destination
> submission_relay_restrictions = permit_sasl_authenticated, reject
> # smtpd_sasl_auth_enable is "no" by default, so omit that, but
> # other smtpd_sasl_* settings can go here
> ...
>
> master.cf:
> ...
> submission inet  n       -       n       -       -       smtpd
>    -o smtpd_tls_auth_only=yes
>    -o smtpd_sasl_auth_enable=yes
>    -o smtpd_recipient_restrictions=
>    -o smtpd_relay_restrictions=$submission_relay_restrictions
>    -o milter_macro_daemon_name=ORIGINATING
>    -o syslog_name=postfix/submission
> ...
>
> (That example assumes that TLS is set up for smtpd.)
>
> Yes, someone can still  "telnet" to port 25 and send mail to your
> addresses/users.  That's what mail exchange is.  Nothing is magic
> about telnet, it is just one of many ways to make a TCP connection.
> That's the same thing a MTA client will do when delivering mail on
> behalf of their user to one of your addresses.
> --
>  http://rob0.nodns4.us/
>  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Reply | Threaded
Open this post in threaded view
|

Re: Telnet auth

Tobi
If you do not accept submission on port 25, you could add a
sender_access map to the service on port 25

smtpd_sender_restrictions =
...
 check_sender_access hash:/etc/postfix/sender_access
...

and in said file list your domains each with action "reject"

Am 18.05.2016 um 12:22 schrieb Catalin Badirca:

> Thank you very much for your time and sorry for the long response time.
>
> I've tried your suggestion and the issue remains. Someone could telnet into postfix and would be allowed to send mails from a valid address to another valid address in mydomain without authentication.
>
> Is there any way I can stop potential spam for mydomain ?
>
> Thabk you !
>
> Sent from my iPhone
>
>> On 16 May 2016, at 20:21, /dev/rob0 <[hidden email]> wrote:
>>
>>> On Mon, May 16, 2016 at 07:25:54PM +0300, Catalin Badirca wrote:
>>> I am breaking my head trying to solve the following thing. I have a
>>> Postfix server that accepts mail from $mydomain and delivers for
>>
>> "From $mydomain" probably has nothing to do with it.
>>
>>> standard $mydestination. I also have smtp_relay_redtriction to
>>
>> smtpd_relay_restrictions, spelling DOES count, and be especially
>> aware of the "smtp_* != smtpd_" issue.
>>
>>> allow sasl and reject other destinations than $mydomain. Standard
>>
>> s/mydomain/mydestination/ , that is.
>>
>>> until now. The thing is: if i telnet to the machine and try to send
>>> mail from a valid address to another valid address in $mydomain i
>>> can do it without beeing forced to authenticate. I can easily force
>>> reject instead of reject_unauth_destination and tale care of this
>>> but then no emails for me.
>>>
>>> Does anyone know a solution for this please ?
>>
>> It's quite simple, actually.
>>
>> Do not accept user submission on port 25.  Remove all permit_*
>> restrictions from the global configuration.  Don't advertise nor
>> accept AUTH on port 25.
>>
>> Do not accept mail exchange on port 587.
>>
>> main.cf:
>> ...
>> smtpd_relay_restrictions = reject_unauth_destination
>> submission_relay_restrictions = permit_sasl_authenticated, reject
>> # smtpd_sasl_auth_enable is "no" by default, so omit that, but
>> # other smtpd_sasl_* settings can go here
>> ...
>>
>> master.cf:
>> ...
>> submission inet  n       -       n       -       -       smtpd
>>    -o smtpd_tls_auth_only=yes
>>    -o smtpd_sasl_auth_enable=yes
>>    -o smtpd_recipient_restrictions=
>>    -o smtpd_relay_restrictions=$submission_relay_restrictions
>>    -o milter_macro_daemon_name=ORIGINATING
>>    -o syslog_name=postfix/submission
>> ...
>>
>> (That example assumes that TLS is set up for smtpd.)
>>
>> Yes, someone can still  "telnet" to port 25 and send mail to your
>> addresses/users.  That's what mail exchange is.  Nothing is magic
>> about telnet, it is just one of many ways to make a TCP connection.
>> That's the same thing a MTA client will do when delivering mail on
>> behalf of their user to one of your addresses.
>> --
>>  http://rob0.nodns4.us/
>>  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: Telnet auth

D'Arcy Cain
In reply to this post by Catalin Badirca
On Wed, 18 May 2016 13:22:49 +0300
Catalin Badirca <[hidden email]> wrote:
> I've tried your suggestion and the issue remains. Someone could
> telnet into postfix and would be allowed to send mails from a valid
> address to another valid address in mydomain without authentication.
>
> Is there any way I can stop potential spam for mydomain ?

What do you mean by "telnet into postfix"?  Are you saying that valid
users on your system are spamming your other users?  All you can do
there is monitor your own house and slap anyone who does that.  It
doesn't matter whether they spam their fellow users or the whole world.
your users are your responsibility but that's not a technical issue.

If you mean that someone can connect to your port 25 and send your
users spam then yes, welcome to the twenty-first century and the spam
problem that everyone is fighting.  That's the daily fight we all
have.  There are a number of spam mitigation techniques that you can
try.  None of them are 100% effective.  You can block known spam sites,
use SPF, greylisting and other tools to slow down spam at the SMTP
level and spamassassin, bogofilter and other filters after to catch
suspected spam after it is accepted.  Look at spam-fighting sites for
some ideas.

If you do find a way to block 100% of all spam please tell us how.
Better yet, package it and sell it.  You will be a billionaire.

--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:[hidden email]
VoIP: sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Telnet auth

Wietse Venema
In reply to this post by Tobi
A brief example:

/etc/postfix/sender_access:
    example.com reject Sender address requires authentication
    other.example reject Sender address requires authentication

Do "postmap /etc/postfix/sender_access", then add this to main.cf:

smtpd_sender_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    check_sender_access hash:/etc/postfix/sender_access

With this, only senders in a trusted network, or authenticated
senders, can do "MAIL FROM:<[hidden email]>" etc.

This does not restrict the address in the From: message header.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Telnet auth

Wietse Venema
Wietse Venema:

> A brief example:
>
> /etc/postfix/sender_access:
>     example.com reject Sender address requires authentication
>     other.example reject Sender address requires authentication
>
> Do "postmap /etc/postfix/sender_access", then add this to main.cf:
>
> smtpd_sender_restrictions =
>     permit_mynetworks
>     permit_sasl_authenticated
>     check_sender_access hash:/etc/postfix/sender_access
>
> With this, only senders in a trusted network, or authenticated
> senders, can do "MAIL FROM:<[hidden email]>" etc.
>
> This does not restrict the address in the From: message header.

BTW this means that you have to do your "telnet" tests from a
remote IP address!

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Telnet auth

Catalin Badirca
In reply to this post by D'Arcy Cain
I will try to be more specific. Create an test account that can send emails from postfix. Telnet on the postfix machine on port 25. Now send an email from that test account to any other valid email on your domain. You will see that you are allowed to do so without authentication. The whole world can do that.
I don't think you will want emails to be sent on your user's behalf inside your domain.

Is there any way postfix can stop that ?


> On 18 May 2016, at 14:08, D'Arcy J.M. Cain <[hidden email]> wrote:
>
> On Wed, 18 May 2016 13:22:49 +0300
> Catalin Badirca <[hidden email]> wrote:
>> I've tried your suggestion and the issue remains. Someone could
>> telnet into postfix and would be allowed to send mails from a valid
>> address to another valid address in mydomain without authentication.
>>
>> Is there any way I can stop potential spam for mydomain ?
>
> What do you mean by "telnet into postfix"?  Are you saying that valid
> users on your system are spamming your other users?  All you can do
> there is monitor your own house and slap anyone who does that.  It
> doesn't matter whether they spam their fellow users or the whole world.
> your users are your responsibility but that's not a technical issue.
>
> If you mean that someone can connect to your port 25 and send your
> users spam then yes, welcome to the twenty-first century and the spam
> problem that everyone is fighting.  That's the daily fight we all
> have.  There are a number of spam mitigation techniques that you can
> try.  None of them are 100% effective.  You can block known spam sites,
> use SPF, greylisting and other tools to slow down spam at the SMTP
> level and spamassassin, bogofilter and other filters after to catch
> suspected spam after it is accepted.  Look at spam-fighting sites for
> some ideas.
>
> If you do find a way to block 100% of all spam please tell us how.
> Better yet, package it and sell it.  You will be a billionaire.
>
> --
> D'Arcy J.M. Cain
> System Administrator, Vex.Net
> http://www.Vex.Net/ IM:[hidden email]
> VoIP: sip:[hidden email]

Reply | Threaded
Open this post in threaded view
|

SV: Telnet auth

Sebastian Nielsen
Yes.
Remove permit_sasl_authenticated and permit_mynetworks.
Then add the following rule instead, immediately BEFORE
reject_unauth_destination:
check_sender_access hash:/etc/postfix/relay_auth

Inside the file relay_auth, which must be postmap:ed, you have the
following:

yourdomain.com: permit_sasl_authenticated, reject

This means when a outsider tries to send from lets say [hidden email]
to [hidden email] without authentication, the rule evaluated will
be:
" permit_sasl_authenticated, reject, reject_unauth_destination"
The word "reject" comes before "reject_unauth_destination", thus the mail
will be rejected despite being to a allowed domain.
If you instead tries to send from a non-"yourdomain.com" domain, then the
check_sender_access will be skipped, and you will be allowed to send mail to
local accounts.

This also have another advantage: authenticated accounts CANNOT send from
another domain than your domain.

You can try for yourself. Try telnetting to this server: dns2.sebbe.eu which
is my mail server.
Then try to see if you can send spoofed mail originating from some account
inside @sebbe.eu to [hidden email]

(I however use IP authentication, eg only mynetworks are allowed to relay,
instead of account authentication)

-----Ursprungligt meddelande-----
Från: [hidden email]
[mailto:[hidden email]] För Catalin Badirca
Skickat: den 18 maj 2016 20:53
Till: D'Arcy J.M. Cain <[hidden email]>
Kopia: [hidden email]
Ämne: Re: Telnet auth

I will try to be more specific. Create an test account that can send emails
from postfix. Telnet on the postfix machine on port 25. Now send an email
from that test account to any other valid email on your domain. You will see
that you are allowed to do so without authentication. The whole world can do
that.
I don't think you will want emails to be sent on your user's behalf inside
your domain.

Is there any way postfix can stop that ?


> On 18 May 2016, at 14:08, D'Arcy J.M. Cain <[hidden email]> wrote:
>
> On Wed, 18 May 2016 13:22:49 +0300
> Catalin Badirca <[hidden email]> wrote:
>> I've tried your suggestion and the issue remains. Someone could
>> telnet into postfix and would be allowed to send mails from a valid
>> address to another valid address in mydomain without authentication.
>>
>> Is there any way I can stop potential spam for mydomain ?
>
> What do you mean by "telnet into postfix"?  Are you saying that valid
> users on your system are spamming your other users?  All you can do
> there is monitor your own house and slap anyone who does that.  It
> doesn't matter whether they spam their fellow users or the whole world.
> your users are your responsibility but that's not a technical issue.
>
> If you mean that someone can connect to your port 25 and send your
> users spam then yes, welcome to the twenty-first century and the spam
> problem that everyone is fighting.  That's the daily fight we all
> have.  There are a number of spam mitigation techniques that you can
> try.  None of them are 100% effective.  You can block known spam
> sites, use SPF, greylisting and other tools to slow down spam at the
> SMTP level and spamassassin, bogofilter and other filters after to
> catch suspected spam after it is accepted.  Look at spam-fighting
> sites for some ideas.
>
> If you do find a way to block 100% of all spam please tell us how.
> Better yet, package it and sell it.  You will be a billionaire.
>
> --
> D'Arcy J.M. Cain
> System Administrator, Vex.Net
> http://www.Vex.Net/ IM:[hidden email]
> VoIP: sip:[hidden email]


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SV: Telnet auth

Catalin Badirca
This is what I was looking for. Thank you very very much Sebastien. I will try it right now and will post the result.

Sent from my iPhone

> On 18 May 2016, at 22:07, Sebastian Nielsen <[hidden email]> wrote:
>
> Yes.
> Remove permit_sasl_authenticated and permit_mynetworks.
> Then add the following rule instead, immediately BEFORE
> reject_unauth_destination:
> check_sender_access hash:/etc/postfix/relay_auth
>
> Inside the file relay_auth, which must be postmap:ed, you have the
> following:
>
> yourdomain.com: permit_sasl_authenticated, reject
>
> This means when a outsider tries to send from lets say [hidden email]
> to [hidden email] without authentication, the rule evaluated will
> be:
> " permit_sasl_authenticated, reject, reject_unauth_destination"
> The word "reject" comes before "reject_unauth_destination", thus the mail
> will be rejected despite being to a allowed domain.
> If you instead tries to send from a non-"yourdomain.com" domain, then the
> check_sender_access will be skipped, and you will be allowed to send mail to
> local accounts.
>
> This also have another advantage: authenticated accounts CANNOT send from
> another domain than your domain.
>
> You can try for yourself. Try telnetting to this server: dns2.sebbe.eu which
> is my mail server.
> Then try to see if you can send spoofed mail originating from some account
> inside @sebbe.eu to [hidden email]
>
> (I however use IP authentication, eg only mynetworks are allowed to relay,
> instead of account authentication)
>
> -----Ursprungligt meddelande-----
> Från: [hidden email]
> [mailto:[hidden email]] För Catalin Badirca
> Skickat: den 18 maj 2016 20:53
> Till: D'Arcy J.M. Cain <[hidden email]>
> Kopia: [hidden email]
> Ämne: Re: Telnet auth
>
> I will try to be more specific. Create an test account that can send emails
> from postfix. Telnet on the postfix machine on port 25. Now send an email
> from that test account to any other valid email on your domain. You will see
> that you are allowed to do so without authentication. The whole world can do
> that.
> I don't think you will want emails to be sent on your user's behalf inside
> your domain.
>
> Is there any way postfix can stop that ?
>
>
>> On 18 May 2016, at 14:08, D'Arcy J.M. Cain <[hidden email]> wrote:
>>
>> On Wed, 18 May 2016 13:22:49 +0300
>> Catalin Badirca <[hidden email]> wrote:
>>> I've tried your suggestion and the issue remains. Someone could
>>> telnet into postfix and would be allowed to send mails from a valid
>>> address to another valid address in mydomain without authentication.
>>>
>>> Is there any way I can stop potential spam for mydomain ?
>>
>> What do you mean by "telnet into postfix"?  Are you saying that valid
>> users on your system are spamming your other users?  All you can do
>> there is monitor your own house and slap anyone who does that.  It
>> doesn't matter whether they spam their fellow users or the whole world.
>> your users are your responsibility but that's not a technical issue.
>>
>> If you mean that someone can connect to your port 25 and send your
>> users spam then yes, welcome to the twenty-first century and the spam
>> problem that everyone is fighting.  That's the daily fight we all
>> have.  There are a number of spam mitigation techniques that you can
>> try.  None of them are 100% effective.  You can block known spam
>> sites, use SPF, greylisting and other tools to slow down spam at the
>> SMTP level and spamassassin, bogofilter and other filters after to
>> catch suspected spam after it is accepted.  Look at spam-fighting
>> sites for some ideas.
>>
>> If you do find a way to block 100% of all spam please tell us how.
>> Better yet, package it and sell it.  You will be a billionaire.
>>
>> --
>> D'Arcy J.M. Cain
>> System Administrator, Vex.Net
>> http://www.Vex.Net/ IM:[hidden email]
>> VoIP: sip:[hidden email]
>
>

Reply | Threaded
Open this post in threaded view
|

Re: SV: Telnet auth

/dev/rob0
In reply to this post by Sebastian Nielsen
Catalin Badirca <[hidden email]> wrote:
> I will try to be more specific. Create an test account that can
> send emails from postfix.

Send THROUGH Postfix is more accurate wording than send FROM.  Also,
creation of the account does not matter.  By default there is no
checking of sender addresses.

> Telnet on the postfix machine on port 25. Now send an email from
> that test account to any other valid email on your domain. You will
> see that you are allowed to do so without authentication. The whole
> world can do that. I don't think you will want emails to be sent on
> your user's behalf inside your domain.

Less common now than in years past, but there are still some
legitimate reasons why this can happen.  Anyway, now your goal is
clear.

> Is there any way postfix can stop that ?

On Wed, May 18, 2016 at 09:07:44PM +0200, Sebastian Nielsen wrote:

> Yes.
> Remove permit_sasl_authenticated and permit_mynetworks.
> Then add the following rule instead, immediately BEFORE
> reject_unauth_destination:
> check_sender_access hash:/etc/postfix/relay_auth
>
> Inside the file relay_auth, which must be postmap:ed, you have the
> following:
>
> yourdomain.com: permit_sasl_authenticated, reject

Two errors in that.  First, the colon is wrong.  Second, multiple
results are not possible except when using restriction classes (and
then, the result is still single: it's the name of the class.)

The OP continues to ask this question after it has been answered.
Refer back to Wietse's example given yesterday.  It was missing from
my prior post because the actual goal, to prevent receipt of mail
claiming to be from users@$mydomain from outside, was not yet clear.

However, I still recommend separation of inbound mail exchange from
user-submitted mail, and this matter becomes more simple: just don't
accept senders@$mydomain on port 25.

> This means when a outsider tries to send from lets say
> [hidden email] to [hidden email] without
> authentication, the rule evaluated will be:
> " permit_sasl_authenticated, reject, reject_unauth_destination"

Again, this can only happen with restriction classes.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

SV: SV: Telnet auth

Sebastian Nielsen
It is actually possible to use multiple results when using the built-in
restriction commands (permit_sasl_authentication, permit_mynetworks, reject,
etc)
(Eg, words that can be used in the rules chain instead of
"check_sender_access")

Then they will be inserted in the rule chain just where the
check_sender_access is,
Using processing commands like DISCARD can however only be used in single.

And colon is used when using a hash:
Look in your /etc/aliases and you will see.

Im using "permit_mynetworks, reject" in my check_sender_access without
problems. And it works exactly as expected, nobody can send a email with a
sender of @sebbe.eu , not even to a local domain, if they aren't inside
mynetworks.
Combined with a couple of DISCARD's for spammy top TLD's like .xyz, .bid,
.date.

-----Ursprungligt meddelande-----
Från: [hidden email]
[mailto:[hidden email]] För /dev/rob0
Skickat: den 18 maj 2016 22:36
Till: [hidden email]
Ämne: Re: SV: Telnet auth


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SV: SV: Telnet auth

Noel Jones-2
On 5/18/2016 3:46 PM, Sebastian Nielsen wrote:
> It is actually possible to use multiple results when using the built-in
> restriction commands (permit_sasl_authentication, permit_mynetworks, reject,
> etc)
> (Eg, words that can be used in the rules chain instead of
> "check_sender_access")
>
> Then they will be inserted in the rule chain just where the
> check_sender_access is,
> Using processing commands like DISCARD can however only be used in single.

This is correct.  Multiple "simple" actions are allowed in an access
map result. (not sure where this is documented)

>
> And colon is used when using a hash:
> Look in your /etc/aliases and you will see.

Half wrong.  The ":" colon is specific to an alias file, and not
used / not valid for an access table.  This has nothing to do with
hash: table types.
http://www.postfix.org/aliases.5.html


  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

SV: SV: SV: Telnet auth

Sebastian Nielsen
Aah now I see. I tought colon between the key and value was something
specific to hash.
But strangely, it works both with/without colon too.
Maybe its how postmap parses the file.

However, the OPs problem is solved.

-----Ursprungligt meddelande-----
Från: [hidden email]
[mailto:[hidden email]] För Noel Jones
Skickat: den 18 maj 2016 23:28
Till: [hidden email]
Ämne: Re: SV: SV: Telnet auth

On 5/18/2016 3:46 PM, Sebastian Nielsen wrote:

> It is actually possible to use multiple results when using the
> built-in restriction commands (permit_sasl_authentication,
> permit_mynetworks, reject,
> etc)
> (Eg, words that can be used in the rules chain instead of
> "check_sender_access")
>
> Then they will be inserted in the rule chain just where the
> check_sender_access is, Using processing commands like DISCARD can
> however only be used in single.
This is correct.  Multiple "simple" actions are allowed in an access map
result. (not sure where this is documented)

>
> And colon is used when using a hash:
> Look in your /etc/aliases and you will see.

Half wrong.  The ":" colon is specific to an alias file, and not used / not
valid for an access table.  This has nothing to do with
hash: table types.
http://www.postfix.org/aliases.5.html


  -- Noel Jones


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SV: SV: Telnet auth

Wietse Venema
In reply to this post by Noel Jones-2
Noel Jones:
[ Charset windows-1252 converted... ]

> On 5/18/2016 3:46 PM, Sebastian Nielsen wrote:
> > It is actually possible to use multiple results when using the built-in
> > restriction commands (permit_sasl_authentication, permit_mynetworks, reject,
> > etc)
> > (Eg, words that can be used in the rules chain instead of
> > "check_sender_access")
> >
> > Then they will be inserted in the rule chain just where the
> > check_sender_access is,
> > Using processing commands like DISCARD can however only be used in single.
>
> This is correct.  Multiple "simple" actions are allowed in an access
> map result. (not sure where this is documented)

In the access(5) manpage.

ACCEPT ACTIONS
        ...
REJECT ACTIONS
        ...
OTHER ACTIONS
       restriction...
              Apply    the   named   UCE   restriction(s)   (permit,   reject,
              reject_unauth_destination, and so on).

Not quite sure what to change here.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Telnet auth

Richard James Salts
In reply to this post by Wietse Venema
On 19/05/16 00:38, Wietse Venema wrote:

> Wietse Venema:
>> A brief example:
>>
>> /etc/postfix/sender_access:
>>      example.com reject Sender address requires authentication
>>      other.example reject Sender address requires authentication
>>
>> Do "postmap /etc/postfix/sender_access", then add this to main.cf:
>>
>> smtpd_sender_restrictions =
>>      permit_mynetworks
>>      permit_sasl_authenticated
>>      check_sender_access hash:/etc/postfix/sender_access
>>
>> With this, only senders in a trusted network, or authenticated
>> senders, can do "MAIL FROM:<[hidden email]>" etc.
>>
>> This does not restrict the address in the From: message header.
> BTW this means that you have to do your "telnet" tests from a
> remote IP address!
>
> Wietse
And it will also break forwarding for your users. e.g. [hidden email]
sends to a mailing list
that they're a member of and the mailing list doesn't alter the envelope
sender, or sends to their friend
at [hidden email] who has their mail forwarded back to
[hidden email]. A way to
allow this but prevent forgeries would be to set up DKIM or BATV and
reject email with an invalid signature
for the email or the envelope sender.
Reply | Threaded
Open this post in threaded view
|

SV: Telnet auth

Sebastian Nielsen
Yeah, it do break forwarding where stupid mailservers (or more correctly,
mailservers configured by stupid admins) just forward the mail verbatim, and
even forge the MAIL FROM to the destination server.

That is the thing that causes SPF to fail when for example:
My server --> Receivers Company server --> Receivers Private address (not
DKIM aware).

And "Receivers Company server" is stupidly configured and forges the MAIL
FROM (instead of replacing it with a own address), and thus the Private
server reject the mail due to a SPF failure, which causes the "Receivers
Company Server" to return a DSN (since it knows that SPF is OK from their
point of view) where private server complains on the SPF. OFCOURSE the
"Receivers Company server" is not authorized to send with my domain as MAIL
FROM according to my SPF record, SPF works exactly as expected.

Same with this policy suggestion with rejecting local forgeries. Its nothing
wrong with such a policy, it’s the forwarding mailserver that are doing
things wrong if the mail gets rejected due to forwarding.

Yes, forwarders could use Sender Rewriting Scheme, but better is to actually
rewrite the mail to be able to pass the SPF policy from their own point of
view,  eg rewrite MAIL FROM to actually contain the address the mail was
originally sent to.
Like a mail sent MAIL FROM [hidden email] to [hidden email]
should be forwarded as MAIL FROM [hidden email] to
[hidden email]


So if this breaks forwarding in some cases, blame it on the servers who are
forwarding the mail. Have had a few such failures when I send mail due to my
"Reject local forgeries" and SPF policy, then I have wrote a oozing mail to
the postmaster of the forwarding server where I tell them why their server
is so badly misconfigured. In some cases they have fixed the problem, and in
other cases they told me that it would break <insert something else> here
(for example filter rules).


>Wietse:
The advantage with my example (Where I use permit_mynetworks or
permit_sasl_authenticated inside the sender_access file in addition to
reject), is that authenticated senders cannot spoof the sender domain to
something else either. So if [hidden email] tries to send as
[hidden email] to a remote receiver (relaying), the
permit_sasl_authenticated will never be returned by the sender_access file,
and thus it will not accept the mail.
This can then be combined with the policy that only allows authenticated
senders to send as the same username as they have logged on with, which then
makes a rock solid defense against spambots running on client computers, as
they will be forced to send as the original user, and the problem can be
traced much more easily when abuse happens.


-----Ursprungligt meddelande-----
Från: [hidden email]
[mailto:[hidden email]] För Richard James Salts
Skickat: den 19 maj 2016 01:07
Till: [hidden email]
Ämne: Re: Telnet auth

On 19/05/16 00:38, Wietse Venema wrote:

> Wietse Venema:
>> A brief example:
>>
>> /etc/postfix/sender_access:
>>      example.com reject Sender address requires authentication
>>      other.example reject Sender address requires authentication
>>
>> Do "postmap /etc/postfix/sender_access", then add this to main.cf:
>>
>> smtpd_sender_restrictions =
>>      permit_mynetworks
>>      permit_sasl_authenticated
>>      check_sender_access hash:/etc/postfix/sender_access
>>
>> With this, only senders in a trusted network, or authenticated
>> senders, can do "MAIL FROM:<[hidden email]>" etc.
>>
>> This does not restrict the address in the From: message header.
> BTW this means that you have to do your "telnet" tests from a remote
> IP address!
>
> Wietse
And it will also break forwarding for your users. e.g. [hidden email]
sends to a mailing list that they're a member of and the mailing list
doesn't alter the envelope sender, or sends to their friend at
[hidden email] who has their mail forwarded back to [hidden email].
A way to allow this but prevent forgeries would be to set up DKIM or BATV
and reject email with an invalid signature for the email or the envelope
sender.


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SV: SV: Telnet auth

/dev/rob0
In reply to this post by Wietse Venema
On Wed, May 18, 2016 at 06:47:45PM -0400, Wietse Venema wrote:

> Noel Jones:
> [ Charset windows-1252 converted... ]
> > On 5/18/2016 3:46 PM, Sebastian Nielsen wrote:
> > > It is actually possible to use multiple results when using the
> > > built-in restriction commands (permit_sasl_authentication,
> > > permit_mynetworks, reject, etc)
> > > (Eg, words that can be used in the rules chain instead of
> > > "check_sender_access")
> > >
> > > Then they will be inserted in the rule chain just where the
> > > check_sender_access is,
> > > Using processing commands like DISCARD can however only be used
> > > in single.
> >
> > This is correct.  Multiple "simple" actions are allowed in an
> > access map result. (not sure where this is documented)
>
> In the access(5) manpage.
>
> ACCEPT ACTIONS
> ...
> REJECT ACTIONS
> ...
> OTHER ACTIONS
>        restriction...
>               Apply  the  named  UCE  restriction(s) (permit,
>               reject,  reject_unauth_destination,  and so on).
>
> Not quite sure what to change here.

Ah, that's clear, and sorry, I missed that.

My confusion came from the RESTRICTION_CLASS_README, "... you can't
specify a lookup table on the RHS ...", which I misremembered.

Thanks Noel, Sebastian, and Wietse.

While we're on the matter, however, is "UCE restriction" a proper
term to use here?  I'd suggest that "UCE" is never proper.  Are these
not more properly called just "restrictions"?
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: SV: Telnet auth

sercoinful
In reply to this post by Sebastian Nielsen
Hi,

I'm trying to use configuration like below. But authentication from local to
local via telnet still not working. Anyone could send mail to local from
local via telnet. Which part is not correct?

main.cf
smtpd_recipient_restrictions = permit_sasl_authenticated,
reject_unauth_destination
smtpd_sender_restrictions = permit_sasl_authenticated, check_sender_access
hash:/etc/postfix/sender_access

/etc/postfix/sender_access
xdomain.com reject_unverified_sender
ydomain.com reject_unverified_sender

Regards



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Reply | Threaded
Open this post in threaded view
|

Re: SV: Telnet auth

Wietse Venema
sercoinful:
> Hi,
>
> I'm trying to use configuration like below. But authentication from local to
> local via telnet still not working. Anyone could send mail to local from
> local via telnet. Which part is not correct?

I see no 'reject' action in the rule with 'permit_sasl_authenticated'

        Wietse

> main.cf
> smtpd_recipient_restrictions = permit_sasl_authenticated,
> reject_unauth_destination
> smtpd_sender_restrictions = permit_sasl_authenticated, check_sender_access
> hash:/etc/postfix/sender_access
>
> /etc/postfix/sender_access
> xdomain.com reject_unverified_sender
> ydomain.com reject_unverified_sender
>
> Regards
>
>
>
> --
> Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
>
12