Security: How to limit authentication attempts?

[Kiss Gábor]

Dear folks,

My logs are full of lines like this:

Feb 21 04:12:05 MYOLDMTA postfix/smtpd[12967]: warning: 
unknown[195.22.126.159]: SASL LOGIN authentication failed: authentication 
failure

This is a brute force attack in order to get a valid username/password pair.
The cracker usually does 20 attempts within a single SMTP session.
Thought fail2ban alerts the firewall after the third or fourth one but
network filtering applies to new connections only.
(I would not filter _all_ incoming packets until it is
absolutely necessary.)

So the attacker may try any number of password quite unobtrusively.

Is there any way to instruct smtpd to close session after 3 unsuccesful
attempts as is written in RFC 4954? I found no appropriate config parameter.

https://tools.ietf.org/html/rfc4954#section-9
   Servers MAY implement a policy whereby the connection is dropped
   after a number of failed authentication attempts.  If they do so,
   they SHOULD NOT drop the connection until at least 3 attempts to
   authenticate have failed.

The affected Postfix version is 2.11.3, our old MTA.
The new one is not found yet by the bad guys.

Regards

Gabor

How to use a local postfix server for outgoing mail only

[Tom Browder]

I want to use my local host as a mail server for outgoing mail only.  For
example, send mail to my gmail address with no intervening smtp server
except that on my local host.

How can that be done?

Thanks.

Best regards,

-Tom

Re: A bug, maybe?

[Curtis Maurand]

On 2/20/2016 1:46 PM, Viktor Dukhovni wrote:

On Sat, Feb 20, 2016 at 01:37:39PM -0500, Curtis Maurand wrote:


Nothing is chrooted.  resolv.conf is world readable.  Wietse's program
returns a valid address.  It might not match the reverse, but it did return
an address.
# ./getaddr delivery.mailspamprotection.com
Hostname:   delivery.mailspamprotection.com
Addresses:  108.163.228.171

There's your problem, it is supposed to return *all* the addresses.  On
my system:

 $ ./getaddrinfo delivery.mailspamprotection.com
 Hostname:   delivery.mailspamprotection.com
 Addresses:  108.163.220.52 108.163.201.229 69.175.69.94 
108.163.204.150 198.143.161.10 108.163.201.230 96.127.190.5 184.154.58.227 
198.143.161.21 184.154.48.173 198.143.161.29 69.175.69.92 108.163.243.190 
96.127.190.4 198.143.161.30 108.178.24.182 108.163.243.188 108.163.228.171 
69.175.69.93 184.154.208.34 184.154.208.36 96.127.176.253 96.127.190.2 
198.143.161.27 108.163.220.54 198.143.161.11 108.163.228.170 198.143.161.13 
184.154.58.230 108.163.243.189 108.163.228.174 108.163.201.228 108.178.24.171 
108.163.201.226 108.178.24.181 108.163.201.227 184.154.208.37 108.178.24.174 
198.143.161.12 184.154.48.171 96.127.176.250 108.163.243.186 108.178.24.180 
69.175.69.90 108.163.243.187 108.163.228.172 96.127.176.252 184.154.177.50 
184.154.48.172 108.163.204.148 198.143.161.28 108.163.204.146 184.154.208.35 
108.163.204.149 96.127.190.6 69.175.69.91 184.154.58.226 108.163.228.173 
108.178.24.173 108.178.24.178 96.127.176.254 198.143.161.18 184.154.48.174 
198.143.161.20 184.154.58.229 108.163.220.51 96.127.176.251 108.163.220.50 
108.178.24.170 108.163.220.53 198.143.161.22 184.154.208.38 184.154.48.170 
184.154.58.228 108.178.24.172 198.143.161.14 108.178.24.179 198.143.161.19 
108.163.204.147 198.143.161.26 96.127.190.3

If your getaddrinfo returns only the first address, it is busted.
Perhaps this is controlled via /etc/hosts.conf:

 http://www.linfo.org/etc_host_conf.html

 /etc/hosts.conf:
multi on


That said.  Since the unit has been updated, but not rebooted, I may need to
reboot to get the kernel fix.  Ubuntu does, at least, backport fixes.

The getaddrinfo issue is not resolved via a kernel fix, it is
addressed via a glibc fix.


interesting.  on my 12.04 mail server it works correctly.  on the 14.04 
server it is not.  both have "multi on" set.  I fired up another virtual 
machine with 14.04 installed and that one works fine.  As a work around, 
I've set my mx to the 12.04 machine that works with a transport command 
that sends the mail to the host that should be receiving the mail.  the 
machine that is not working right claims to not have any updates 
available, thought the getaddrinfo() has been patched.  frustrating.  
Thank you for your help.  The problem appears to not be postfix.



--
Curtis Maurand
cur...@maurand.com 
207-252-7748

Re: SV: SV: SV: SV: Blocking TLDs

[Marco]

Hello all.

In some countries e-mails are subject to the same rules as physical
mail, and the destruction or non-delivery is a criminal offence. Just to
mention there are i.e. countries in which you need the authorization of
a judge to access the mailbox of an user, or you are not authorized to
track the e-mail traffic of an enterprise unless evidence of a misuse is
available. And so on and so forth, e-mail rules are really country related.

