Re: Fixing broken UTF-8 handling with MySQL driver
Am 12.03.2015 um 14:55 schrieb Timo Sirainen t...@iki.fi: On 11 Mar 2015, at 21:31, Felix Zandanel fe...@zandanel.me wrote: Although my MySQL installation is set up to use UTF-8 as the default charset on every level (config, database, table and field), and the character_set_* runtime variables all yield the value utf8, it still seems that the mysql client library must be instructed to actually use UTF-8 explicitly. Adding the following statement to driver_mysql_connect() fixes the issue for me: mysql_options(db-mysql, MYSQL_SET_CHARSET_NAME, utf8); I think you can also add to /etc/my.cnf : [client] default-character-set = utf8 Sorry for the late reply. You were so right, that simple line did the trick. My fault, I didn't read the whole charset documentation of MySQL. It's a shame that UTF-8 isn't the default setting. Anyway, as dovecot's internals expect all input strings to be UTF-8, wouldn't it be useful to enforce UTF-8 in the database drivers? Using anything else than ASCII / UTF-8 for dovecot's MySQL connections doesn't really make sense, I think. Also, a default-character-set = utf8 line in my.cnf is a system wide configuration, which might break other software interacting with MySQL—in theory. signature.asc Description: Message signed with OpenPGP using GPGMail
Fixing broken UTF-8 handling with MySQL driver
Hi,
I noticed that dovecot's MySQL driver doesn't play well with UTF-8 encoded
strings. I presume this issue has been around for a while. However, it still
fails with the current release candidate 2.2.16-rc1.
I have been using the sieve extdata plugin with a MySQL-backed dict to retrieve
a folder name that is then passed to fileinto:
fileinto :create ${extdata.folder_name_drafts};
Whenever this dict returned a string with non-7byte characters, a line such as
the following popped up in sieve.log. (This example query should return
Entwürfe.)
error: folder name specified for fileinto command is not utf-8: Entw?rfe.
Although my MySQL installation is set up to use UTF-8 as the default charset on
every level (config, database, table and field), and the character_set_*
runtime variables all yield the value utf8, it still seems that the mysql
client library must be instructed to actually use UTF-8 explicitly. Adding the
following statement to driver_mysql_connect() fixes the issue for me:
mysql_options(db-mysql, MYSQL_SET_CHARSET_NAME, utf8);
I checked this against mysql 5.5.41.
Regards,
Felix
mysql_utf8.patch
Description: Binary data
Re: IP drop list
Am 01.03.2015 um 10:25 schrieb Reindl Harald h.rei...@thelounge.net: Am 01.03.2015 um 08:53 schrieb Jim Pazarena: I wonder if there is an easy way to provide dovecot a flat text file of ipv4 #'s which should be ignored or dropped? I have accumulated 45,000+ IPs which routinely try dictionary and 12345678 password attempts. The file is too big to create firewall drops, and I don't want to compile with wrappers *if* dovecot has an easy ability to do this. If dovecot could parse a flat text file of IPs and drop connections it would sure put a dent in these attempts. hence i asked month ago for RBL support because such lists are easy to feed into http://www.corpit.ru/mjt/rbldnsd.html - sadly i got no reply than use fail2ban and what not irrelevant if there is already a local dnsbl I absolutely agree with Harald Reindl's findings on the advantages of DNSBL, but you have to see the big picture. Though I’ll speak about DNSBL a lot in this text, this is about blocking IPs in general. In my opinion, the *only* valid setup to use DNSBL are MTAs that accept mail from unauthenticated clients. That is because in such scenarios there are several heuristics you can safely use to distinguish the good from the bad. One of the most important aspects has to do with the distinction between mail submission and transmission. If you don’t want an open relay, you normally let your users authenticate before they can submit their mail. In any other case it’s safe to assume that the client is another MTA wanting to push a message over to you. We are talking about server systems here, not end users. Servers that should have a valid hostname, a static IP with no NAT in between etc. Blocking one IP in this case *should* really only block that one bad computer system. In the end, it’s perfectly OK to block clients that are either not authenticated, have no valid hostname, use dynamically assigned IPs etc. from accessing your MTA. Once having checked that one may put single IPs on a private block list to speed things up. In the case of HTTP, IMAP, etc. things are not so easy. Just think about NAT and CGN. You as a service provider *can* never know that there’s no collateral damage when you block an IP address. Every single IP out there could be a gateway to a private or even carrier grade network with hundreds or thousands of computers behind it. Some of them might be infected by malware or controlled by a bad guy. Some others might be those your clients use to download their mail. You’d lock them all out—just because you want to safe some server resources? Is it really worth it? Imagine one of your customers traveling abroad, using unusual POPs to access your dovecot instance. If the gateway IP that your server sees is blocked, you lock out your own customer. It’s the old tale. Some words of advice: (1) There’s no point in listing thousands of IPs without proper TTL. And that TTL should be short! If there really were 45 000 single /32 IPs that were behaving rude at some point in the past, how can you be sure these addresses are still doing so? Moreover, with IPv4 addresses being rare and IPv6 only being deployed slowly, CGN happens to be used more often than in the past. Even with IPv6, where prefixes were initially meant to be static, there are many ISPs that don’t give their line customers static IPv6 prefixes. That means attackers as well as your customers might end up using many different addresses over time. (2) If you run your own block list and were to add another IP, there should be sufficient knowledge about the origin of the attack. Always check the RIR whois databases, look at the delegated address range the IP is in, the country, the owner of the network, hostnames... Monitor your log files and try to detect patterns. [Honestly, I’d not be willing to invest the time ;-) ] (3) Use a scoring system. If there are other DNSBLs that list the IP or network in question, the likelihood of causing more harm than good is a bit lower than if you are the only one suffering an attack. Community based DNSBLs are commonly a good thing. You see, blocking IPs just because it’s simple and effective (for the moment) might not be what you want. I’d rather let my users choose stronger passwords, strongly enforce TLS and scale up my server systems to handle the bad traffic. Surely, it depends on your own case, just don’t be naïve and think that blocking IPs is a general solution to anything nowadays. It might very well work for you if you don’t have a lot of customers, though. Speaking about dovecot, I doubt direct DNSBL integration will happen upstream because dovecot already supports access lookups. You can use dovecot's tcpwrap and configure your /etc/hosts.deny to lookup an external ACL program that in turn consults your DNSBL. See man hosts_options, section RUNNING OTHER COMMANDS. Look for »aclexec«.[1] I guess that should get you on track. Just be warned that
Re: IP drop list
Am 04.03.2015 um 20:31 schrieb Reindl Harald h.rei...@thelounge.net: In the case of HTTP, IMAP, etc. things are not so easy. Just think about NAT and CGN that don't matter if i blacklist a client because he starts a dictionary attack in SMTP i want it also bock on IMAP without use a dozen of different tools because teh via IMAP now catched account password will be used for send spam later when the SMTP RBL entry expires That’s the point why DNSBLs are good: You can use them for many different services at once. However, the idea is to block attackers before they are able to succeed identifying a valid login credential AND not to block your customers that expect a service that just works. This is a trade off. If both the attacker (or a malware infected computer etc.) and your valid user sit behind the same CGN gateway then it does matter and that scenario is not uncommon. Blocking a rude boy for some time from continuing with the attack will likely cause him to stop entirely, at least for a much longer time than you blocking the address. If he proceeds afterwards, then you have no other choice than blocking the IP for longer anyway and maybe tell your users you are suffering an attack. I am not against block lists. I just say their use should be justified as they may decrease overall service quality as well. There is another solution for auth based services: As soon as you detect a possible attack (# auth reqs x etc.), keep the connection open, slow it down and just never let it succeed regardless of the credentials provided. This is done on a per-connection basis. No block list needed. Can be accomplished with fail2ban and iptables and therefore uses minimal server resources. Cheers, Felix signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Per-protocol ssl_protocols settings
I performed a quick test and it seems that the ssl_protocols setting is
per-IP only and shared among all listeners defined for that address. As you
want this setting to be active for one specific inet_listener only (with port
10995 in your case), dovecot would have to permit the ssl_protocols directive
in that scope, which it doesn’t.
As a workaround I suggest using a special, unused loopback address to which you
can apply the distinct SSL settings. You could use iptables/NAT to forward all
incoming traffic originating from your external IP on port 10995 to
127.0.0.2:10995 for example. Then configure the POP3 service with an
inet_listener for 127.0.0.2:10995 and use the local directive to set up the
SSL protocols without touching global settings:
local 127.0.0.2 {
ssl_protocols = !SSLv2
}
Regards,
Felix Zandanel
Am 09.02.2015 um 11:33 schrieb Gionatan Danti g.da...@assyoma.it:
Sorry for the bump...
Anyone know if it is possible to have multiple protocols instances with
different ssl_protocols settings?
Regards.
On 07/02/15 00:03, Gionatan Danti wrote:
Hi all,
anyone with some ideas?
Thanks.
Il 2015-02-02 23:08 Gionatan Danti ha scritto:
Hi all,
I have a question regarding the ssl_protocols parameter.
I understand that editing the 10-ssl.conf file I can set the
ssl_protocols variable as required.
At the same time, I can edit a single protocol file (eg: 20-pop3.conf)
to set the ssl_protocols for a specific protocol/listener.
I wander if (and how) I can create a different listener for another
POP3 instance, for example listening on port 10995, and using another
ssl_protocol setting.
In short, I would like to create a different, firewalled pop3s service
enabling the SSLv3 stack, while disabling it at system-wide settings.
I am able to successfully create a new listener for port 10995, but I
don't understand how to associate the ssl_protocols value to the new
listener. Simply putting the ssl_protocols value into the listener
section give me a configuration error.
Thank you all.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8
