Re: SV: Telnet auth

[sercoinful]

Hi,

When I replace "reject_unverified_sender" to "reject" it works. Thanks.

Regards



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

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
> 

Re: SV: Telnet auth

[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?

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

Re: SV: SV: Telnet auth

[/dev/rob0]

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:

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 sebast...@sebbe.eu to somegr...@mycompany.org
should be forwarded as MAIL FROM somegr...@mycompany.org to
finaldestinat...@privateserver.org 


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  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 us...@example.com tries to send as
rolexwatc...@watchcompany.com 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: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Richard James Salts
Skickat: den 19 maj 2016 01:07
Till: postfix-users@postfix.org
Ä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:<u...@example.com>" 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. u...@example.com
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
user2@alumni.example who has their mail forwarded back to us...@example.com.
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
Description: S/MIME Cryptographic Signature

Re: Telnet auth

[Richard James Salts]

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

Wietse Venema:

A brief example:

/etc/postfix/sender_access:
 example.comreject 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:" 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. u...@example.com 
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 user2@alumni.example who has their mail forwarded back to 
us...@example.com. 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.

Re: SV: SV: Telnet auth

[Wietse Venema]

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...
  Applythe   named   UCE   restriction(s)   (permit,   reject,
  reject_unauth_destination, and so on).

Not quite sure what to change here.

Wietse

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: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Noel Jones
Skickat: den 18 maj 2016 23:28
Till: postfix-users@postfix.org
Ä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
Description: S/MIME Cryptographic Signature

Re: SV: SV: Telnet auth

[Noel Jones]

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

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: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För /dev/rob0
Skickat: den 18 maj 2016 22:36
Till: postfix-users@postfix.org
Ämne: Re: SV: Telnet auth



smime.p7s
Description: S/MIME Cryptographic Signature

Re: SV: Telnet auth

[/dev/rob0]

Catalin Badirca  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 
> t...@yourdomain.com to someot...@yourdomain.com 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:

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 <sebast...@sebbe.eu> 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 t...@yourdomain.com
> to someot...@yourdomain.com 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 sebast...@sebbe.eu
> 
> (I however use IP authentication, eg only mynetworks are allowed to relay,
> instead of account authentication)
> 
> -Ursprungligt meddelande-
> Från: owner-postfix-us...@postfix.org
> [mailto:owner-postfix-us...@postfix.org] För Catalin Badirca
> Skickat: den 18 maj 2016 20:53
> Till: D'Arcy J.M. Cain <da...@vex.net>
> Kopia: postfix-users@postfix.org
> Ä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 <da...@vex.net> wrote:
>> 
>> On Wed, 18 May 2016 13:22:49 +0300
>> Catalin Badirca <badi...@yahoo.com> 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:da...@vex.net
>> VoIP: sip:da...@vex.net
> 
> 

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 t...@yourdomain.com
to someot...@yourdomain.com 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 sebast...@sebbe.eu

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

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Catalin Badirca
Skickat: den 18 maj 2016 20:53
Till: D'Arcy J.M. Cain <da...@vex.net>
Kopia: postfix-users@postfix.org
Ä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 <da...@vex.net> wrote:
> 
> On Wed, 18 May 2016 13:22:49 +0300
> Catalin Badirca <badi...@yahoo.com> 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:da...@vex.net
> VoIP: sip:da...@vex.net




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Telnet auth

[Catalin Badirca]

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  wrote:
> 
> On Wed, 18 May 2016 13:22:49 +0300
> Catalin Badirca  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:da...@vex.net
> VoIP: sip:da...@vex.net

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:" 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

Re: Telnet auth

[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:" etc.

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

Wietse

Re: Telnet auth

[D'Arcy J.M. Cain]

On Wed, 18 May 2016 13:22:49 +0300
Catalin Badirca  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:da...@vex.net
VoIP: sip:da...@vex.net

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  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:

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  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:

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:

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 !