The only common rule, in all laws I have seen, is related to the
detection of a risk, that allows everywhere a protective attitude. This
means that mails can be not delivered, but this does not implies they
can be destroyed, as some countries do require a complete logging of the
e-mail traffic (I'm for the FLAME ON with the regulators that did
take this decision, don't blame me...)

There is no valid general statement concerning this question, it really
depends from where your servers are located.

Marco



Il 20. 02. 16 15:01, Sebastian Nielsen ha scritto:
> I readed that on wikipedia, and readed the sources, and one thing I can say,
> is that the source is heavily misinterpreted. They refer to physical mail,
> and telecommunication, where a set of rules apply to physical mail, and some
> other set apply to telecommunication.
> Of course, you are not allowed to tamper with third-party communication, but
> if you run a mail server, then you are "in the loop" and are permitted to do
> whatever you want. Nobody forces you to accept whatever you don't want into
> your network. If you want to toss all HTML mail destined for your company
> into /dev/null, its up to you.
> This provided that you didn't unauthorizedly insert yourself into the loop.
> If a end user select to use you as mail service, they have to abide by your
> rules, including that some mails might get tossed away. But if you force
> somebody, which aren't using your network, to use your mail service, for
> example via ARP spoofing or fake Wifi AP's, then its computer intrusion.
>
> Also, the law does not make any difference on reject or discard, either you
> are allowed to block, and then it will apply to both reject and discard, or
> you are not allowed to block, and then it apply to both reject and discard.
> Theres no difference in rejecting or discarding, its still considered
> distruption, if you do it in the wrong situation.
>
> If I receive a call from somebody asking me to forward information to person
> D, even if I say "yes, I will do", its not illegal to ignore that and not
> forward the phone call. Its my phone, if someone calls my phone, they have
> to abide to my rules.
>
> Note the wording "electronic communication", which also apply to website
> traffic and such. The ruling is more aiming on hackers, for example
> "distrupting communications between 2 parties" is meant to target DoS, not
> someone blocking certain email traffic into their network.
>
> What I have understand, E-mail does not have any special catering, not
> either in german law or swedish law. Maybe some single EU country does pay
> special attention to E-mails, but normally, E-mail is same as website
> traffic is same as for example Skype, and is just TCP/IP packets over the
> internet. And TCP/IP packets its up to you if you want to accept, reject, or
> drop packets destined for your network.
>
> Simple as this: The mail server you run for a company, or for some user or
> whatever, can be seen as your post-box outside the house. Of course, even if
> you receive physical mail for other people in same house, you are fully
> permitted to regulate that mail and toss mail you don't want, even if its
> adressed to someone else at that adress. Compare with for example a parent
> that toss away porn magazines adressed for their child, without telling
> either the magazine company or the child.
>
>
> Of course, a ISP mailserver is bound by much more strict rules, and here it
> might be regulation prohibiting when you are allowed to reject's/discard's,
> but I suspect none on this mailing list are running a ISP mailserver. (An
> ISP is defined as someone who runs a access network of a specific minimum
> size, wired, wireless or cellular, that people can access for a fee, where
> no prior internet access is required - so VPNs don't count. A hotel wifi
> wont count, it must be something larger, and being a ISP requires a special
> license from the government, like a bank, because being a ISP is a community
> service and must meet some minimum quality standards)
>
>
> So to put it short, if you block mail in the wrong situation, it don't
> matter if its reject or discard. Either you may block, then reject=allowed,
> discard=allowed, or you may not block, and then reject=prohibited,
> discard=prohibited.
> Unless the country in question have special rules for SMTP traffic, which I
> find unlikely. SMTP is TCP/IP like website traffic, IRC traffic, Skype
> traffic, DNS traffic or whatever.
>
>
> -Ursprungligt meddelande-
> 

Re: A bug, maybe?

[Viktor Dukhovni]

On Sat, Feb 20, 2016 at 01:37:39PM -0500, Curtis Maurand wrote:

> Nothing is chrooted.  resolv.conf is world readable.  Wietse's program
> returns a valid address.  It might not match the reverse, but it did return
> an address.
> # ./getaddr delivery.mailspamprotection.com
> Hostname:   delivery.mailspamprotection.com
> Addresses:  108.163.228.171

There's your problem, it is supposed to return *all* the addresses.  On
my system:

$ ./getaddrinfo delivery.mailspamprotection.com
Hostname:   delivery.mailspamprotection.com
Addresses:  108.163.220.52 108.163.201.229 69.175.69.94 108.163.204.150 
198.143.161.10 108.163.201.230 96.127.190.5 184.154.58.227 198.143.161.21 
184.154.48.173 198.143.161.29 69.175.69.92 108.163.243.190 96.127.190.4 
198.143.161.30 108.178.24.182 108.163.243.188 108.163.228.171 69.175.69.93 
184.154.208.34 184.154.208.36 96.127.176.253 96.127.190.2 198.143.161.27 
108.163.220.54 198.143.161.11 108.163.228.170 198.143.161.13 184.154.58.230 
108.163.243.189 108.163.228.174 108.163.201.228 108.178.24.171 108.163.201.226 
108.178.24.181 108.163.201.227 184.154.208.37 108.178.24.174 198.143.161.12 
184.154.48.171 96.127.176.250 108.163.243.186 108.178.24.180 69.175.69.90 
108.163.243.187 108.163.228.172 96.127.176.252 184.154.177.50 184.154.48.172 
108.163.204.148 198.143.161.28 108.163.204.146 184.154.208.35 108.163.204.149 
96.127.190.6 69.175.69.91 184.154.58.226 108.163.228.173 108.178.24.173 
108.178.24.178 96.127.176.254 198.143.161.18 184.154.48.174 198.143.161.20 
184.154.58.229 108.163.220.51 96.127.176.251 108.163.220.50 108.178.24.170 
108.163.220.53 198.143.161.22 184.154.208.38 184.154.48.170 184.154.58.228 
108.178.24.172 198.143.161.14 108.178.24.179 198.143.161.19 108.163.204.147 
198.143.161.26 96.127.190.3

If your getaddrinfo returns only the first address, it is busted.
Perhaps this is controlled via /etc/hosts.conf:

http://www.linfo.org/etc_host_conf.html

/etc/hosts.conf:
multi on

> That said.  Since the unit has been updated, but not rebooted, I may need to
> reboot to get the kernel fix.  Ubuntu does, at least, backport fixes.

The getaddrinfo issue is not resolved via a kernel fix, it is
addressed via a glibc fix.

-- 
Viktor.

Re: A bug, maybe?

[Curtis Maurand]

On 2/20/2016 12:17 PM, Viktor Dukhovni wrote:

On Sat, Feb 20, 2016 at 11:40:09AM -0500, Curtis Maurand wrote:


i just sent myself a test message from the client's system.  Here is what I
got.  I immediately ran the lookups using dig.  postfix can't seem to
resolve things properly.  Running Ubuntu Server 14.04 LTS with ispconfig
installed.  I'm using powerdns with powerdns recursor.  resolv.conf points
to the localhost's external ip address.  This is sort of annoying.  I really
don't want to open up the server's to misconfigured system as that increases
the amount of spam dramatically.

Do keep in mind that on Ubuntu systems Postfix tends to have many
services in master.cf chooted by default, the chroot jail may have
a different /etc/resolv.conf, and may have different copies of
various dynamically loaded nss modules.

Do disable chroot for "smtpd" if enabled, and do test your
getaddrinfo() implementation.


Nothing is chrooted.  resolv.conf is world readable.  Wietse's program 
returns a valid address.  It might not match the reverse, but it did 
return an address.

# ./getaddr delivery.mailspamprotection.com
Hostname:   delivery.mailspamprotection.com
Addresses:  108.163.228.171

That said.  Since the unit has been updated, but not rebooted, I may 
need to reboot to get the kernel fix.  Ubuntu does, at least, backport 
fixes.





--
Curtis Maurand
cur...@maurand.com 
207-252-7748

Re: A bug, maybe?

[Viktor Dukhovni]

On Sat, Feb 20, 2016 at 11:40:09AM -0500, Curtis Maurand wrote:

> i just sent myself a test message from the client's system.  Here is what I
> got.  I immediately ran the lookups using dig.  postfix can't seem to
> resolve things properly.  Running Ubuntu Server 14.04 LTS with ispconfig
> installed.  I'm using powerdns with powerdns recursor.  resolv.conf points
> to the localhost's external ip address.  This is sort of annoying.  I really
> don't want to open up the server's to misconfigured system as that increases
> the amount of spam dramatically.

Do keep in mind that on Ubuntu systems Postfix tends to have many
services in master.cf chooted by default, the chroot jail may have
a different /etc/resolv.conf, and may have different copies of
various dynamically loaded nss modules.

Do disable chroot for "smtpd" if enabled, and do test your
getaddrinfo() implementation.

-- 
Viktor.

Re: A bug, maybe?

[Wietse Venema]

Curtis Maurand:
> Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: warning: hostname
> delivery.mailspamprotection.com does not resolve to address
> 108.163.243.188

The problem of testing with nslookup, dig, etc., is that they don't
use the getaddrinfo() system library function that Postfix uses to
look up the remote SMTP client IP address. This uses nsswitch, which
uses nscd or whatever it is called today.

You can test your getaddrinfo() system library function with the
attached test program.

But you will never be able to reproduce the conditions of Feb 19 16:30:29.

BTW This week there was a major bugfix for getaddrinfo() on Linux
systems. So yours has probably been updated.

Wietse

 /*
  * getaddrinfo(3) (name->address lookup) tester.
  * 
  * Compile with:
  * 
  * cc -o getaddrinfo getaddrinfo.c (BSD, Linux)
  * 
  * cc -o getaddrinfo getaddrinfo.c -lsocket -lnsl (SunOS 5.x)
  * 
  * Run as: getaddrinfo hostname
  * 
  * Author: Wietse Venema, Eindhoven University of Technology, The Netherlands.
  * 
  * Author: Wietse Venema, IBM T.J. Watson Research, USA.
  */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
charhostbuf[NI_MAXHOST];/* XXX */
struct addrinfo hints;
struct addrinfo *res0;
struct addrinfo *res;
const char *addr;
int err;

#define NO_SERVICE ((char *) 0)

if (argc != 2) {
fprintf(stderr, "usage: %s hostname\n", argv[0]);
exit(1);
}
memset((char *) , 0, sizeof(hints));
hints.ai_family = PF_UNSPEC;
hints.ai_flags = AI_CANONNAME;
hints.ai_socktype = SOCK_STREAM;
if ((err = getaddrinfo(argv[1], NO_SERVICE, , )) != 0) {
fprintf(stderr, "host %s not found: %s\n", argv[1], gai_strerror(err));
exit(1);
}
printf("Hostname:\t%s\n", res0->ai_canonname);
printf("Addresses:\t");
for (res = res0; res != 0; res = res->ai_next) {
addr = (res->ai_family == AF_INET ?
(char *) &((struct sockaddr_in *) res->ai_addr)->sin_addr :
(char *) &((struct sockaddr_in6 *) res->ai_addr)->sin6_addr);
if (inet_ntop(res->ai_family, addr, hostbuf, sizeof(hostbuf)) == 0) {
perror("inet_ntop:");
exit(1);
}
printf("%s ", hostbuf);
}
printf("\n");
freeaddrinfo(res0);
exit(0);
}

