Bug#396668: fail2ban: issues with default from on emails
OK, now that I have this working, I can verify that with 0.7, after enabling the mailing, the messages appear to come from [EMAIL PROTECTED] (obscuring actual domain). check your local MTA configuration, in particular /etc/mailname fail2ban is simply callin gmail command without specifying From at all - thus it takes root since it is running as root and it takes mail name of the box... or it depends how your system configured... just have a look at /etc/fail2ban/action.d/mail-whois.conf and actionban to see support for my words... Is it the case that there is no option to set the sender anymore (short of editing the command that sends the mail)? yep - you would need to override actionban in /etc/fail2ban/action.d/mail-whois.local in section [Definition] (or edit .conf file directly which I wouldn't recommend) Should fail2ban include some kind of dependency on a package that provides the mail command (I have mailx, which is priority important, and provides mail-reader)? I will add suggests to mailx I think... mail-reader is irrelevant I think - correct me if I am wrong P.S. mail-whois.conf includes # Destinataire of the mail dest = root I think the desired English is Destination not Destinataire. ;-) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgplelGMrxKpl.pgp Description: PGP signature
Bug#396668: fail2ban: issues with default from on emails
On Sun, Nov 26, 2006 at 01:57:46AM -0500, Yaroslav Halchenko wrote: ... Should fail2ban include some kind of dependency on a package that provides the mail command (I have mailx, which is priority important, and provides mail-reader)? I will add suggests to mailx I think... mail-reader is irrelevant I think - correct me if I am wrong Yes, mail-reader looks too broad. Based on apt-file, maybe mailx | mailutils ? I notice a bunch of packages do depend on mailx alone, so maybe that's appropriate. Another alternative would be to use the /usr/sbin/sendmail interface in the commands. I suspect most MTA's provide it (exim does, and obviously sendmail does). A note in README.Debian, or maybe the package description would be good too (e.g., If you edit the configuration to send mail notifications, you will need the suggested mail package.) Ross -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396668: fail2ban: issues with default from on emails
On Tue, Nov 14, 2006 at 01:01:31PM -0500, Yaroslav Halchenko wrote: As I said that the problem (bad From address) is obsolete in 0.7.x, so if you don't mind installing it (0.7.4-3), enabling mail (follow instructions in /etc/fail2ban/jail.conf), and verifying that received email has proper From field (must be root@mailhostname) Thank you in advance! On Tue, 14 Nov 2006, Ross Boylan wrote: On Tue, Nov 14, 2006 at 10:29:40AM -0500, Yaroslav Halchenko wrote: Hi Ross, BTW - given issue is obsolete in 0.7.x which is in unstable already. Could you please verify that ;-) I'm not sure what you mean to verify, but $ apt-show-versions -a fail2ban fail2ban0.6.1-11install ok installed fail2ban0.6.1-11testing fail2ban0.6.1-11testing fail2ban0.7.4-3 unstable fail2ban/testing uptodate 0.6.1-11 (though it sends email to [EMAIL PROTECTED] which I believe must be ok) The problem is with the sender of the email, not the recipient. I have some doubts about localhost, as mentioned in earlier messages for this bug. OK, now that I have this working, I can verify that with 0.7, after enabling the mailing, the messages appear to come from [EMAIL PROTECTED] (obscuring actual domain). Is it the case that there is no option to set the sender anymore (short of editing the command that sends the mail)? Should fail2ban include some kind of dependency on a package that provides the mail command (I have mailx, which is priority important, and provides mail-reader)? P.S. mail-whois.conf includes # Destinataire of the mail # dest = root I think the desired English is Destination not Destinataire. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396668: fail2ban: issues with default from on emails
Hi Ross, BTW - given issue is obsolete in 0.7.x which is in unstable already. Could you please verify that ;-) (though it sends email to [EMAIL PROTECTED] which I believe must be ok) On Sun, 12 Nov 2006, Ross Boylan wrote: On Fri, Nov 10, 2006 at 06:18:49PM -0500, Yaroslav Halchenko wrote: Thank you Ross for reporting the issue. Would you consider it to be a reincarnation of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329722 ? thus option d) in your list? Then I would like to close/merge them (unless we continue discussion) It's certainly in the same neighborhood. However, the focus of the earlier bug was on the domain of the email address (which the second point in this bug discusses), while this one concerns the part before the @ sign as well. -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpg9oYX0DEw6.pgp Description: PGP signature
Bug#396668: fail2ban: issues with default from on emails
On Tue, Nov 14, 2006 at 10:29:40AM -0500, Yaroslav Halchenko wrote: Hi Ross, BTW - given issue is obsolete in 0.7.x which is in unstable already. Could you please verify that ;-) I'm not sure what you mean to verify, but $ apt-show-versions -a fail2ban fail2ban0.6.1-11install ok installed fail2ban0.6.1-11testing fail2ban0.6.1-11testing fail2ban0.7.4-3 unstable fail2ban/testing uptodate 0.6.1-11 (though it sends email to [EMAIL PROTECTED] which I believe must be ok) The problem is with the sender of the email, not the recipient. I have some doubts about localhost, as mentioned in earlier messages for this bug. Ross On Sun, 12 Nov 2006, Ross Boylan wrote: On Fri, Nov 10, 2006 at 06:18:49PM -0500, Yaroslav Halchenko wrote: Thank you Ross for reporting the issue. Would you consider it to be a reincarnation of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329722 ? thus option d) in your list? Then I would like to close/merge them (unless we continue discussion) It's certainly in the same neighborhood. However, the focus of the earlier bug was on the domain of the email address (which the second point in this bug discusses), while this one concerns the part before the @ sign as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396668: fail2ban: issues with default from on emails
As I said that the problem (bad From address) is obsolete in 0.7.x, so if you don't mind installing it (0.7.4-3), enabling mail (follow instructions in /etc/fail2ban/jail.conf), and verifying that received email has proper From field (must be root@mailhostname) Thank you in advance! On Tue, 14 Nov 2006, Ross Boylan wrote: On Tue, Nov 14, 2006 at 10:29:40AM -0500, Yaroslav Halchenko wrote: Hi Ross, BTW - given issue is obsolete in 0.7.x which is in unstable already. Could you please verify that ;-) I'm not sure what you mean to verify, but $ apt-show-versions -a fail2ban fail2ban0.6.1-11install ok installed fail2ban0.6.1-11testing fail2ban0.6.1-11testing fail2ban0.7.4-3 unstable fail2ban/testing uptodate 0.6.1-11 (though it sends email to [EMAIL PROTECTED] which I believe must be ok) The problem is with the sender of the email, not the recipient. I have some doubts about localhost, as mentioned in earlier messages for this bug. -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpt7KyVCNsoV.pgp Description: PGP signature
Bug#396668: fail2ban: issues with default from on emails
On Fri, Nov 10, 2006 at 06:18:49PM -0500, Yaroslav Halchenko wrote: Thank you Ross for reporting the issue. Would you consider it to be a reincarnation of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329722 ? thus option d) in your list? Then I would like to close/merge them (unless we continue discussion) It's certainly in the same neighborhood. However, the focus of the earlier bug was on the domain of the email address (which the second point in this bug discusses), while this one concerns the part before the @ sign as well. Would the solution for that one suffice in this case? or may be I should take a) step since I consider Changing the sender to root seems like a good idea. I'm less clear about what to do with the domain. b) unnecessary user names space pollution -- fail2ban has to run as root in any case c) although it sounds neat, since there is no unified framework to introduce changes into /etc/aliases and keep/remove them, I would prefer to stay out of it. I might be ignorant and if there is a better way than echo 'fail2ban: root' /etc/aliases ... and sed -i -e 's/^fail2ban.*//g' on purge - please let me know, I might rethink Thanks in advance for your output I think getting a good default sender is the easiest solution. Unfortunately, it seems likely that reasonably configured systems could reject unqualified senders (root) or ones qualified with meaningless domains ([EMAIL PROTECTED]). I'll ask some of the debian-exim people about this. Ross -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396668: fail2ban: issues with default from on emails
Thank you Ross for reporting the issue. Would you consider it to be a reincarnation of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329722 ? thus option d) in your list? Then I would like to close/merge them (unless we continue discussion) Would the solution for that one suffice in this case? or may be I should take a) step since I consider b) unnecessary user names space pollution -- fail2ban has to run as root in any case c) although it sounds neat, since there is no unified framework to introduce changes into /etc/aliases and keep/remove them, I would prefer to stay out of it. I might be ignorant and if there is a better way than echo 'fail2ban: root' /etc/aliases ... and sed -i -e 's/^fail2ban.*//g' on purge - please let me know, I might rethink Thanks in advance for your output -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpdlvmnpIgv1.pgp Description: PGP signature
Bug#396668: fail2ban: issues with default from on emails
Package: fail2ban Version: 0.6.1-11 Severity: minor The default configuration uses # Option: from # Notes.: e-mail address of the sender. # Values: MAIL Default: fail2ban # from = [EMAIL PROTECTED] 2 issues with this. First, fail2ban is not a user on the system. As a result, the mail may be rejected by sender verification. I see several possible approaches: a) change the sender to a real user, like root b) create a fail2ban user c) create some kind of alias so that fail2ban is acceptable d) document the current behavior and options for dealing with it e) decide that someone who is verifying senders on their own system is being perverse, and do nothing. However, note that such checks can prevent spoofing if users are not trusted, and that fail2ban email might go to some machine other than the one originating the message. Second, the use of @localhost seems like asking for trouble. If it's preserved, but the message is routed to another machine, this will be disorienting at best. I'm not even sure it's a legitmate domain for an email address. It may be that all MTA's will clean this up, but they would probably clean up an unqualified name (just fail2ban without @anything) as well. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (990, 'stable'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27advncdfs Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages fail2ban depends on: ii iptables1.3.5.0debian1-1 Linux kernel 2.4+ iptables adminis ii lsb-base3.1-15 Linux Standard Base 3.1 init scrip ii python 2.4.3-11 An interactive high-level object-o ii python-central 0.5.6register and build utility for Pyt fail2ban recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
