Re: SV: Telnet auth
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
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
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
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
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, its 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:" 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: SV: SV: Telnet auth
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
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
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
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
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
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 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 > 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 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 > >
SV: Telnet auth
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 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 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 smime.p7s Description: S/MIME Cryptographic Signature