Re: A bug, maybe?

[Curtis Maurand]

On 2/20/2016 11:26 AM, Curtis Maurand wrote:



On 2/20/2016 11:12 AM, Christian Kivalo wrote:

On 2016-02-20 16:45, Curtis Maurand wrote:

Not sure if I found something or not.  A client tried to send email
to one of my other addresses.  The requisite portion of the main.cf
follows at the end of the message.  The logs are telling me:

Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: warning: hostname
delivery.mailspamprotection.com does not resolve to address
108.163.243.188
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: connect from
unknown[108.163.243.188]
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: NOQUEUE: reject: RCPT
from unknown[108.163.243.188]: 450 4.7.1 Client host rejected: cannot
find your hostname, [108.163.243.188];
from= to= proto=ESMTP
helo=


Have you had dns lookup problems? This is a temporary error and the 
client should retry delivery




450 4.7.1 Client host rejected: cannot find your hostname,
[108.163.243.188]:
retry timeout exceeded

the original message was sent on the 15th.  the return bounce on the 
19th.  I haven't rebooted or restarted services on that machine and 
all of the included lookups for this mail message were performed on 
the same machine this morning.


i just sent myself a test message from the client's system.  Here is 
what I got.  I immediately ran the lookups using dig.  postfix can't 
seem to resolve things properly.  Running Ubuntu Server 14.04 LTS with 
ispconfig installed.  I'm using powerdns with powerdns recursor.  
resolv.conf points to the localhost's external ip address.  This is sort 
of annoying.  I really don't want to open up the server's to 
misconfigured system as that increases the amount of spam dramatically.


Feb 20 11:31:45 ispconfig postfix/smtpd[16013]: warning: hostname 
delivery.mailspamprotection.com does not resolve to address 108.163.220.52
Feb 20 11:31:45 ispconfig postfix/smtpd[16013]: connect from 
unknown[108.163.220.52]
Feb 20 11:31:45 ispconfig postfix/smtpd[16013]: NOQUEUE: reject: RCPT 
from unknown[108.163.220.52]: 450 4.7.1 Client host rejected: cannot 
find your hostname, [108.163.220.52]; from= 
to= proto=ESMTP helo=
Feb 20 11:31:45 ispconfig postfix/smtpd[16013]: disconnect from 
unknown[108.163.220.52]

Feb 20 11:32:01 ispconfig postfix/smtpd[16013]: connect from localhost[::1]
Feb 20 11:32:01 ispconfig postfix/smtpd[16013]: lost connection after 
CONNECT from localhost[::1]
Feb 20 11:32:01 ispconfig postfix/smtpd[16013]: disconnect from 
localhost[::1]


root@ispconfig:/var/www/webmail.xyonet.com/web# dig 
delivery.mailspamprotection.com |grep 108.163.220

