Ever since upgrading to Exim 4.91, legitimate email notifications are being rejected with an error "T=remote_smtp: message is too big (transport limit = 1)".
This appears to be related to a new ACL in Exim as described here to block messages that contain lines longer than 998 octets :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828801
A macro was supposedly added to v4.88~RC6-2, which disables this ACL named IGNORE_SMTP_LINE_LENGTH_LIMIT and to disable the ACL you can configure it to 1.
In my configuration, I have a server that sends email notifications. This server uses another server as a smarthost. I am running centos and have a config at /etc/exim/exim.conf on both servers.
I can't seem to disable this ACL no matter what I do.
I have added IGNORE_SMTP_LINE_LENGTH_LIMIT=1 to the top of both servers exim.conf files and continue to get errors.
Any suggestions on what to do?
I use "one big config-file" (not split-config), and adding
IGNORE_SMTP_LINE_LENGTH_LIMIT=1
to /etc/exim4/exim4.conf.localmacros works.
My configuration is also splitted in multiple files and uses a smarthost. Following these instructions, it works:
Create a new file in acl directory with nano /etc/exim4/conf.d/acl/00_local and put this:
IGNORE_SMTP_LINE_LENGTH_LIMIT=1
Reload configuration with systemctl reload exim4 or restart the service with systemctl restart exim4
Send an email and check the exim logs from /var/log/exim4/mainlog.
Related
I already have vsftp set up with an SSL which is working fine. The issue is that the SSL is for the server's host name and not one of my client's. This client has to be PCI compliant, so when the PCI scan takes place it checks the FTP ports and sees that the SSL is not associated with my client's URL. My question is how can I set vsftp up to serve an SSL based off the IP address or the hostname?
vsftpd version 3.0.3
Red Hat 8.2
I finally found the answer to this on Red Hat's site (https://access.redhat.com/solutions/5172631).
Essentially, the default configuration file is located at /etc/vsftpd/vsftpd.conf. You need to update this file to listen to the default IP address for the server using listen_address=.... Then, copy that file to /etc/vsftpd/[site].conf and change the listen_address to the one for the other site. (Obviously, you have to have different IP addresses for different sites for this to work.)
Once done, enable vsftpd.target and start it:
systemctl enable vsftpd.target
systemctl start vsftpd.target
I also had to restart vsftpd to get this to work:
systemctl restart vsftpd
After that, when connecting to FTP for site 1, everything worked as expected. When connecting to site 2 (the one with it's own unique SSL) I got the correct SSL.
I have my stun / turn server running on local pc (CoTurn). It is tested on "https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/" and works. I have a domain name and configured the modem with public ip. I configured apache2 to make the site visible to the world. I have active and valid letsencript certificates. Everything works in short. But the test application starts the connection (the external pc communicates with the local via socket.io) but then the video is not seen and the console returns the error: ICE failed, your TURN server appears to be broken, see about:webrtc for more details.
The link of the application that I use as a test, because with my original I had no comparisons to make. First time with socket.io. But socket.io send and receive messages so these not appear a problem for now.
https://github.com/anoek/webrtc-group-chat-example
P.S.:
Ok. Server is behind the nat. My app (but linked app too) work very fine on local network (sorry I checked this point first before). These with my turn/stun server, than with public stun/turns google servers. This evidently indicates a bad setting of apache2 server or/and turn server. Where could I find a guide about it?
My server situation: myServerIpLocal-xxx.xxx.xxx.xxx -> nat/router/modem WithPublicIpStatic-xx.xx.xx.xx. I can see my sites from all the world, but turn server not work outside the local network. Inside local network work ok.
these my turn config:
listening-port=3478
tls-listening-port=5349
alt-listening-port=3479
alt-tls-listening-port=5350
listening-ip=xxx.xxx.xxx.xxx /*mylocal ip*/
relay-ip=xxx.xxx.xxx.xxx /*mylocal ip*/
external-ip=xx.xx.xx.xx /*my public ip on nat/ruter/modem */
min-port=49152
max-port=65535
verbose
fingerprint
userdb=/var/lib/turn/turndb
realm=mysite.com
cert=/etc/ssl/certificate.pem
pkey=/etc/ssl/private.key
dh-file=/etc/turn/dhparam.pem
no-stdout-log
log-file=/myhome/.turn/turn.log
lt-cred-mech
user=myusername:mypasswd
# Turn OFF the CLI support.
# By default it is always ON.
# See also options cli-ip and cli-port.
#
no-cli
#Local system IP address to be used for CLI server endpoint. Default value
# is 127.0.0.1.
#
cli-ip=127.0.1.1
# CLI server port. Default is 5766.
#
cli-port=5766
# CLI access password. Default is empty (no password).
#
cli-password=logen
no-sslv3
no-tlsv1
my old code on turn.conf:
lt-cred-mech
user=myusername:mypasswd
but turn work only locally .... probabily because I use:
sudo turnserver -L myPublicIp -o -a myrealm
at every coturn start command ....
actually I try not use the command "turnserver" and I try to use onlu sudo coturn start .....
basically in my turn.conf file I change these:
lt-cred-mech
user=mypasswd:myusername /***** mind the gap ;) *****/
these because my index.js file debug never see my external connection as authrized user ..... magically at these time my app perform webrtc multiple connection with every pc and mobile .... inside and outside my lan .... (I try connect my appa from phone in barcelona spain to other one in london with good result).
May be coturn wiki need to update?
Finally I would like to thank the serverfault and super-user guys who rejected my question. Since I had to make arrangements, I was able to acquire new and interesting information on this subject.
regards
After a recent automatic update to linux components (CentOS v7 with PLesk 17.8.11) my web (php) applications are no longer enabled to do outbound connections.
Both "curl" requests and PHPMailer fail; curl is returning http code 0 with no content, while PHPMailer says "SMTP Connect() failed".
The same statements/programs work perfectly when run from terminal (root user). In other words, if I write a trivial program executing "curl http://www.example.com" and run it from terminal, it works; if I call it from a browser, it does not work.
The same is true for any program using PHPMailer to send a mail.
SELinux is disabled, so it does not depends on the httpd_can_network_connect SELinux boolean.
Any idea?
I found a solution, but I did not really understood what the real reason was. By default, my CentOS+Plesk server has SELinux disabled: I changed it to "enabled" with SELINUX=permissive, then I changed two SELinux booleans:
setsebool -P httpd_can_network_connect on
setsebool -P httpd_can_sendmail on
Even if SELinux is in warning-only mode, settings those two booleans on made the trick.
Most likely, affected domains are using system PHP, which was updated recently. Correct me if I am wrong.
What would explain broken PHP functionality, because during the update of system PHP package, Apache restart is not triggered by Plesk.
Simply restart Apache in Tools & Settings > Service Management or by using systemctl restart httpd. If the issue still persist after that, try to switch to any of Plesk PHP versions.
I have attempted everything recommended by the following error message:
(error) DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
My /etc/redis/sentinel.conf:
daemonize yes
sentinel myid XXX
sentinel monitor master XXX 6379 2
sentinel down-after-milliseconds master 60000
sentinel config-epoch master 0
protected-mode no
bind 0.0.0.0
port 26379
EDIT: My /etc/redis/redis.conf:
port 6379
bind 0.0.0.0
protected-mode no
I've also tried adding sentinel auth-pass master XXX.
My entire backend is on private subnets. I'm VPN'd into my datacenter behind the firewall, coming from the same private network, and I can still only connect locally without getting that frustrating error message.
Server Environment: Debian 8, Redis 3.2.6
Client Environment: Ubuntu 16.10, redis-cli 3.2.1
Redis instances: 3
Sentinel instances: 3
I've done not just one, but 3/4 of the things suggested (didn't set the command-line flags). Does anyone have any guidance or ideas? I'm clearly missing something that I've been unable to figure out from the error message, documentation, Stackoverflow, Google, and trial & error. I figured I'd post a question here first, before diving into the source code.
Any help is appreciated. Thanks!
... and, yes, I've restarted the daemons after configuration changes. :)
https://www.reddit.com/r/redis/comments/3zv85m/new_security_feature_redis_protected_mode/
As you know we got several problems from unprotected Redis instances exposed to the internet. I covered the reason why a restrictive binding to 127.0.0.1 by default may be an usability concern and, even worse, may not fix the problem (hey just comment the "bind" statement and restart!) in my blog post.
The same blog post introduced an attack that was heavily used by script kiddies to break into Redis instances (serious security researchers where already able to do this, I guess).
So I finally decided to do something before Redis 3.2 official release: Protected mode is the result and will be merged into 3.2 RC2.
The feature is already available in the unstable branch, introduced by this commit. This is how it works.
If and only if:
Protected mode is enabled (this is the default both in the configuration file and in the configless default).
AND IF No AUTH password is configured.
AND IF No "bind" directive is used in order to restrict Redis to certain interfaces.
Then Redis only accepts connections from the loopback IPv4 and IPv6 addresses. External connections are accepted just for the time to send the client an error that makes the user aware of what is happening:
> PING
(error) DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients.
In this mode connections are only accepted from the lookback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions:
Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent.
Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server.
If you started the server manually just for testing, restart it with the --protected-mode no option.
Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
This should protect errors in a reasonable way while providing users with a clue instead of a connection refused. Please share your feedbacks so that we can make changes to this feature if needed, before it will get merged into Redis 3.2 RC2. Thanks.
So I created a new Cpanel using WHM I set the quota to 50MB and the bandwidth to 50MB as well. And I also uploaded the web files to public_html on cpanel successfully but when I load the website, an error that says This webpage is not available ERR_CONNECTION_TIMED_OUT appear.
Here's the status screenshot.
And here's the screenshot of the files I uploaded.
But still I get the error. Did I missed something?
Since it is connection timed out, definitely it is related to firewall. Do you have any firewall installed like CSF ? If so please try to check if your ISP IP (you can get ISP IP from http://whatismyip.com ) is blocked in the firewall.
Another possiblity is your server is having Selinux enabled. To disable that please try to
setenforce 0
Another possiblity is server is having some default iptables rules
iptables -L -n
If the above command is showing rules, then try to stop it
service iptables stop
Let me know how it goes