delivery.mailspamprotection.com. 30 IN  A 108.163.220.50
delivery.mailspamprotection.com. 30 IN  A 108.163.220.51
delivery.mailspamprotection.com. 30 IN  A 108.163.220.53
delivery.mailspamprotection.com. 30 IN  A 108.163.220.54
delivery.mailspamprotection.com. 30 IN  A 108.163.220.52
root@ispconfig:/var/www/webmail.xyonet.com/web# dig ptr 
52.220.163.108.in-addr.arpa


; <<>> DiG 9.9.5-3ubuntu0.7-Ubuntu <<>> ptr 52.220.163.108.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32216
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;52.220.163.108.in-addr.arpa.   IN  PTR

;; ANSWER SECTION:
52.220.163.108.in-addr.arpa. 3495 INPTR delivery.mailspamprotection.com.





--
Curtis Maurand
cur...@maurand.com 
207-252-7748


--
Curtis Maurand
cur...@maurand.com 
207-252-7748

Re: Outbound TLS

[Wietse Venema]

Viktor Dukhovni:
> On Sat, Feb 20, 2016 at 08:32:31AM -0500, Wietse Venema wrote:
> 
> > > Creating a separate hash file with following content like below solved my
> > > issue but doing the same for all domain will not be acceptable solution 
> > > ...
> > 
> > If you want to encrypt mail to all domains:
> > 
> > /etc/postfix/main.cf
> >smtp_tls_security_level = encrypt
> > 
> > But I would not recommend this.
> 
> If the OP just wants to use TLS with domains that offer STARTTLS,
> then:
> 
> smtp_tls_security_level = may
> 
> may be most appropriate.  This does not prevent cleartext fallback
> in case of trouble, but there are enough domains that advertise
> non-working STARTTLS to make cleartext fallback the sensible choice
> at present.  Opportunistic TLS is a counter-measure to passive
> monitoring, not active attacks.

The fanatics can disable fallback to plaintext with the example in
http://www.postfix.org/postconf.5.html#default_delivery_status_filter
(available in Postfix 3.0 and later).

Wietse

Re: A bug, maybe?

[Curtis Maurand]

On 2/20/2016 11:12 AM, Christian Kivalo wrote:

On 2016-02-20 16:45, Curtis Maurand wrote:

Not sure if I found something or not.  A client tried to send email
to one of my other addresses.  The requisite portion of the main.cf
follows at the end of the message.  The logs are telling me:

Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: warning: hostname
delivery.mailspamprotection.com does not resolve to address
108.163.243.188
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: connect from
unknown[108.163.243.188]
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: NOQUEUE: reject: RCPT
from unknown[108.163.243.188]: 450 4.7.1 Client host rejected: cannot
find your hostname, [108.163.243.188];
from= to= proto=ESMTP
helo=


Have you had dns lookup problems? This is a temporary error and the 
client should retry delivery




450 4.7.1 Client host rejected: cannot find your hostname,
[108.163.243.188]:
retry timeout exceeded

the original message was sent on the 15th.  the return bounce on the 
19th.  I haven't rebooted or restarted services on that  machine and all 
of the included lookups for this mail message were performed on the same 
machine this morning.



--
Curtis Maurand
cur...@maurand.com 
207-252-7748

Re: A bug, maybe?

[Christian Kivalo]

On 2016-02-20 16:45, Curtis Maurand wrote:

Not sure if I found something or not.  A client tried to send email
to one of my other addresses.  The requisite portion of the main.cf
follows at the end of the message.  The logs are telling me:

Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: warning: hostname
delivery.mailspamprotection.com does not resolve to address
108.163.243.188
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: connect from
unknown[108.163.243.188]
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: NOQUEUE: reject: RCPT
from unknown[108.163.243.188]: 450 4.7.1 Client host rejected: cannot
find your hostname, [108.163.243.188];
from= to= proto=ESMTP
helo=


Have you had dns lookup problems? This is a temporary error and the 
client should retry delivery



Feb 19 16:30:30 ispconfig postfix/smtpd[18437]: disconnect from
unknown[108.163.243.188]

deliver.mailspamprotection.com resolves to a lot of addresses (and
this is a partial list):

dig delivery.mailspamprotection.com |grep 108.163.243
delivery.mailspamprotection.com. 30 IN  A   108.163.243.188
delivery.mailspamprotection.com. 30 IN  A   108.163.243.187
delivery.mailspamprotection.com. 30 IN  A   108.163.243.189
delivery.mailspamprotection.com. 30 IN  A   108.163.243.190
delivery.mailspamprotection.com. 30 IN  A   108.163.243.186

and

;188.243.163.108.in-addr.arpa.  IN  PTR

;; ANSWER SECTION:
188.243.163.108.in-addr.arpa. 3600 IN   PTR
delivery.mailspamprotection.com.

given such a round robin setup, does postfix account for this when
performing it's hostname lookup?  This email should not have been
rejected for any kind of ip mismatch.  Forward, reverse and helo all
match.

Thanks,
Curtis

smtpd_sender_restrictions =
  check_sender_access regexp:/etc/postfix/tag_as_originating.re
  permit_mynetworks,
  permit_sasl_authenticated,
  check_recipient_access
mysql:/etc/postfix/mysql-virtual_recipient.cf,
  check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf,
regexp:/etc/postfix/tag_as_foreign.re
  reject_invalid_hostname,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_unauth_pipelining,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client b.barracudacentral.org

smtpd_client_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_client_access
  mysql:/etc/postfix/mysql-virtual_client.cf,
  reject_unknown_client,
this restriction causes the reject, see 
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname


reject_unknown_client_hostname (with Postfix < 2.3: 
reject_unknown_client)
Reject the request when 1) the client IP address->name mapping fails, 2) 
the name->address mapping fails, or 3) the name->address mapping does 
not match the client IP address.
This is a stronger restriction than the 
reject_unknown_reverse_client_hostname feature, which triggers only 
under condition 1) above.
The unknown_client_reject_code parameter specifies the response code for 
rejected requests (default: 450). The reply is always 450 in case the 
address->name or name->address lookup failed due to a temporary problem.


reject_unknown_reverse_client_hostname is considered the safer 
alternative but in your case maybe removing it altogether allows more 
legitimate mail through.



  reject_invalid_hostname,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_unauth_pipelining,
  reject_unauth_destination,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client b.barracudacentral.org

--
Curtis Maurand
cur...@maurand.com
207-252-7748


--
 Christian Kivalo

Re: A bug, maybe?

[Viktor Dukhovni]

On Sat, Feb 20, 2016 at 10:45:42AM -0500, Curtis Maurand wrote:

> Feb 19 16:30:29 ispconfig postfix/smtpd[18437]:
> warning: hostname delivery.mailspamprotection.com
> does not resolve to address 108.163.243.188
> Feb 19 16:30:29 ispconfig postfix/smtpd[18437]:
> connect from unknown[108.163.243.188]
> Feb 19 16:30:29 ispconfig postfix/smtpd[18437]:
> NOQUEUE: reject: RCPT from unknown[108.163.243.188]:
> 450 4.7.1 Client host rejected: cannot find your hostname, 
> [108.163.243.188];
> from= to= proto=ESMTP
> helo=

Error "450" is a temporary error, the DNS lookup temp failed, stuff
happens.

> deliver.mailspamprotection.com resolves to a lot of addresses (and this is a
> partial list):
> 
> dig delivery.mailspamprotection.com |grep 108.163.243
> delivery.mailspamprotection.com. 30 IN  A 108.163.243.188
> delivery.mailspamprotection.com. 30 IN  A 108.163.243.187
> delivery.mailspamprotection.com. 30 IN  A 108.163.243.189
> delivery.mailspamprotection.com. 30 IN  A 108.163.243.190
> delivery.mailspamprotection.com. 30 IN  A 108.163.243.186

Yes, it resolves to 81 addresses at present, that's more typical
of a spam-sending system than an anti-spam system.  Perhaps
mailspamprotection means protection of spam, rather than protection
from spam?

The large DNS packet size needed to return the PTR record in question
can be contributing factor to interoperability issues.  You also
should check that the getaddrinfo(3) C-library function on your
system returns all 81 addresses that you might see via dig(1).

> given such a round robin setup, does postfix account for this when
> performing it's hostname lookup?

Yes, but the C-library and your resolver need to return the relevant
addresses.

> This email should not have been rejected
> for any kind of ip mismatch.  Forward, reverse and helo all match.

They do now, they did not then.

-- 
Viktor.

A bug, maybe?

[Curtis Maurand]

Not sure if I found something or not.  A client tried to send email to 
one of my other addresses.  The requisite portion of the main.cf follows 
at the end of the message.  The logs are telling me:


Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: warning: hostname 
delivery.mailspamprotection.com does not resolve to address 108.163.243.188
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: connect from 
unknown[108.163.243.188]
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: NOQUEUE: reject: RCPT 
from unknown[108.163.243.188]: 450 4.7.1 Client host rejected: cannot 
find your hostname, [108.163.243.188]; from= 
to= proto=ESMTP helo=
Feb 19 16:30:30 ispconfig postfix/smtpd[18437]: disconnect from 
unknown[108.163.243.188]


deliver.mailspamprotection.com resolves to a lot of addresses (and this 
is a partial list):


dig delivery.mailspamprotection.com |grep 108.163.243
delivery.mailspamprotection.com. 30 IN  A 108.163.243.188
delivery.mailspamprotection.com. 30 IN  A 108.163.243.187
delivery.mailspamprotection.com. 30 IN  A 108.163.243.189
delivery.mailspamprotection.com. 30 IN  A 108.163.243.190
delivery.mailspamprotection.com. 30 IN  A 108.163.243.186

and

;188.243.163.108.in-addr.arpa.  IN  PTR

;; ANSWER SECTION:
188.243.163.108.in-addr.arpa. 3600 IN   PTR delivery.mailspamprotection.com.


given such a round robin setup, does postfix account for this when 
performing it's hostname lookup?  This email should not have been 
rejected for any kind of ip mismatch.  Forward, reverse and helo all match.


Thanks,
Curtis


smtpd_sender_restrictions =
  check_sender_access regexp:/etc/postfix/tag_as_originating.re
  permit_mynetworks,
  permit_sasl_authenticated,
  check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf,
  check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf, 
regexp:/etc/postfix/tag_as_foreign.re

  reject_invalid_hostname,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_unauth_pipelining,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client b.barracudacentral.org

smtpd_client_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_client_access
  mysql:/etc/postfix/mysql-virtual_client.cf,
  reject_unknown_client,
  reject_invalid_hostname,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_unauth_pipelining,
  reject_unauth_destination,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client b.barracudacentral.org


--
Curtis Maurand
cur...@maurand.com 
207-252-7748

Re: Outbound TLS

[Viktor Dukhovni]

On Sat, Feb 20, 2016 at 08:32:31AM -0500, Wietse Venema wrote:

> > Creating a separate hash file with following content like below solved my
> > issue but doing the same for all domain will not be acceptable solution ...
> 
> If you want to encrypt mail to all domains:
> 
> /etc/postfix/main.cf
>smtp_tls_security_level = encrypt
> 
> But I would not recommend this.

If the OP just wants to use TLS with domains that offer STARTTLS,
then:

smtp_tls_security_level = may

may be most appropriate.  This does not prevent cleartext fallback
in case of trouble, but there are enough domains that advertise
non-working STARTTLS to make cleartext fallback the sensible choice
at present.  Opportunistic TLS is a counter-measure to passive
monitoring, not active attacks.

-- 
Viktor.

SV: SV: SV: SV: Blocking TLDs

[Sebastian Nielsen]

I readed that on wikipedia, and readed the sources, and one thing I can say,
is that the source is heavily misinterpreted. They refer to physical mail,
and telecommunication, where a set of rules apply to physical mail, and some
other set apply to telecommunication.
Of course, you are not allowed to tamper with third-party communication, but
if you run a mail server, then you are "in the loop" and are permitted to do
whatever you want. Nobody forces you to accept whatever you don't want into
your network. If you want to toss all HTML mail destined for your company
into /dev/null, its up to you.
This provided that you didn't unauthorizedly insert yourself into the loop.
If a end user select to use you as mail service, they have to abide by your
rules, including that some mails might get tossed away. But if you force
somebody, which aren't using your network, to use your mail service, for
example via ARP spoofing or fake Wifi AP's, then its computer intrusion.

Also, the law does not make any difference on reject or discard, either you
are allowed to block, and then it will apply to both reject and discard, or
you are not allowed to block, and then it apply to both reject and discard.
Theres no difference in rejecting or discarding, its still considered
distruption, if you do it in the wrong situation.

If I receive a call from somebody asking me to forward information to person
D, even if I say "yes, I will do", its not illegal to ignore that and not
forward the phone call. Its my phone, if someone calls my phone, they have
to abide to my rules.

Note the wording "electronic communication", which also apply to website
traffic and such. The ruling is more aiming on hackers, for example
"distrupting communications between 2 parties" is meant to target DoS, not
someone blocking certain email traffic into their network.

What I have understand, E-mail does not have any special catering, not
either in german law or swedish law. Maybe some single EU country does pay
special attention to E-mails, but normally, E-mail is same as website
traffic is same as for example Skype, and is just TCP/IP packets over the
internet. And TCP/IP packets its up to you if you want to accept, reject, or
drop packets destined for your network.

Simple as this: The mail server you run for a company, or for some user or
whatever, can be seen as your post-box outside the house. Of course, even if
you receive physical mail for other people in same house, you are fully
permitted to regulate that mail and toss mail you don't want, even if its
adressed to someone else at that adress. Compare with for example a parent
that toss away porn magazines adressed for their child, without telling
either the magazine company or the child.


Of course, a ISP mailserver is bound by much more strict rules, and here it
might be regulation prohibiting when you are allowed to reject's/discard's,
but I suspect none on this mailing list are running a ISP mailserver. (An
ISP is defined as someone who runs a access network of a specific minimum
size, wired, wireless or cellular, that people can access for a fee, where
no prior internet access is required - so VPNs don't count. A hotel wifi
wont count, it must be something larger, and being a ISP requires a special
license from the government, like a bank, because being a ISP is a community
service and must meet some minimum quality standards)


So to put it short, if you block mail in the wrong situation, it don't
matter if its reject or discard. Either you may block, then reject=allowed,
discard=allowed, or you may not block, and then reject=prohibited,
discard=prohibited.
Unless the country in question have special rules for SMTP traffic, which I
find unlikely. SMTP is TCP/IP like website traffic, IRC traffic, Skype
traffic, DNS traffic or whatever.


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Robert Schetterer
Skickat: den 20 februari 2016 13:49
Till: postfix-users@postfix.org
Ämne: Re: SV: SV: SV: Blocking TLDs

Am 20.02.2016 um 12:01 schrieb Sebastian Nielsen:
> Why are you people so negative against DISCARD, and wants to use 
> REJECT

Silent discard mail is not allowed in many EU countries, youre the postman
you dont have to deliver bombs ( virus ), you may react on marketing letters
(spam ) by sort them or simply reject at the start when you recieve it, and
only if  your customer ordered you to do so but in general you are not
allowed to burn otherones letters


Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Outbound TLS

[Wietse Venema]

Joy:
> Creating a separate hash file with following content like below solved my
> issue but doing the same for all domain will not be acceptable solution ...

If you want to encrypt mail to all domains:

/etc/postfix/main.cf
   smtp_tls_security_level = encrypt

But I would not recommend this.

Wietse

Re: SV: SV: SV: Blocking TLDs

[Robert Schetterer]

Am 20.02.2016 um 12:01 schrieb Sebastian Nielsen:
> Why are you people so negative against DISCARD, and wants to use REJECT

Silent discard mail is not allowed in many EU countries, youre the
postman you dont have to deliver bombs ( virus ), you may react on
marketing letters (spam ) by sort them or simply reject at the start
when you recieve it, and only if  your customer ordered you to do so
but in general you are not allowed to burn otherones letters


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Outbound TLS

[Joy]

Creating a separate hash file with following content like below solved my
issue but doing the same for all domain will not be acceptable solution ...

In case any other solution exist which i may be missing just let me know.


smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

gmail.com encrypt
.gmail.com encrypt




On Sat, Feb 13, 2016 at 6:12 PM, Wietse Venema  wrote:

> Christian Kivalo:
> >
> >
> > Am 13. Februar 2016 11:10:25 MEZ, schrieb Joy :
> > >May i know how can i force postfix to use TLS if remote MTA advertises
> > >STARTTLS on port 25 to connect to remote server ?
> > >
> > >I am already using TLS and connecting from outlook is working
> > >perfectly,
> > >but when sending mail to google it now says TLS fail.
> > Take a look at http://www.postfix.org/DEBUG_README.html#mail and
> provide all necessary information
> >
> > At least postconf -n / postconf -Mf and log output of the tls fail to
> google
>
> Indeed. google.com MX hosts support STARTTLS on port 25. If you
> must verify certificates issued from third-party issuers, see:
>
> http://www.postfix.org/postconf.5.html#tls_append_default_CA
>
> Wietse
>
> $ posttls-finger google.com
> posttls-finger: Connected to aspmx.l.google.com[2607:f8b0:400d:c07::1b]:25
> posttls-finger: < 220 mx.google.com ESMTP 207si21470864qhw.106 - gsmtp
> posttls-finger: > EHLO tail.porcupine.org
> posttls-finger: < 250-mx.google.com at your service, [2604:8d00:189::3]
> posttls-finger: < 250-SIZE 35882577
> posttls-finger: < 250-8BITMIME
> posttls-finger: < 250-STARTTLS
> posttls-finger: < 250-ENHANCEDSTATUSCODES
> posttls-finger: < 250-PIPELINING
> posttls-finger: < 250-CHUNKING
> posttls-finger: < 250 SMTPUTF8
> posttls-finger: > STARTTLS
> posttls-finger: < 220 2.0.0 Ready to start TLS
> ..lotsa stuff..
> posttls-finger: certificate verification failed for 
> aspmx.l.google.com[2607:f8b0:400d:c07::1b]:25:
> untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
> posttls-finger: aspmx.l.google.com[2607:f8b0:400d:c07::1b]:25: subject_CN=
> aspmx.l.google.com, issuer_CN=Google Internet Authority G2,
> fingerprint=17:C3:E9:B6:EB:1C:7E:BB:95:67:BE:EA:E6:48:43:90:E0:24:95:03,
> pkey_fingerprint=AD:4B:02:AC:67:0F:96:F3:D1:85:C9:3D:E3:A2:04:B3:9A:0F:36:17
> posttls-finger: Untrusted TLS connection established to 
> aspmx.l.google.com[2607:f8b0:400d:c07::1b]:25:
> TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
> posttls-finger: > EHLO tail.porcupine.org
> posttls-finger: < 250-mx.google.com at your service, [2604:8d00:189::3]
> posttls-finger: < 250-SIZE 35882577
> posttls-finger: < 250-8BITMIME
> posttls-finger: < 250-ENHANCEDSTATUSCODES
> posttls-finger: < 250-PIPELINING
> posttls-finger: < 250-CHUNKING
> posttls-finger: < 250 SMTPUTF8
> posttls-finger: > QUIT
> posttls-finger: < 221 2.0.0 closing connection 207si21470864qhw.106 - gsmtp
>
>

SV: SV: SV: Blocking TLDs

[Sebastian Nielsen]

What I meant with REJECT vs DISCARD, is that with REJECT, the spammers just
switch to a new domain. And new domain, and new domain.
Like they have some script or API that instantly purchases a new domain once
their current domain gets banned in spam filters. (And yes, they do really
have valid addresses because they often write in the payload like "Reply to
sign up" and so on), and the links inside spam goes to the domain listed
after @.
That’s the bad thing with registrars that allow domain purchasing via a API.

I have witnessed it in realtime, when I continually added banned domains to
my banfile and the spammer just, nearly instant on the second I reloaded
files, switched to some new domain that was similar to the banned. And in
the log file I saw the reject, so I understood the spammer was adapting to
the spam filter. After like 5-6 domains I got fed up, changed everything
into DISCARD, and once that, all the spam from that particular source have
vanished, while I can see in logfiles that the spammer still thinks they get
something through when they really don't. 

Either they are using some domain generator algoritm, or they are just
randoming domains up using some dictionary. They also seem to know when to
change TLD, like when they got rejected on like X different banned domains
without getting a single piece through.

If everyone would use DISCARD on all the static spam filters (where you are
sure not getting false positives), then spammers will never know if they get
their spam delivered, and will not be able to optimize when to
"instant-purchase a new domain and switch to that" to maximize effectiveness
of spam campaign.

But you make a valid point about the payload. Only way to completely get rid
of payload is to use greylisting on all senders, so the spammer can't find a
"valid" domain that aren't banned, eg every domain will result in a
temporary reject.
But greylisting also delays legitimate mail.

Why are you people so negative against DISCARD, and wants to use REJECT, if
we disregard that the payload goes through the wire? Because most spams are
pretty small to not trigger through scans, so its just a few kilobytes.


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Benny Pedersen
Skickat: den 20 februari 2016 10:40
Till: postfix-users@postfix.org
Ämne: Re: SV: SV: Blocking TLDs

On 2016-02-20 00:52, Sebastian Nielsen wrote:
> 1: REJECT tells the spammer "Hey, your spam got stuck in the spam 
> filter. Wanna try again?".

if thay do, so what ?, its not possible for spammers to make remote
administoring on postfix this would be in vain anyway, and the point on
discard is accepting more payloads on recieved data, where reject stop the
payloads

> Better to DISCARD it so the spammer think they got the spam through, 
> then they won't switch to a new domain.

fair, but read above

> I don't think anyone ever will receive legitimate mail from any of 
> those spammy TLDs listed in the rules file I gave.

this  is another problem



smime.p7s
Description: S/MIME Cryptographic Signature

Re: SV: SV: access permissions 101

[Martin Skjöldebrand]

On 20/02/16 11:02, Sebastian Nielsen wrote:
> Think like a apartment. Your outer door is of course closed and locked, but 
> your inner doors are always open.
We leave it at "agree to disagree".
To me your comparison tells me what the problem is. It also doesn't take
the inhabitants into account.

/Martin S

-- 
This address is for technical mail lists only.For all other matters, please use 
my main address at the .org domain.

SV: SV: access permissions 101

[Sebastian Nielsen]

I understand fully what the reasoning is here, where you want average security 
from the ground up into the core of the server.

When I set up servers or systems, I rather prefer a really tough and hard shell 
around the network/system in question, and pretty sloppy security inside.
Like a nut. Very tough to get in, but once you´re in, theres almost no security.
That makes it a whole lot easier to administrate, since then I can easily 
integrate software more tightly in each other (for example DNS integrated with 
HTTP and SMTP and filters and everything), while I can concentrate on tight 
security at the perimeter.

Think like a apartment. Your outer door is of course closed and locked, but 
your inner doors are always open.

So I set up pretty restrictive firewall rules, and have filters, proxies and 
rules at the perimeter protection, to prevent any bad guys from getting in at 
all. On my servers, user's aren't even getting IMAP or SMTP relay access from 
the outside, since I think it’s a security risk. If they need that type of 
access, they have to use webmail, since that can be set up more securely with 
IP authorization, OTP codes and captcha security.
If I need to separate things for security reasons, I rather put them on 
separate networks in firewall with strict rules in-between, rather than 
fiddling with permissions and getting that things working.

So I think its just another way to administrate a server. Some people prefer 
average security everywhere, and some other prefer tough and restrictive 
security at the perimeter and then loose security inside. That’s why I 666's 
files to make it easier to administrate.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Martin Skjöldebrand
Skickat: den 20 februari 2016 10:26
Till: postfix-users@postfix.org
Ämne: Re: SV: access permissions 101

On 20/02/16 02:05, Sebastian Nielsen wrote:
> Everytime I need multiple processes to access the very same file and those 
> processes has interlocks that prevent them from running as the same user or 
> same group, I just "fix" the problem with 666.
>
> That is a thing I ONLY do if I get a permission error when trying to do 
> something I want to do with some software. So for example, when I want to 
> edit something from my admin panel on http://www.sebbe.eu , I just 666 that 
> file to be able to access it from the admin panel.
>
> Same, I needed to get arp working so HTTP could execute arp for detecting 
> which MAC addresses users of a captive portal had. I simply 777'd arp 
> command, because not even 755 worked for some reason, the arp command 
> required whoever that had execute permission to also have write permission.
Apologies for butting in on this discussion. The above reasoning seems to me 
deeply flawed and something I was guilty of as a Linux newbie back in the late 
90s. It is a tempting easy way out.

Rather than addressing the cause of a problem, you are attacking the symptoms 
and in the process creating unnecessary vulnerabilities in the system. At least 
that is how I read your brief description.

The problem with this, to my mind, is that it introduces sloppyness and this 
can influence future actions and sub-par "solutions" permanenting potentially 
harmful workarounds. On my own home gaming box, it's one thing, on a company or 
client server on the other hand ...

/Martin S
>
> Yeah, I agree that actually, only 644 is required on that config file. But 
> why get so angry when someone 666's a file to just get things working?
> Its not like a list of banned spam domains is something super-sensitive.
>
>
> -Ursprungligt meddelande-
> Från: Jim Reid [mailto:j...@rfc1035.com]
> Skickat: den 20 februari 2016 01:40
> Till: Sebastian Nielsen 
> Kopia: postfix-users@postfix.org
> Ämne: access permissions 101
>
>
>> On 19 Feb 2016, at 23:52, Sebastian Nielsen  wrote:
>>
>> but if you're hosting for example a mail server for a company, and only you 
>> as a sysadmin has shell access to the server, its no danger 666'ing files 
>> that throw permission errors. Then the file isn't really "world writable", 
>> since only you have a account on the server anyways.
> This is a remarkably stupid and utterly irresponsible thing to say. It’s also 
> wrong. Very, very wrong.
>
> One of the fundamental principles of security is least privilege. Things get 
> the minimum permissions/access rights/whatever that are needed for the task 
> they have to perform.
>
> So for postfix only some postfix processes need to have write access from 
> time to time to specific files and directories. Almost nothing should ever 
> need write access to postfix's configuration files, except for maybe postmap 
> when rebuilding hash tables. So postfix's config files shouldn’t be writable 
> by anyone, not even the postfix user.
>
> Your starting assumption is also deeply flawed. A world-writable file can be 
> 

Re: SV: SV: Blocking TLDs

[Benny Pedersen]

On 2016-02-20 00:52, Sebastian Nielsen wrote:

1: REJECT tells the spammer "Hey, your spam got stuck in the spam
filter. Wanna try again?".


if thay do, so what ?, its not possible for spammers to make remote 
administoring on postfix this would be in vain anyway, and the point on 
discard is accepting more payloads on recieved data, where reject stop 
the payloads



Better to DISCARD it so the spammer think they got the spam through,
then they won't switch to a new domain.


fair, but read above


I don't think anyone ever will receive legitimate mail from any of
those spammy TLDs listed in the rules file I gave.


this  is another problem


2: Its just a habit, everytime some process complains of not able to
access a file, "666" is the universal solution.


what ?

are you sure root user is not enough for you then ?


Of course, this isn't
recommended in a web hosting setup, but if you're hosting for example
a mail server for a company, and only you as a sysadmin has shell
access to the server, its no danger 666'ing files that throw
permission errors. Then the file isn't really "world writable", since
only you have a account on the server anyways.


read access is bad in its own

Chmod the banned_tlds file to 666 to ensure the postfix process can 
read it.


two annotations:
  - I would not suggest DISCARD but REJECT
  - mode 666 (world writable) is generally not needed. 644 is enough


or mode 640
and chgrp postfix, and still owned by root

possible spammers reads world files ? :=)


banned_tlds:

/\.bid$/ DISCARD

/\.top$/ DISCARD


can be a single pcre line

Re: SV: access permissions 101

[Martin Skjöldebrand]

On 20/02/16 02:05, Sebastian Nielsen wrote:
> Everytime I need multiple processes to access the very same file and those 
> processes has interlocks that prevent them from running as the same user or 
> same group, I just "fix" the problem with 666.
>
> That is a thing I ONLY do if I get a permission error when trying to do 
> something I want to do with some software. So for example, when I want to 
> edit something from my admin panel on http://www.sebbe.eu , I just 666 that 
> file to be able to access it from the admin panel.
>
> Same, I needed to get arp working so HTTP could execute arp for detecting 
> which MAC addresses users of a captive portal had. I simply 777'd arp 
> command, because not even 755 worked for some reason, the arp command 
> required whoever that had execute permission to also have write permission.
Apologies for butting in on this discussion. The above reasoning seems
to me deeply flawed and something I was guilty of as a Linux newbie back
in the late 90s. It is a tempting easy way out.

Rather than addressing the cause of a problem, you are attacking the
symptoms and in the process creating unnecessary vulnerabilities in the
system. At least that is how I read your brief description.

The problem with this, to my mind, is that it introduces sloppyness and
this can influence future actions and sub-par "solutions" permanenting
potentially harmful workarounds. On my own home gaming box, it's one
thing, on a company or client server on the other hand ...

/Martin S
>
> Yeah, I agree that actually, only 644 is required on that config file. But 
> why get so angry when someone 666's a file to just get things working?
> Its not like a list of banned spam domains is something super-sensitive.
>
>
> -Ursprungligt meddelande-
> Från: Jim Reid [mailto:j...@rfc1035.com] 
> Skickat: den 20 februari 2016 01:40
> Till: Sebastian Nielsen 
> Kopia: postfix-users@postfix.org
> Ämne: access permissions 101
>
>
>> On 19 Feb 2016, at 23:52, Sebastian Nielsen  wrote:
>>
>> but if you're hosting for example a mail server for a company, and only you 
>> as a sysadmin has shell access to the server, its no danger 666'ing files 
>> that throw permission errors. Then the file isn't really "world writable", 
>> since only you have a account on the server anyways.
> This is a remarkably stupid and utterly irresponsible thing to say. It’s also 
> wrong. Very, very wrong.
>
> One of the fundamental principles of security is least privilege. Things get 
> the minimum permissions/access rights/whatever that are needed for the task 
> they have to perform.
>
> So for postfix only some postfix processes need to have write access from 
> time to time to specific files and directories. Almost nothing should ever 
> need write access to postfix's configuration files, except for maybe postmap 
> when rebuilding hash tables. So postfix's config files shouldn’t be writable 
> by anyone, not even the postfix user.
>
> Your starting assumption is also deeply flawed. A world-writable file can be 
> written to by anything, not just the UIDs who have shell accounts. There will 
> be other (or should be) UIDs and GIDs allocated to other services that run on 
> the box: HTTP, DNS, printing, MySQL, postgres, games, spam filters, man 
> pages, TeX, FTP, etc, etc. That way if one of these things has a security 
> leak, it can only write to that UID’s writable files (if there are any). The 
> breakage can’t contaminate anything else. But if someone is stupid enough to 
> intentionally make config files world-writable, these can be damaged by a 
> security problem in a rogue application. This is why the TeX user (say) 
> doesn’t get write access to the DNS or mail or MySQl or configuration. 
> That UID doesn’t need those privileges. So it doesn’t get them. At least, not 
> on any sensibly managed computer system.
>
> The logical extension of your approach is to make the password file, kernel, 
> shared library, etc world-writable. After all, you’re the only one who has 
> shell access. And you never, ever make mistakes and no software 
> vulnerabilities of any sort ever occur on the servers you manage - right?
>
> If you were hosting mail for my business and I found out you’d *deliberately* 
> set 666 permissions on the mail configuration files my company depended on, 
> I’d sue you for gross negligence. And win.
>
>
>

-- 
This address is for technical mail lists only.For all other matters, please use 
my main addressat the .org domain.