Re: sendmail localhost rDNS
On Tue, Aug 11, 2009 at 10:56:57AM +0200, Joerg Morbitzer wrote: I just did a fresh sendmail installation on Debian Etch getting this auto-generated new /etc/mail/access file: titan:~# grep ^Connect:.*RELAY /etc/mail/access Connect:localhost RELAY Connect:127 RELAY Connect:[IPv6:::1] RELAY titan:~# Although it only binds to 127.0.0.1 and ::1 by default, Debian Lenny has the same default /etc/mail/access, which turns the whole Doctor, it hurts when I do this! discussion into Doctor, it hurts when you do this to me! On the other hand, I was not able to reproduce the problem on a Lenny virtual machine in my test environment. After I tampered with rDNS so that the sending system would resolve to 'localhost', Sendmail did indeed record the hostname 'localhost' in log messages, but it was always accompanied by the sending system's IP address and the note 'may be forged'. Even with the ability to control forward resolution of localhost (which requires commenting out the localhost lines in /etc/hosts or altering NSS configuration), I was able to get rid of the may be forged warnings but wasn't able to relay. I don't have any suitable Etch images prepared (and didn't want to sit through an installation), so I didn't run a test from a clean install, but in limited testing on an existing Etch system with the default Connect:localhost RELAY line in /etc/mail/access, I could not get the system to relay mail that it shouldn't have. Notes on test procedure: The Lenny Sendmail installation was entirely default, except that sendmail.mc was edited to allow Sendmail to bind all interfaces on the system. BIND was installed on the same system and provided with a suitably altered version of my number-to-name zone. The /etc/resolv.conf file was altered to point only at this new nameserver. To test ability to control forward resolution of 'localhost', I commented out all 'localhost' lines in /etc/mail/access and added a new line which matched the information my test DNS server was delivering. I did not perform tests on the Etch system that required altering /etc/hosts. On the Etch Here is a session transcript from a conversation with the Lenny system (with hostnames and IP addresses altered). Note that the same results happend regardless of whether I HELO'd with 'localhost', the target system's hostname, or some other name. | 220 vmtest1.a.test ESMTP Sendmail 8.14.3/8.14.3/Debian-5; Wed, 12 Aug 2009 16:43:04 -0600; (No UCE/UBE) logging access from: [x.x.x.5](FORGED)-localhost [x.x.x.5] (may be forged) | helo myhostname | 250 vmtest1.a.test Hello localhost [x.x.x.5] (may be forged), pleased to meet you | mail from: us...@a.test | 250 2.1.0 us...@a.test... Sender ok | rcpt to: us...@a.test | 550 5.7.1 us...@a.test... Relaying denied. IP name possibly forged [x.x.x.5] | quit | 221 2.0.0 vmtest1.a.test closing connection Here is a (hand-retyped) section of the mail log for the above session: | Aug 12 16:43:15 vmtest1 sm-mta[4761]: n7CMh4Q5004761: ruleset=check_rcpt, arg1=us...@a.test, relay=localhost [x.x.x.5] (may be forged), reject=550 5.7.1 us...@a.test... Relaying denied. IP name possibly forged [x.x.x.5] | Aug 12 16:43:16 vmtest1 sm-mta[4761]: n7CMh4Q5004761: from=us...@a.test, size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=localhost [x.x.x.5] (may be forged) -- William Aoki KD7YAFwa...@umnh.utah.edu5-1924 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
* Lupe Christoph l...@lupe-christoph.de [090810 21:13]: Almost all security holes need to user to do something. (If only to power up the machine, to install some packages, to connect to the internet, to give accounts to users). The question cannot be that something has to be done do make people vulnerable, but whether properly sane and educated people can guess that something opens a security problem. I interpret this to mean that there should be DSAs for all problems *made possible* by Debian packages, rather than those *caused* by the package. What I try to tell you is that I do not share your interpretion of caused. If bash had a bug to always include . in PATH, would that cause a problem or make a problem possible? (After all, noone forces you do switch to other peoples directories before doing ls). If a webbrowser has a problem executing arbitrary stuff told by the website visited, is that a security problem caused or made possible by the webbrowser. (After all, if you do not visit untrusted sites, there is no problem). If sshd had a bug so that PermitRootLogin without-password (which is not the default) allowed people to login without any identification as root instead of what it is supposed to be, would that be bug caused by ssh or a bug made possible by ssh? So it is in my eyes to criteria at all that the user has to change some configuration. The question is whether this change is supposed to cause the effects it does and if a user can be expected to understand the effects. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
Re, Lupe Christoph wrote: On Monday, 2009-08-10 at 14:35:06 +0200, Bernhard R. Link wrote: * Lupe Christoph l...@lupe-christoph.de [090810 13:53]: On Monday, 2009-08-10 at 13:46:38 +0200, Thomas Liske wrote: last week, there was an article on heise security about MTAs[1] which relay mails for hosts having a reverse resolution of 'localhost'. Doing a small test shows that sendmail on etch seems to be vulnerable, too. I need to have a localhost RELAY line in my access file (which is not default AFAIK). Will there be a DSA on this issue, since it seems to turn Sendmail installations with allowed localhost RELAYing into Open Relays? Are you saying you want a DSA for a package that does not have that particular vulnerability, but allows a user to create it? Doctor, it hurts when I do this! Don't do it, then. Help, help my computer does funny things! Don't power it up, then. That's not what I meant. Admitted, the quote is more funny than exact (and it isn;t particularly funny...). What I mean is that a lot of software allows the user to shoot himself in various body parts. One such example is rm. As in rm * .o. Oooops. If 'rm foo' has the same effect like 'rm -rf /', than rm would be broken. If '127.0.0.1 RELAY' has the same effect like '* RELAY' than sendmail is broken. More related to the OP, sendmail allows you to configure an open relay in a number of ways, not all of them as easily identified as the localhost problem. It has a built-in write-only language... This has nothing todo with the OP. But why would the posssibility to configure the package to open a relay warrant a DSA? It would IMNSHO only when the package came preconfigured to do that. yep, I think most of the recent DSAs shouldn't be published. The packages can be exploided if feed with user data - this is a change to the preconfigured setup !!! Almost all security holes need to user to do something. (If only to power up the machine, to install some packages, to connect to the internet, to give accounts to users). The question cannot be that something has to be done do make people vulnerable, but whether properly sane and educated people can guess that something opens a security problem. I interpret this to mean that there should be DSAs for all problems *made possible* by Debian packages, rather than those *caused* by the package. It is caused by the package, due the implementation of the access.db handling. If netfilter wouldn't drop/reject any packets, you won't issue an DSA? The preconfiguration doesn't ship any rules, so nobody should care if netfilter doesn't work in stable... Regards, Thomas PS: The guy who went to the doctor has died by disease last week. If the doc would have take a look at the guy, he would still be alive. -- supp...@ibh.de Tel. +49 351 477 77 30 www.ibh.de Fax +49 351 477 77 39 --- Dipl.-Ing. Thomas Liske Netzwerk- und System-Design IBH IT-Service GmbH Amtsgericht Dresden Gostritzer Str. 61-63 HRB 13626 D-01217 Dresden GF: Prof. Dr. Thomas Horn Germany VAT DE182302907 --- Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV --- professioneller IT-Service - kompetent und zuverlässig --- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
OK, I give up. And shut up. Please file a bug against the sendmail package, with the information that sendmail allows you to enter Connect:localhost RELAY in /etc/mail/access. And another one that Connect:127.0.0.1 RELAY opens up the same hole as Connect:localhost RELAY. Since I have no sendmail installation to use for testing, I can't reproduce the second problem. The sendmail package maintainer will probably require the submitter to provide details which I can't. Thank you, Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
On Tuesday, 2009-08-11 at 10:32:04 +0200, Bernhard R. Link wrote: * Lupe Christoph l...@lupe-christoph.de [090810 21:13]: Almost all security holes need to user to do something. (If only to power up the machine, to install some packages, to connect to the internet, to give accounts to users). The question cannot be that something has to be done do make people vulnerable, but whether properly sane and educated people can guess that something opens a security problem. I interpret this to mean that there should be DSAs for all problems *made possible* by Debian packages, rather than those *caused* by the package. What I try to tell you is that I do not share your interpretion of caused. If bash had a bug to always include . in PATH, would that cause a problem or make a problem possible? (After all, noone forces you do switch to other peoples directories before doing ls). That would be a defect in the package that requires no user configuration. The equivalent of Connect:localhost RELAY would be this in .bashrc: PATH=.:$PATH . If a webbrowser has a problem executing arbitrary stuff told by the website visited, is that a security problem caused or made possible by the webbrowser. (After all, if you do not visit untrusted sites, there is no problem). That is a defect in the webbrowser. It requires no user configuration. If sshd had a bug so that PermitRootLogin without-password (which is not the default) allowed people to login without any identification as root instead of what it is supposed to be, would that be bug caused by ssh or a bug made possible by ssh? That is a bug because sshd does not what is documented. Suppose sshd_config had an option PermitRootLogin always, meaning that no password or key is required to log in as root. Would it be a bug of sshd to include this option or a misfeature? So it is in my eyes to criteria at all that the user has to change some configuration. The question is whether this change is supposed to cause the effects it does and if a user can be expected to understand the effects. Please go ahead and file security-related bugs against all packages that allow the user to open security holes by changing the default configuration. I suppose we should agree to disagree and terminate this thread here. Of course I will not restrict your freedom to answer to this mail, but I will leave your reply unanswered because I believe we won't ever agree. Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
Lupe Christoph wrote: OK, I give up. And shut up. Please file a bug against the sendmail package, with the information that sendmail allows you to enter Connect:localhost RELAY in /etc/mail/access. And another one that Connect:127.0.0.1 RELAY opens up the same hole as Connect:localhost RELAY. Since I have no sendmail installation to use for testing, I can't reproduce the second problem. The sendmail package maintainer will probably require the submitter to provide details which I can't. Thank you, Lupe Christoph I just did a fresh sendmail installation on Debian Etch getting this auto-generated new /etc/mail/access file: titan:~# grep ^Connect:.*RELAY /etc/mail/access Connect:localhost RELAY Connect:127 RELAY Connect:[IPv6:::1] RELAY titan:~# Regards, Joerg. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
* Lupe Christoph l...@lupe-christoph.de [090811 10:56]: So it is in my eyes no criteria at all that the user has to change some configuration. The question is whether this change is supposed to cause the effects it does and if a user can be expected to understand the effects. Please go ahead and file security-related bugs against all packages that allow the user to open security holes by changing the default configuration. I suppose we should agree to disagree and terminate this thread here. Of course I will not restrict your freedom to answer to this mail, but I will leave your reply unanswered because I believe we won't ever agree. Thanks for not restricting my freedom to reply to a mail that ridicules what I say by drawing absurd conclusions out of it. I never said that being able to change a configuration to open holes is in itself and always a security problem. What I am saying is that needing user action or having to change a configuration file is no reason at all to claim that something is not a security problem. Annoyed, Bernhard R. Link That is a bug because sshd does not what is documented. Suppose sshd_config had an option PermitRootLogin always, meaning that no password or key is required to log in as root. Would it be a bug of sshd to include this option or a misfeature? Of course not. And being able to add an option to sendmail to allow everyone to relay would of course also definitely be no problem if it was documentated to do so and has a sensible name. And noone in this thread claimed it would be. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
If sendmail would do a double lookup verify on the reverse DNS records, there would be no problem at all. When some obscure IP address has reverse DNS pointer record localhost and sendmail would do another lookup to see what IP address belongs to localhost, then it would not match (obscure IP != 127.0.0.1) and the access DB rule should not be valid for this connection. Could someone from the Debian security team do some test and check if sendmail does the double lookup verify? If not, a DSA would be appropriate and it should be patched. With kind regards, Michiel Klaver IT professional At 11-8-2009 10:45, Lupe Christoph wrote: OK, I give up. And shut up. Please file a bug against the sendmail package, with the information that sendmail allows you to enter Connect:localhost RELAY in /etc/mail/access. And another one that Connect:127.0.0.1 RELAY opens up the same hole as Connect:localhost RELAY. Since I have no sendmail installation to use for testing, I can't reproduce the second problem. The sendmail package maintainer will probably require the submitter to provide details which I can't. Thank you, Lupe Christoph -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
sendmail localhost rDNS
Hi, last week, there was an article on heise security about MTAs[1] which relay mails for hosts having a reverse resolution of 'localhost'. Doing a small test shows that sendmail on etch seems to be vulnerable, too. I need to have a localhost RELAY line in my access file (which is not default AFAIK). Will there be a DSA on this issue, since it seems to turn Sendmail installations with allowed localhost RELAYing into Open Relays? Cheers, Thomas [1] http://www.h-online.com/security/Naming-trick-opens-mail-servers--/news/113946 -- supp...@ibh.de Tel. +49 351 477 77 30 www.ibh.de Fax +49 351 477 77 39 --- Dipl.-Ing. Thomas Liske Netzwerk- und System-Design IBH IT-Service GmbH Amtsgericht Dresden Gostritzer Str. 61-63 HRB 13626 D-01217 Dresden GF: Prof. Dr. Thomas Horn Germany VAT DE182302907 --- Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV --- professioneller IT-Service - kompetent und zuverlässig --- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
On Monday, 2009-08-10 at 13:46:38 +0200, Thomas Liske wrote: last week, there was an article on heise security about MTAs[1] which relay mails for hosts having a reverse resolution of 'localhost'. Doing a small test shows that sendmail on etch seems to be vulnerable, too. I need to have a localhost RELAY line in my access file (which is not default AFAIK). Will there be a DSA on this issue, since it seems to turn Sendmail installations with allowed localhost RELAYing into Open Relays? Are you saying you want a DSA for a package that does not have that particular vulnerability, but allows a user to create it? Doctor, it hurts when I do this! Don't do it, then. Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
Re, #Lupe Christoph wrote: On Monday, 2009-08-10 at 13:46:38 +0200, Thomas Liske wrote: last week, there was an article on heise security about MTAs[1] which relay mails for hosts having a reverse resolution of 'localhost'. Doing a small test shows that sendmail on etch seems to be vulnerable, too. I need to have a localhost RELAY line in my access file (which is not default AFAIK). Will there be a DSA on this issue, since it seems to turn Sendmail installations with allowed localhost RELAYing into Open Relays? Are you saying you want a DSA for a package that does not have that particular vulnerability, but allows a user to create it? if an access line like: Connect:localhost RELAY turns a MTA into an Open Relay than I would prefere a DSA, since the ACL implementation is broken IMHO. Regards, Thomas -- supp...@ibh.de Tel. +49 351 477 77 30 www.ibh.de Fax +49 351 477 77 39 --- Dipl.-Ing. Thomas Liske Netzwerk- und System-Design IBH IT-Service GmbH Amtsgericht Dresden Gostritzer Str. 61-63 HRB 13626 D-01217 Dresden GF: Prof. Dr. Thomas Horn Germany VAT DE182302907 --- Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV --- professioneller IT-Service - kompetent und zuverlässig --- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
On Monday, 2009-08-10 at 14:03:44 +0200, Thomas Liske wrote: #Lupe Christoph wrote: On Monday, 2009-08-10 at 13:46:38 +0200, Thomas Liske wrote: last week, there was an article on heise security about MTAs[1] which relay mails for hosts having a reverse resolution of 'localhost'. Doing a small test shows that sendmail on etch seems to be vulnerable, too. I need to have a localhost RELAY line in my access file (which is not default AFAIK). Will there be a DSA on this issue, since it seems to turn Sendmail installations with allowed localhost RELAYing into Open Relays? Are you saying you want a DSA for a package that does not have that particular vulnerability, but allows a user to create it? if an access line like: Connect:localhost RELAY turns a MTA into an Open Relay than I would prefere a DSA, since the ACL implementation is broken IMHO. Well, a line like this: Connect:spammer.comRELAY does the same, so, as I said, just don't do it. I still don't see why on one hand you say that you need a localhost line, and then complain that it hurts you. Why can't you use 127.0.0.1 or localhost.mydomain? Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
On Mon, 2009-08-10 at 14:03 +0200, Thomas Liske wrote: if an access line like: Connect:localhost RELAY turns a MTA into an Open Relay than I would prefere a DSA, since the ACL implementation is broken IMHO. As long as reverse DNS can be faked, I would never use hostnames in my configuration files like that. If the debian package doesn't ship with this ACL as default, I don't see reason for a DSA. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
Re, Jan de Groot wrote: On Mon, 2009-08-10 at 14:03 +0200, Thomas Liske wrote: if an access line like: Connect:localhost RELAY turns a MTA into an Open Relay than I would prefere a DSA, since the ACL implementation is broken IMHO. As long as reverse DNS can be faked, I would never use hostnames in my configuration files like that. If the debian package doesn't ship with this ACL as default, I don't see reason for a DSA. the problem is even more worse. Replacing localhost with 127.0.0.1 as suggested by Lupe Christoph doesn't change anything. I can still relay if my reverse DNS resolves to localhost. Regards, Thomas -- supp...@ibh.de Tel. +49 351 477 77 30 www.ibh.de Fax +49 351 477 77 39 --- Dipl.-Ing. Thomas Liske Netzwerk- und System-Design IBH IT-Service GmbH Amtsgericht Dresden Gostritzer Str. 61-63 HRB 13626 D-01217 Dresden GF: Prof. Dr. Thomas Horn Germany VAT DE182302907 --- Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV --- professioneller IT-Service - kompetent und zuverlässig --- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
* Jan de Groot j...@jgc.homeip.net [090810 14:22]: On Mon, 2009-08-10 at 14:03 +0200, Thomas Liske wrote: if an access line like: Connect:localhost RELAY turns a MTA into an Open Relay than I would prefere a DSA, since the ACL implementation is broken IMHO. As long as reverse DNS can be faked, I would never use hostnames in my configuration files like that. How common is programs verifying reverse DNS by doing forward DNS of the result? At least all programs relying on this information I've yet met consciously had it. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
* Lupe Christoph l...@lupe-christoph.de [090810 13:53]: On Monday, 2009-08-10 at 13:46:38 +0200, Thomas Liske wrote: last week, there was an article on heise security about MTAs[1] which relay mails for hosts having a reverse resolution of 'localhost'. Doing a small test shows that sendmail on etch seems to be vulnerable, too. I need to have a localhost RELAY line in my access file (which is not default AFAIK). Will there be a DSA on this issue, since it seems to turn Sendmail installations with allowed localhost RELAYing into Open Relays? Are you saying you want a DSA for a package that does not have that particular vulnerability, but allows a user to create it? Doctor, it hurts when I do this! Don't do it, then. Help, help my computer does funny things! Don't power it up, then. Almost all security holes need to user to do something. (If only to power up the machine, to install some packages, to connect to the internet, to give accounts to users). The question cannot be that something has to be done do make people vulnerable, but whether properly sane and educated people can guess that something opens a security problem. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
On Monday, 2009-08-10 at 14:35:06 +0200, Bernhard R. Link wrote: * Lupe Christoph l...@lupe-christoph.de [090810 13:53]: On Monday, 2009-08-10 at 13:46:38 +0200, Thomas Liske wrote: last week, there was an article on heise security about MTAs[1] which relay mails for hosts having a reverse resolution of 'localhost'. Doing a small test shows that sendmail on etch seems to be vulnerable, too. I need to have a localhost RELAY line in my access file (which is not default AFAIK). Will there be a DSA on this issue, since it seems to turn Sendmail installations with allowed localhost RELAYing into Open Relays? Are you saying you want a DSA for a package that does not have that particular vulnerability, but allows a user to create it? Doctor, it hurts when I do this! Don't do it, then. Help, help my computer does funny things! Don't power it up, then. That's not what I meant. Admitted, the quote is more funny than exact (and it isn;t particularly funny...). What I mean is that a lot of software allows the user to shoot himself in various body parts. One such example is rm. As in rm * .o. Oooops. More related to the OP, sendmail allows you to configure an open relay in a number of ways, not all of them as easily identified as the localhost problem. It has a built-in write-only language... But why would the posssibility to configure the package to open a relay warrant a DSA? It would IMNSHO only when the package came preconfigured to do that. Almost all security holes need to user to do something. (If only to power up the machine, to install some packages, to connect to the internet, to give accounts to users). The question cannot be that something has to be done do make people vulnerable, but whether properly sane and educated people can guess that something opens a security problem. I interpret this to mean that there should be DSAs for all problems *made possible* by Debian packages, rather than those *caused* by the package. Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Still problems with sendmail updates in Stable (libsasl2)
Hi! I still have dependency problems with the sendmail update on Stable. I only get libsasl2 2.1.19-1.5sarge1 from security.debian.org while the sendmail-bin package depends on libsasl2 (= 2.1.19.dfsg1). When can one expect to be able to install the sendmail update? Thank you, Lupe Christoph -- | You know we're sitting on four million pounds of fuel, one nuclear | | weapon and a thing that has 270,000 moving parts built by the lowest | | bidder. Makes you feel good, doesn't it? | | Rockhound in Armageddon, 1998, about the Space Shuttle | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Still problems with sendmail updates in Stable (libsasl2)
On Tuesday, 2006-08-29 at 09:06:46 +0200, Lupe Christoph wrote: I still have dependency problems with the sendmail update on Stable. I only get libsasl2 2.1.19-1.5sarge1 from security.debian.org while the sendmail-bin package depends on libsasl2 (= 2.1.19.dfsg1). When can one expect to be able to install the sendmail update? DSA-1155-2 must have slipped by me unnoticed. While I do not like the method (I believe all required packages should be available from security.debian.org), I will do as described. Fortunately only two of my Debian machines run sendmail, while most use Postfix. Lupe Christoph -- | You know we're sitting on four million pounds of fuel, one nuclear | | weapon and a thing that has 270,000 moving parts built by the lowest | | bidder. Makes you feel good, doesn't it? | | Rockhound in Armageddon, 1998, about the Space Shuttle | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sendmail-bin: uninstallable due to unavailable libsasl2 (= 2.1.19.dfsg1)
Package: sendmail-bin Version: 8.13.4-3sarge2 Severity: grave Tags: sarge, security Hello, the just released security fix package 8.13.4-3sarge2 does not install on sarge, because it depends on libsasl2 (= 2.1.19.dfsg1) while on sarge only libsasl2 (2.1.19-1.5sarge1) is available. Package: sendmail-bin Version: 8.13.4-3sarge2 Depends: ..., libsasl2 (= 2.1.19.dfsg1), ... Package: libsasl2 Version: 2.1.19-1.5sarge1 I'm not sure whether this bug is to be best off, so I'm CC:ing debian-security@lists.debian.org as hinted in the Security Advisory. regards Mario -- User sind wie ideale Gase - sie verteilen sich gleichmaessig ueber alle Platten signature.asc Description: Digital signature
Re: sendmail-bin: uninstallable due to unavailable libsasl2 (= 2.1.19.dfsg1)
And if you just install libsasl2 2.1.19.dfsg1 from DSA 1155-2, you end up with a number of other failing dependecies: canardo:/tmp# apt-get dist-upgrade Reading Package Lists... Done Building Dependency Tree... Done You might want to run `apt-get -f install' to correct these. The following packages have unmet dependencies: libsasl2-modules: Depends: libsasl2 (= 2.1.19-1.5sarge1) but 2.1.19.dfsg1-0sarge2 is installed libsasl2-modules-gssapi-heimdal: Depends: libsasl2 (= 2.1.19-1.5sarge1) but 2.1.19.dfsg1-0sarge2 is installed libsasl2-modules-kerberos-heimdal: Depends: libsasl2 (= 2.1.19-1.5sarge1) but 2.1.19.dfsg1-0sarge2 is installed E: Unmet dependencies. Try using -f. Bjørn pgpgGqMhvIf4k.pgp Description: PGP signature
Re: [TGSysadmin] [SECURITY] [DSA 1155-1] New sendmail packages fix denial of service
On Thu, Aug 24, 2006 at 08:23:59AM +0200, Martin Schulze [EMAIL PROTECTED] wrote: [...] a MIME conversion routine in sendmail, a powerful, efficient, and scalable mail transport agent, could be tricked [...] Funny, bias in errata reports. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [TGSysadmin] [SECURITY] [DSA 1155-1] New sendmail packages fix denial of service
On Thu, Aug 24, 2006 at 09:17:06AM -0400, Paul Nesbit [EMAIL PROTECTED] wrote: On Thu, Aug 24, 2006 at 08:23:59AM +0200, Martin Schulze [EMAIL PROTECTED] wrote: [...] a MIME conversion routine in sendmail, a powerful, efficient, and scalable mail transport agent, could be tricked [...] Funny, bias in errata reports. Oops--sorry, meant to be an internal reply. Paul -- Paul Nesbit System Administrator TransGaming Technologies Inc. http://www.transgaming.com 445 King St. West, Suite 201 Toronto, Ontario M5V 1K4 +1 416 979 9900 ext.331 Broadening The Playing Field -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [TGSysadmin] [SECURITY] [DSA 1155-1] New sendmail packages fix denial of service
On Thu, Aug 24, 2006 at 09:17:06AM -0400, Paul Nesbit wrote: On Thu, Aug 24, 2006 at 08:23:59AM +0200, Martin Schulze [EMAIL PROTECTED] wrote: [...] a MIME conversion routine in sendmail, a powerful, efficient, and scalable mail transport agent, could be tricked [...] Funny, bias in errata reports. All DSA notices have a description like that. These descriptions come from the package itself. eg: [EMAIL PROTECTED]:~$ apt-cache show sendmail | grep Desc Description: powerful, efficient, and scalable Mail Transport Agent Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/
Sendmail security fix for stable?
Hi, The version of Sendmail in sarge is vulnerable to CVE-2006-1173 from what I can determine, and there's been a fixed version in testing for some time, but what's happened to stable? regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fwd: [NATIONAL-ALERTS] (AUSCERT AL-2006.0048) [UNIX/Linux][Win] - Sendmail fails to handle malformed multipart MIME messages
Sourced from AusCERT. andrew -- Forwarded message -- From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wed, 14 Jun 2006 23:49:01 UT Subject: [NATIONAL-ALERTS] (AUSCERT AL-2006.0048) [UNIX/Linux][Win] - Sendmail fails to handle malformed multipart MIME messages To: [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 === A U S C E R T A L E R T AL-2006.0048 -- AUSCERT ALERT [UNIX/Linux][Win] Sendmail fails to handle malformed multipart MIME messages 15 June 2006 === AusCERT Alert Summary - Product: Sendmail 8.13.6 and prior Publisher:US-CERT Operating System: UNIX variants (UNIX, Linux, OSX) Windows Impact: Denial of Service Access: Remote/Unauthenticated CVE Names:CVE-2006-1173 Original Bulletin:http://www.kb.cert.org/vuls/id/146718 http://www.sendmail.org/releases/8.13.7.html - --BEGIN INCLUDED TEXT US-CERT Vulnerability Note VU#146718 Sendmail fails to handle malformed multipart MIME messages Overview Sendmail does not properly handle malformed multipart MIME messages. This vulnerability may allow a remote, unauthenticated attacker to cause a denial-of-service condition. I. Description Sendmail Sendmail is a widely used mail transfer agent (MTA). Mail Transfer Agents (MTA) MTAs are responsible for sending an receiving email messages over the internet. They are also referred to as mail servers or SMTP servers. The Problem Sendmail fails to properly handle malformed mulitpart MIME messages. This vulnerability may be triggered by sending a specially crafted message to a vulnerable Sendmail MTA. II. Impact This vulnerability will not cause the Sendmail server process to terminate. However, it may cause the Sendmail to consume a large amount of system resources. Specifically, if a system writes uniquely named core dump files, this vulnerability may cause available disk space to be filled with core dumps leading to a disruption of system operation resulting in a denial-of-service condition. Additionally, this vulnerability may cause queue runs to abort preventing the processing and delivery of queued messages. III. Solution Upgrade Sendmail This issue is corrected in Sendmail version 8.13.7. The following workarounds were provided by Sendmail: Limit message size Limiting the maximum message size accepted by your server (via the sendmail MaxMessageSize option) will mitigate this vulnerability. Remove stack size limit If your operating system limits stack size, remove that limit. This will make the attack more difficult to accomplish, as it will require a very large message. Also, by limiting the maximum message size accepted by your server (via the sendmail MaxMessageSize option), you can eliminate the attack completely. Configure your MTA to avoid the negative impacts listed above: * Disable core dumps. * Enable the ForkEachJob option at the cost of lower queue run performance and potentially a high number of processes. * Set QueueSortOrder to random, which will randomize the order jobs are processed. Note that with random queue sorting, the bad message will still be processed and the queue run aborted every time, but at a different, random spot. Systems Affected Vendor Status Date Updated 3com, Inc. Unknown 9-May-2006 Alcatel Unknown 9-May-2006 Apple Computer, Inc.Unknown 9-May-2006 ATTUnknown 9-May-2006 Avaya, Inc. Unknown 9-May-2006 Avici Systems, Inc. Unknown 9-May-2006 Borderware Technologies Not Vulnerable 25-May-2006 B.U.G., Inc Not Vulnerable 13-Jun-2006 Century Systems Inc.Not Vulnerable 13-Jun-2006 Charlotte's Web NetworksUnknown 9-May-2006 Check Point Software Technologies Unknown 9-May-2006 Chiaro Networks, Inc. Unknown 9-May-2006 Cisco Systems, Inc. Unknown 9-May-2006 Computer Associates Unknown 9-May-2006 Conectiva Inc. Unknown 9-May-2006 Cray Inc. Unknown 9-May-2006 D-Link Systems, Inc.Unknown 9-May-2006 Data Connection, Ltd. Unknown 9-May-2006 Debian GNU/LinuxUnknown 9-May-2006 DragonFly BSD Project
Re: Problems after sendmail security upgrade
Hello, Richard A Nelson a écrit (Mon, Apr 03, 2006 at 09:53:43AM -0700) : - is it mandatory to use /etc/mail/sendmail.conf? No, not at all - is there a way to manually configure sendmail the classical way set this variable in /etc/mail/sendmail.conf HANDS_OFF=Yes; After setting that, the scripts become non-functional; any and all changes must be done manually Thank you very much for this information. Sorry to all subscribers for the noise on this topic that was finally not security-related. Cheers, -- Emmanuel Halbwachs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems after sendmail security upgrade
Hello, Sorry for the delay, I was abroad and off-line for a week. So I just talked with the sysadmin in charge of the mailhost (he is in cc:). We're going slightly out of topic for debian-security but I keep it there for the record. A file in /etc that was overwritten silently is a bug. Please file one with the bug tracking system if this is the case. But please make sure first you didn't actually answer Yes to dpkg asking whether to overwrite the file, and that you don't have --force-confnew or similar in /etc/dpkg/dpkg.cfg. No interactive questions was asked during the upgrade. Richard A Nelson a écrit (Sun, Mar 26, 2006 at 11:47:29AM -0800) : Can you mail me more details... there is support in /etc/mail/sendmail.conf to automagically support the type of queue aging that you are doing... After a look in the preinst scripts, there is something like : mesiog /var/lib/dpkg/info# grep cron.d/sendmail sendmail*preinst sendmail-base.preinst: if [ -f /etc/cron.d/sendmail ]; then sendmail-base.preinst: echo #preinst /etc/cron.d/sendmail; sendmail-bin.preinst: if [ -f /etc/cron.d/sendmail ]; then sendmail-bin.preinst: echo #preinst /etc/cron.d/sendmail; Indeed, in our configuration, the /etc/cron.d/sendmail has been hand edited in spite of the warning : # This file is automagically generated -- edit at your own risk For some reasons, the admins didn't configure sendmail the Debian way and didn't use the queue aging feature in /etc/mail/sendmail.conf. - is it mandatory to use /etc/mail/sendmail.conf? - is it OK to say A file in /etc that was overwritten silently is a bug as this was the case here? - is there a way to manually configure sendmail the classical way without using the Debian configuration wrappers but cleanly against the package upgrade? (no offense, just for people accustomed to other OS like *BSD) Cheers, -- Emmanuel Halbwachs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems after sendmail security upgrade
On Mon, 3 Apr 2006, Emmanuel Halbwachs wrote: For some reasons, the admins didn't configure sendmail the Debian way and didn't use the queue aging feature in /etc/mail/sendmail.conf. - is it mandatory to use /etc/mail/sendmail.conf? No, not at all - is there a way to manually configure sendmail the classical way without using the Debian configuration wrappers but cleanly against the package upgrade? (no offense, just for people accustomed to other OS like *BSD) set this variable in /etc/mail/sendmail.conf HANDS_OFF=Yes; After setting that, the scripts become non-functional; any and all changes must be done manually -- Rick Nelson Microsoft is a cross between the Borg and the Ferengi. Unfortunately, they use Borg to do their marketing and Ferengi to do their programming. -- Simon Slavin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems after sendmail security upgrade
On Fri, 24 Mar 2006, Emmanuel Halbwachs wrote: Emmanuel Halbwachs a ?crit (Fri, Mar 24, 2006 at 06:57:43PM +0100) : - after the upgrade : in some cases (more on this below), incoming mail goes to /var/spool/mqueue/daily and is stuck there OK, the problem was on our side: /etc/cron.d/sendmail has been tailored to our needs and has been reverted to a standard Debian one by the upgrade. Very sorry for the noise and thanks for your collaboration. Can you mail me more details... there is support in /etc/mail/sendmail.conf to automagically support the type of queue aging that you are doing... -- Rick Nelson * BenC wonders why he has upgraded to 3.3.5-1 before teh X maintainer
Problems after sendmail security upgrade
Hello, We are experiencing problems after the sendmail security upgrade on our mailhost. - do some other people out there are experiencing some troubles after this upgrade ? - is there a way to downgrade the sendmail packages to the previous version before the security fix ? (i. e. something with apt-pinning) Thanks in advance, -- Emmanuel Halbwachs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems after sendmail security upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emmanuel Halbwachs wrote: We are experiencing problems after the sendmail security upgrade on our mailhost. What sort of problems, exactly? - is there a way to downgrade the sendmail packages to the previous version before the security fix ? (i. e. something with apt-pinning) If you can find a .deb of the package version you want, something like: dpkg --force-downgrade --install sendmail-whatever.deb should do the trick. Be aware that forcing a downgrade doesn't check for dependencies on the newer, replaced version of the package. - -- Chris Hilts [EMAIL PROTECTED] Say it with flowers -- Send them a triffid! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) iD8DBQFEJC6g98ixrK2vMtARAoQzAKCJppzEOmLupmqX5UPhlU+b93EXAwCgk25D dZWT1UyV8F/OVYomGj51m7M= =JayI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems after sendmail security upgrade
On Fri, Mar 24, 2006 at 12:38:40PM -0500, Chris Hilts wrote: If you can find a .deb of the package version you want, something like: dpkg --force-downgrade --install sendmail-whatever.deb should do the trick. Be aware that forcing a downgrade doesn't check for dependencies on the newer, replaced version of the package. Which is why you shouldn't use the force flag in that case. Just installing the old version is sufficient. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems after sendmail security upgrade
Hans a écrit (Fri, Mar 24, 2006 at 12:38:01PM -0500) : Can you be more specific about the problems you are having? I am not the guy who administer the mailhost, but I just talk to my fellow postmaster. I'll try: - the sendmail config uses 6 queues: in, out, in.hourly, out.hourly, in.daily, out.daily - after the upgrade : in some cases (more on this below), incoming mail goes to /var/spool/mqueue/daily and is stuck there - this happens for : - mail inside - inside (95 % of the time) - mail from outside (sometimes) - the config has not changed, and is still the same after the upgrade - only the binary has changed (of course) We will try the dpkg -i to go the previous version. Thanks to all. -- Emmanuel Halbwachs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems after sendmail security upgrade
Hello again, Emmanuel Halbwachs a écrit (Fri, Mar 24, 2006 at 06:57:43PM +0100) : - after the upgrade : in some cases (more on this below), incoming mail goes to /var/spool/mqueue/daily and is stuck there OK, the problem was on our side: /etc/cron.d/sendmail has been tailored to our needs and has been reverted to a standard Debian one by the upgrade. Very sorry for the noise and thanks for your collaboration. -- Emmanuel Halbwachs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems after sendmail security upgrade
This one time, at band camp, Emmanuel Halbwachs said: Hello again, Emmanuel Halbwachs a écrit (Fri, Mar 24, 2006 at 06:57:43PM +0100) : - after the upgrade : in some cases (more on this below), incoming mail goes to /var/spool/mqueue/daily and is stuck there OK, the problem was on our side: /etc/cron.d/sendmail has been tailored to our needs and has been reverted to a standard Debian one by the upgrade. Very sorry for the noise and thanks for your collaboration. A file in /etc that was overwritten silently is a bug. Please file one with the bug tracking system if this is the case. Thanks, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Problems after sendmail security upgrade
All seems ok here. Can you be more specific about the problems you are having? Hans. Le vendredi 24 mars 2006 à 18:31 +0100, Emmanuel Halbwachs a écrit : Hello, We are experiencing problems after the sendmail security upgrade on our mailhost. - do some other people out there are experiencing some troubles after this upgrade ? - is there a way to downgrade the sendmail packages to the previous version before the security fix ? (i. e. something with apt-pinning) Thanks in advance, -- Emmanuel Halbwachs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems after sendmail security upgrade
* Stephen Gran [Fri, 24 Mar 2006 18:45:52 +]: This one time, at band camp, Emmanuel Halbwachs said: /etc/cron.d/sendmail has been tailored to our needs and has been reverted to a standard Debian one by the upgrade. Very sorry for the noise and thanks for your collaboration. A file in /etc that was overwritten silently is a bug. Please file one with the bug tracking system if this is the case. But please make sure first you didn't actually answer Yes to dpkg asking whether to overwrite the file, and that you don't have --force-confnew or similar in /etc/dpkg/dpkg.cfg. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Acaba de... Acaba de una vez... Acaba de una vez conmigo -- Astrud, Masaje -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sendmail vulnerability
Hello, ISS has reported a serious flaw in sendmail before 8.13.6, see http://xforce.iss.net/xforce/alerts/id/216 and http://sendmail.org/8.13.6.html Is a security fix of the sendmail-package(s) in view, or should I try to install sendmail 8.13.6 standalone? Thanks, Andreas -- Dr. Andreas Piper, Hochschulrechenzentrum der Philipps-Univ. Marburg Hans-Meerwein-Strasse, 35032 Marburg, Germany Phone: +49 6421 28-23521 Fax: -26994 Email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sendmail vulnerability
On Thu, Mar 23, 2006 at 09:44:38AM +0100, Andreas Piper wrote: Hello, ISS has reported a serious flaw in sendmail before 8.13.6, see http://xforce.iss.net/xforce/alerts/id/216 and http://sendmail.org/8.13.6.html Is a security fix of the sendmail-package(s) in view, or should I try to install sendmail 8.13.6 standalone? sendmail 8.13.6-1 is in NEW. See http://ftp-master.debian.org/new.html Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: sendmail vulnerability
* Andreas Piper ([EMAIL PROTECTED]) [060323 09:45]: Hello, ISS has reported a serious flaw in sendmail before 8.13.6, see http://xforce.iss.net/xforce/alerts/id/216 and http://sendmail.org/8.13.6.html Is a security fix of the sendmail-package(s) in view, or should I try to install sendmail 8.13.6 standalone? A package is being prepared and should be available soon. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sendmail vulnerability
Andreas Piper wrote: ISS has reported a serious flaw in sendmail before 8.13.6, see http://xforce.iss.net/xforce/alerts/id/216 and http://sendmail.org/8.13.6.html Is a security fix of the sendmail-package(s) in view, or should I try to install sendmail 8.13.6 standalone? Packages for Sarge and Woody are currently building and will appear soon. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
preserving sendmail configuration security hacks
One of my mail servers runs sendmail and some extra security features are implemented in the Local_check_relay ruleset---in particualr it only allows a small list of IP addresses to connect. There are also a few other Local_check_* rulesets which are non-standard and do things like tweaking the relay restrictions and providing additional resistance to thrid party relaying. I can put the rulesets Local_check_* rulesets in the LOCAL_RULESETS in sendmail.mc and delete the blank ones make sendmail.cf generates manually but this is suboptimal. Is there a way of writing the sendmail.mc file so the extra rules in the Local_check_* rulesets appear. I read the m4 source and saw items for handling LOCAL_RULE_0 and LOCAL_RULE_3 (both of which I use for some special effects) but nothign similar appears where the blank Local_check_* rulsets are defined. I have my doubts about the ability of postfix and exim to handle everythign required. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preserving sendmail configuration security hacks
On Wed, 10 Nov 2004, Duncan Simpson wrote: I can put the rulesets Local_check_* rulesets in the LOCAL_RULESETS in sendmail.mc and delete the blank ones make sendmail.cf generates manually but this is suboptimal. Is there a way of writing the sendmail.mc file so the extra rules in the Local_check_* rulesets appear. I do stuff like this all the time (in sendmail.mc, or include): LOCAL_RULESETS # Allow etrn,expn,vrfy from anyplace allowed to relay through us SLocal_check_commands ... # No pause for port 587(MSP) as authentication is required SLocal_greet_pause ... The last case does cause two occurances of Slocal_greet_pause... but unlike the Bat book V2 (still gotta get V3), sendmail doesn't complain - and does the right thing. I'd be happy to look over you setup if you'd like... If you've got anything that might be generally applicable, I'd love to merge it into what I'm putting together... a set of hacks to increase security and simplify things as much as possible. -- Rick Nelson What you end up with, after running an operating system concept through these many marketing coffee filters, is something not unlike plain hot water. (By Matt Welsh) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
upgrading sendmail package when postfix installed
Hi! I have installed postfix from sources a while ago, and now there is a security update fro sendmail. As you probably know, I can not remove the sendmail package (although I'm not using it), because it would remove apache and many other packages wich are depending on a MTA. So can I fake the sendmail installation, so apt-get would see that sendmail has been upgraded, or do I have upgrade sendmail (for security reasons) and then re-install postfix all over again? Thanks! Daniel -- LeVA pgpGRZ6W2bkkj.pgp Description: PGP signature
Re: upgrading sendmail package when postfix installed
On Mon, 2004-10-11 at 12:46, LeVA wrote: I have installed postfix from sources a while ago, and now there is a security update fro sendmail. As you probably know, I can not remove the sendmail package (although I'm not using it), because it would remove apache and many other packages wich are depending on a MTA. So can I fake the sendmail installation, so apt-get would see that sendmail has been upgraded, or do I have upgrade sendmail (for security reasons) and then re-install postfix all over again? Use equivs to create a fake package that provides mail-transport-agent, to keep the package management system happy. Then you won't need the sendmail package. [EMAIL PROTECTED]:~$apt-cache show equivs Package: equivs Priority: extra Section: admin Installed-Size: 132 Maintainer: Fabio Rafael da Rosa [EMAIL PROTECTED] Architecture: all Version: 2.0.6-0.1 Depends: perl | perl5, debhelper, dpkg-dev, devscripts, make, fakeroot Filename: pool/main/e/equivs/equivs_2.0.6-0.1_all.deb Size: 18066 MD5sum: 0791bcf0d3e543bfeb147c1afdf42ac6 Description: Circumvent Debian package dependencies This package provides a tool to create Debian packages that only contain dependency information. . If a package P is not installed on the system, packages that depend on P cannot normally be installed. However, if equivalent functionality to P is known to be installed, this tool can be used to trick the Debian package management system into believing that package P is actually installed. . Another possibility is creation of a meta package. When this package contains a dependency as Depends: a, b, c, then installing this package will also select packages a, b and c. Instead of Depends, you can also use Recommends: or Suggests: for less demanding dependency. . Please note that this is a crude hack and if thoughtlessly used, it might possibly do damage to your packaging system. And please note as well that using it is not the recommended way of dealing with broken dependencies. Better file a bug report instead. -- Tot ziens, Bart-Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: upgrading sendmail package when postfix installed
On Mon, Oct 11, 2004 at 12:46:01PM +0200, LeVA wrote: I have installed postfix from sources a while ago, and now there is a security update fro sendmail. As you probably know, I can not remove the sendmail package (although I'm not using it), because it would remove apache and many other packages wich are depending on a MTA. So can I fake the sendmail installation, so apt-get would see that sendmail has been upgraded, or do I have upgrade sendmail (for security reasons) and then re-install postfix all over again? Put the sendmail package on hold, so that it is no longer upgraded or touched by apt at all. Just be sure that you never cause it to be run. The reference manual has an example of how to do this, or google will help: http://www.debian.org/doc/manuals/reference/ch-package.en.html I had to do this on one system to stop exim from being updated, even though it's running qmail. Steve -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: upgrading sendmail package when postfix installed
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: because it would=20 remove apache and many other packages wich are depending on a MTA. So=20 can I fake the sendmail installation, so apt-get would see that=20 sendmail has been upgraded, or do I have upgrade sendmail (for security=20 reasons) and then re-install postfix all over again? Use equivs to create a package that supplies mail-transport-agent. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[SECURITY] [DSA 554-1] New sendmail packages fix potential open relay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 554-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze September 27th, 2004http://www.debian.org/security/faq - -- Package: sendmail Vulnerability : pre-set password Problem-Type : remote Debian-specific: yes CVE ID : CAN-2004-0833 Hugo Espuny discovered a problem in sendmail, a commonly used program to deliver electronic mail. When installing sasl-bin to use sasl in connection with sendmail, the sendmail configuration script use fixed user/pass information to initialise the sasl database. Any spammer with Debian systems knowledge could utilise such a sendmail installation to relay spam. For the stable distribution (woody) this problem has been fixed in version 8.12.3-7.1. For the unstable distribution (sid) this problem has been fixed in version 8.13.1-13. We recommend that you upgrade your sendmail package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.1.dsc Size/MD5 checksum: 751 f87d51444a4f2e04a59fafeb7f097bbc http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.1.diff.gz Size/MD5 checksum: 258790 c2f8dcc37edf99eada5fb65b26bb9e72 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3.orig.tar.gz Size/MD5 checksum: 1840401 b198b346b10b3b5afc8cb4e12c07ff4d Architecture independent components: http://security.debian.org/pool/updates/main/s/sendmail/sendmail-doc_8.12.3-7.1_all.deb Size/MD5 checksum: 747880 2ae5775f103472f8f7941e0662786930 Alpha architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.1_alpha.deb Size/MD5 checksum: 267968 69dab41dfc47d348ec7ee5603971c68b http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.1_alpha.deb Size/MD5 checksum: 1109604 9f64220f46ac154f7426450478f101dc ARM architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.1_arm.deb Size/MD5 checksum: 247700 6bb4396b026113ec4e12026377a18d17 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.1_arm.deb Size/MD5 checksum: 979550 718d6fb7066f753dcba7c71aa7d76ed0 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.1_i386.deb Size/MD5 checksum: 237456 111a0ee4b50eafdfdf89845dc633aa1b http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.1_i386.deb Size/MD5 checksum: 918104 ad5cc37cb435ed63022ab3a16ae01f6e Intel IA-64 architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.1_ia64.deb Size/MD5 checksum: 282146 360db5037b71cb5eab9015ae8292aca3 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.1_ia64.deb Size/MD5 checksum: 1332930 f25bedb4ac5beb5372a704a99dc4d2ac HP Precision architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.1_hppa.deb Size/MD5 checksum: 261806 5aebadbfa1f4c5b63a97034a5bdd3b5a http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.1_hppa.deb Size/MD5 checksum: 1081296 1fc96f0e94f384c4f8007358243a4e5e Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.1_m68k.deb Size/MD5 checksum: 231282 8d498605748163c67d9ff0f467e01966 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.1_m68k.deb Size/MD5 checksum: 866108 b41e130ed77f5224f80178375f25664c Big endian MIPS architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.1_mips.deb Size/MD5 checksum: 255334 699b5f21580f659cd22311150bf0ba5c http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.1_mips.deb Size/MD5 checksum: 1022342 2b627d3fdc4c7c9841c6d150b33c1c2a Little endian MIPS architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.1_mipsel.deb Size/MD5 checksum: 255012
sendmail: 550 Error: Message content rejected
Hello Russel, How do you send the previous Message ? If a resond to it, I get in 'mutt' the error Message: sendmail: 550 Error: Message content rejected Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: sendmail: 550 Error: Message content rejected
Michelle Konzack [EMAIL PROTECTED] wrote: How do you send the previous Message ? If a resond to it, I get in 'mutt' the error Message: sendmail: 550 Error: Message content rejected The message from Russel had Content-Type: text/plain; charset=iso-8859-1 and Content-Transfer-Encoding: 7bit but iso-8859-1 doesn't fit in 7-bit ;-) Beside that I see no unusal things in Russel's mail. To me it looks like a bug in kmail, an mua should 'nt send with the wrong encoding. Or did murphy change it to 7-bit because there wasn't any 8-bit content? However, that's all OT here. hth and bye, Manne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sendmail problem:connection timed out
hello, I am using sendmail 8.12 in redhat linux9.0 to send mail.It sends the message between the internal network. But it doesnot send the message to the external network. I want to send mail to [EMAIL PROTECTED] But it is not sending mail.The following logs are generated in maillog . From the message i understand that it is accepting the mail.But it is not able to relay to the user_account @hotmail.com Please reply as soon as possible. very urgent. logs ** Jan 5 12:04:56 arun sendmail[5213]: i056YuFS005213: from=root, size=133, class=0, nrcpts=1, msgid=[EMAIL PROTECTED], [EMAIL PROTECTED] Jan 5 12:04:56 arun sendmail[5215]: i056Yuor005215: from=[EMAIL PROTECTED], size=333, class=0, nrcpts=1, msgid=[EMAIL PROTECTED], proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1] (may be forged) Jan 5 12:04:56 arun sendmail[5213]: i056YuFS005213: [EMAIL PROTECTED], ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30086, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (i056Yuor005215 Message accepted for delivery) Jan 5 12:07:56 arun sendmail[5217]: i056Yuor005215: to=[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (0/0), delay=00:03:00, xdelay=00:03:00, mailer=esmtp, pri=30286, relay=hotmail.com [64.4.33.7], dsn=4.0.0, stat=Deferred: Connection timed out with hotmail.com thanks, arun my email_id: [EMAIL PROTECTED] Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.com
Re: sendmail problem:connection timed out
Are you able to ping 64.4.33.7 !? If so, try 'telnet 64.4.33.7 25' next to get a smtp prompt. If nothing works look at your connection: Firewall rules etc. Beside that your sendmail seems to work. Christian - Original Message - From: arun raj [EMAIL PROTECTED] To: debian-security@lists.debian.org Sent: Monday, January 05, 2004 11:48 AM Subject: sendmail problem:connection timed out hello, I am using sendmail 8.12 in redhat linux9.0 to send mail.It sends the message between the internal network. But it doesnot send the message to the external network. I want to send mail to [EMAIL PROTECTED] But it is not sending mail.The following logs are generated in maillog . From the message i understand that it is accepting the mail.But it is not able to relay to the user_account @hotmail.com Please reply as soon as possible. very urgent. logs ** Jan 5 12:04:56 arun sendmail[5213]: i056YuFS005213: from=root, size=133, class=0, nrcpts=1, msgid=[EMAIL PROTECTED], [EMAIL PROTECTED] Jan 5 12:04:56 arun sendmail[5215]: i056Yuor005215: from=[EMAIL PROTECTED], size=333, class=0, nrcpts=1, msgid=[EMAIL PROTECTED], proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1] (may be forged) Jan 5 12:04:56 arun sendmail[5213]: i056YuFS005213: [EMAIL PROTECTED], ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30086, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (i056Yuor005215 Message accepted for delivery) Jan 5 12:07:56 arun sendmail[5217]: i056Yuor005215: to=[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (0/0), delay=00:03:00, xdelay=00:03:00, mailer=esmtp, pri=30286, relay=hotmail.com [64.4.33.7], dsn=4.0.0, stat=Deferred: Connection timed out with hotmail.com thanks, arun my email_id: [EMAIL PROTECTED] Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: easiest way to configure STARTTLS and PAM/AUTH on debian sendmail?
Richard A Nelson wrote: On Mon, 29 Sep 2003, Jeff Wiegley wrote: I'm very tired of struggling with sendmail to get it to support STARTTLS and SMTPAUTH under debian. More on this in a minute... STARTTLS is a pretty easy single include line in the .mc files. Yes, and more secure to boot - especially if you only allow plaintext methods *after* STARTTLS negotiations Yep, I definately like TLS. I'm migrating all my settings to it as soon as I can figure out evolution and sendmail won't cooperate and start a decent TLS connection. I've figure out that you only need the two lines: include(`/etc/mail/tls/starttls.m4')dnl include(`/etc/mail/sasl/sasl.m4')dnl in the .mc files on the latest debian to get both STARTLS and SMTP AUTH going but two items remain: 1) Is there anything I have to configure or check to get the behavior you described as [only] allow plaintext methods *after* STARTTLS negotiations? Or is it this way by default? 2) Maybe there is a sort of dependency bug in the debian sendmail package: When I installed sendmail it brought in libsasl but nothing caused either sasl2-bin or libsasl2-modules to be installed. It was stupid of me that I couldn't figure out why AUTH wasn't being presented for the longest time but I finally figured out that if you don't have any mechanisms available then AUTH is disabled. It seems weird that sendmail really needs sasl and sasl really needs some modules but these modules (and daemon) were not installed along with my request for sendmail. Just a small item but maybe the sendmail dependencies could include sasl2-bin and libsasl2-modules? No big deal about this. It was just confusing. but AUTH is a real pain. Indeed :( What is the easiest method (preferrably one that doesn't require sasl) to get AUTH setup so that: 1) non-STARTTLS connections do NOT offer PLAIN or LOGIN, and 2) STARTTLS connections do honor PLAIN or LOGIN? No dice, man... SMTP AUTH *is* based upon SASL v1 or v2... There is a GNU TLS, and iirc, even a GNU SASL replacement - but dont expect a quick change from upstream or me; I know I've not investigated it at all, and I'd expect that upstream hasn't even heard of it - bigger fish to fry ATM. Thanks. I knew about SASL but I didn't realize that SMTP AUTH was dependent on it. I thought SMTP AUTH was around before SASL and therefore maybe there was some way to reconfigure it to not use sasl. [snipped the sasl dead horse content] I'm sorry about that. I searched for relevant sendmail lists, or some Debian WiKi type things and couldn't find anything very pertinent; especially any focused on the debian sendmail package. I stumbled across this list just an hour or so after mailing you. I thought it wouldn't deal with sendmail; just about firewalls and IPsec, classic security items. But, of course, I was wrong. Here's a double sorry: Sorry, but you'll probably find a couple of bugs entered about sendmail via the reportbug tool. I was having these problems with a couple of clients and I was desperate for help. I'm happy to help, but the other problem you mention is thusfar unique to you, and I only follow these groups on an as time/sanity permits basis and dislike having to tie notes from disjoint locations together to get a cohesive picture of a problem... so pick a spot, any (singular) spot and let me know where that is. I choose the debian.security list. (Except for things that I find that I really think are bugs; those I'll submit via reportbug.) For now I'll try to do some investigation as to why my STARTTLS connections are crashing due to that Decryption failure. But it seems to be an issue between sendmail and evolution. Mozilla doesn't seem to have a problem with outgoing STARTTLS connections. But evolution sure does. Maybe somebody else can help... When evolution trys to connect to starttls I get the following in /var/log/mail.log: Sep 30 10:33:21 mail sm-mta[25586]: STARTTLS=server, error: accept failed=-1, SSL_error=1, timedout=0, errno=0 Sep 30 10:33:21 mail sm-mta[25586]: STARTTLS=server: 25586:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:424: Mozilla doesn't cause this error. and no other evolution user seems to be complaining about this. But I can duplicate the error on all the Debian sid boxes I have by just upgrading and then removing and reinstalling sendmail. I've submitted a bug report to Ximian. Can anybody help me by informing me of some way that I can obtain more information about that first mail.log line? Why would the accept fail? How can I find out what SSL_error=1 means? Thanks, (Especially to Richard for dealing with the multiple avenues) - Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FIXED: easiest way to configure STARTTLS and PAM/AUTH on debian sendmail?
Look like I got this fixed. I had to reboot my machine that seemed to do the trick. My guess is that evolution cached some cert along the way and only cleared it out when I rebooted. hmmm. Unix does occasionally need to be rebooted. Go figure. Thank for the help, - Jeff Maybe somebody else can help... When evolution trys to connect to starttls I get the following in /var/log/mail.log: Sep 30 10:33:21 mail sm-mta[25586]: STARTTLS=server, error: accept failed=-1, SSL_error=1, timedout=0, errno=0 Sep 30 10:33:21 mail sm-mta[25586]: STARTTLS=server: 25586:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:424: Mozilla doesn't cause this error. and no other evolution user seems to be complaining about this. But I can duplicate the error on all the Debian sid boxes I have by just upgrading and then removing and reinstalling sendmail. I've submitted a bug report to Ximian. Can anybody help me by informing me of some way that I can obtain more information about that first mail.log line? Why would the accept fail? How can I find out what SSL_error=1 means? Thanks, (Especially to Richard for dealing with the multiple avenues) - Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: easiest way to configure STARTTLS and PAM/AUTH on debian sendmail?
Richard A Nelson wrote: On Mon, 29 Sep 2003, Jeff Wiegley wrote: I'm very tired of struggling with sendmail to get it to support STARTTLS and SMTPAUTH under debian. More on this in a minute... STARTTLS is a pretty easy single include line in the .mc files. Yes, and more secure to boot - especially if you only allow plaintext methods *after* STARTTLS negotiations Yep, I definately like TLS. I'm migrating all my settings to it as soon as I can figure out evolution and sendmail won't cooperate and start a decent TLS connection. I've figure out that you only need the two lines: include(`/etc/mail/tls/starttls.m4')dnl include(`/etc/mail/sasl/sasl.m4')dnl in the .mc files on the latest debian to get both STARTLS and SMTP AUTH going but two items remain: 1) Is there anything I have to configure or check to get the behavior you described as [only] allow plaintext methods *after* STARTTLS negotiations? Or is it this way by default? 2) Maybe there is a sort of dependency bug in the debian sendmail package: When I installed sendmail it brought in libsasl but nothing caused either sasl2-bin or libsasl2-modules to be installed. It was stupid of me that I couldn't figure out why AUTH wasn't being presented for the longest time but I finally figured out that if you don't have any mechanisms available then AUTH is disabled. It seems weird that sendmail really needs sasl and sasl really needs some modules but these modules (and daemon) were not installed along with my request for sendmail. Just a small item but maybe the sendmail dependencies could include sasl2-bin and libsasl2-modules? No big deal about this. It was just confusing. but AUTH is a real pain. Indeed :( What is the easiest method (preferrably one that doesn't require sasl) to get AUTH setup so that: 1) non-STARTTLS connections do NOT offer PLAIN or LOGIN, and 2) STARTTLS connections do honor PLAIN or LOGIN? No dice, man... SMTP AUTH *is* based upon SASL v1 or v2... There is a GNU TLS, and iirc, even a GNU SASL replacement - but dont expect a quick change from upstream or me; I know I've not investigated it at all, and I'd expect that upstream hasn't even heard of it - bigger fish to fry ATM. Thanks. I knew about SASL but I didn't realize that SMTP AUTH was dependent on it. I thought SMTP AUTH was around before SASL and therefore maybe there was some way to reconfigure it to not use sasl. [snipped the sasl dead horse content] I'm sorry about that. I searched for relevant sendmail lists, or some Debian WiKi type things and couldn't find anything very pertinent; especially any focused on the debian sendmail package. I stumbled across this list just an hour or so after mailing you. I thought it wouldn't deal with sendmail; just about firewalls and IPsec, classic security items. But, of course, I was wrong. Here's a double sorry: Sorry, but you'll probably find a couple of bugs entered about sendmail via the reportbug tool. I was having these problems with a couple of clients and I was desperate for help. I'm happy to help, but the other problem you mention is thusfar unique to you, and I only follow these groups on an as time/sanity permits basis and dislike having to tie notes from disjoint locations together to get a cohesive picture of a problem... so pick a spot, any (singular) spot and let me know where that is. I choose the debian.security list. (Except for things that I find that I really think are bugs; those I'll submit via reportbug.) For now I'll try to do some investigation as to why my STARTTLS connections are crashing due to that Decryption failure. But it seems to be an issue between sendmail and evolution. Mozilla doesn't seem to have a problem with outgoing STARTTLS connections. But evolution sure does. Maybe somebody else can help... When evolution trys to connect to starttls I get the following in /var/log/mail.log: Sep 30 10:33:21 mail sm-mta[25586]: STARTTLS=server, error: accept failed=-1, SSL_error=1, timedout=0, errno=0 Sep 30 10:33:21 mail sm-mta[25586]: STARTTLS=server: 25586:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:424: Mozilla doesn't cause this error. and no other evolution user seems to be complaining about this. But I can duplicate the error on all the Debian sid boxes I have by just upgrading and then removing and reinstalling sendmail. I've submitted a bug report to Ximian. Can anybody help me by informing me of some way that I can obtain more information about that first mail.log line? Why would the accept fail? How can I find out what SSL_error=1 means? Thanks, (Especially to Richard for dealing with the multiple avenues) - Jeff
Re: FIXED: easiest way to configure STARTTLS and PAM/AUTH on debian sendmail?
Look like I got this fixed. I had to reboot my machine that seemed to do the trick. My guess is that evolution cached some cert along the way and only cleared it out when I rebooted. hmmm. Unix does occasionally need to be rebooted. Go figure. Thank for the help, - Jeff Maybe somebody else can help... When evolution trys to connect to starttls I get the following in /var/log/mail.log: Sep 30 10:33:21 mail sm-mta[25586]: STARTTLS=server, error: accept failed=-1, SSL_error=1, timedout=0, errno=0 Sep 30 10:33:21 mail sm-mta[25586]: STARTTLS=server: 25586:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:424: Mozilla doesn't cause this error. and no other evolution user seems to be complaining about this. But I can duplicate the error on all the Debian sid boxes I have by just upgrading and then removing and reinstalling sendmail. I've submitted a bug report to Ximian. Can anybody help me by informing me of some way that I can obtain more information about that first mail.log line? Why would the accept fail? How can I find out what SSL_error=1 means? Thanks, (Especially to Richard for dealing with the multiple avenues) - Jeff
newest sendmail packages break STARTTLS...
I've been trying to set up a new debian based email server for a client and its a horrible nightmare to get both STARTTLS and AUTH working. Let's just tackle STARTTLS for this message. When ever I try anything in evolution that attempts a STARTTLS I get this evolution error dialog: Error while performing operation: Failed to connect to SMTP server mail.cyte.com in secure mode: Input/output error if I look in /var/log/mail.log I see this... Sep 28 22:40:42 mail sm-mta[17847]: STARTTLS=server, error: accept failed=-1, SSL_error=1, timedout=0, errno=0 Sep 28 22:40:42 mail sm-mta[17847]: STARTTLS=server: 7847:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:424: Sep 28 22:40:42 mail sm-mta[17847]: h8T5egvu017847: mail [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA So it looks like something is seriously broken with some sort of decryption routine. My other, older debian box didn't have this problem until I did this: apt-get remove --purge sendmail sasl2-bin rm -rf /etc/mail apt-get install sasl2-bin edited sasl config and start saslauthd apt-get install sendmail configure sendmail and add the two include lines for tls and sasl remake the .cf files and then restart and sendmail and... viola! now this machine also can't handle STARTTLS with exactly the same errors being reported. So I think something is seriously wrong with STARTTLS in the latest sendmail package. Does anybody know how to fix this? - Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
easiest way to configure STARTTLS and PAM/AUTH on debian sendmail?
I'm very tired of struggling with sendmail to get it to support STARTTLS and SMTPAUTH under debian. STARTTLS is a pretty easy single include line in the .mc files. but AUTH is a real pain. What is the easiest method (preferrably one that doesn't require sasl) to get AUTH setup so that: 1) non-STARTTLS connections do NOT offer PLAIN or LOGIN, and 2) STARTTLS connections do honor PLAIN or LOGIN? I'm 100% against sasl in general just for the simple fact that the developers have chosen to store passwords and user credentials in PLAINTEXT in a file on the filesystem. (add to that the need to maintain and synchronize two different databases or username/password information.) Thanks, - Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: easiest way to configure STARTTLS and PAM/AUTH on debian sendmail?
Jeff Wiegley [EMAIL PROTECTED] writes: I'm 100% against sasl in general just for the simple fact that the developers have chosen to store passwords and user credentials in PLAINTEXT in a file on the filesystem. (add to that the need to maintain and synchronize two different databases or username/password information.) FWIW, plaintext passwords is a requirement of some of the SASL mechanisms, such as CRAM-MD5. If you don't need CRAM-MD5 or similar mechanisms, you don't need plaintext passwords on the machine. Also, many, if not most, SASL mechanisms is not compatible with standard Unix username/password management since they derive secrets from the passphrase, which is impossible to access under Unix. (Alternatively, you could blame the Unix username/password system for the problems..) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: easiest way to configure STARTTLS and PAM/AUTH on debian sendmail?
Jeff Wiegley said on Mon, Sep 29, 2003 at 06:08:35AM +: What is the easiest method (preferrably one that doesn't require sasl) to get AUTH setup so that: 1) non-STARTTLS connections do NOT offer PLAIN or LOGIN, and 2) STARTTLS connections do honor PLAIN or LOGIN? I'm 100% against sasl in general just for the simple fact that the developers have chosen to store passwords and user credentials in PLAINTEXT in a file on the filesystem. (add to that the need to maintain and synchronize two different databases or username/password information.) Uh, SMTP AUTH is based on SASL (SASL is a protocol and a library). So, you need sasl to do what you want. http://www.technoids.org/wwstarttls.html appears to have the info you want, specifically: dnl # Offer SMTP AUTH only after encryption (STARTTLS) has been negotiated define(`confAUTH_OPTIONS',`p,y')dnl M pgp0.pgp Description: PGP signature
newest sendmail packages break STARTTLS...
I've been trying to set up a new debian based email server for a client and its a horrible nightmare to get both STARTTLS and AUTH working. Let's just tackle STARTTLS for this message. When ever I try anything in evolution that attempts a STARTTLS I get this evolution error dialog: Error while performing operation: Failed to connect to SMTP server mail.cyte.com in secure mode: Input/output error if I look in /var/log/mail.log I see this... Sep 28 22:40:42 mail sm-mta[17847]: STARTTLS=server, error: accept failed=-1, SSL_error=1, timedout=0, errno=0 Sep 28 22:40:42 mail sm-mta[17847]: STARTTLS=server: 7847:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:424: Sep 28 22:40:42 mail sm-mta[17847]: h8T5egvu017847: mail [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA So it looks like something is seriously broken with some sort of decryption routine. My other, older debian box didn't have this problem until I did this: apt-get remove --purge sendmail sasl2-bin rm -rf /etc/mail apt-get install sasl2-bin edited sasl config and start saslauthd apt-get install sendmail configure sendmail and add the two include lines for tls and sasl remake the .cf files and then restart and sendmail and... viola! now this machine also can't handle STARTTLS with exactly the same errors being reported. So I think something is seriously wrong with STARTTLS in the latest sendmail package. Does anybody know how to fix this? - Jeff
easiest way to configure STARTTLS and PAM/AUTH on debian sendmail?
I'm very tired of struggling with sendmail to get it to support STARTTLS and SMTPAUTH under debian. STARTTLS is a pretty easy single include line in the .mc files. but AUTH is a real pain. What is the easiest method (preferrably one that doesn't require sasl) to get AUTH setup so that: 1) non-STARTTLS connections do NOT offer PLAIN or LOGIN, and 2) STARTTLS connections do honor PLAIN or LOGIN? I'm 100% against sasl in general just for the simple fact that the developers have chosen to store passwords and user credentials in PLAINTEXT in a file on the filesystem. (add to that the need to maintain and synchronize two different databases or username/password information.) Thanks, - Jeff
Re: easiest way to configure STARTTLS and PAM/AUTH on debian sendmail?
Jeff Wiegley [EMAIL PROTECTED] writes: I'm 100% against sasl in general just for the simple fact that the developers have chosen to store passwords and user credentials in PLAINTEXT in a file on the filesystem. (add to that the need to maintain and synchronize two different databases or username/password information.) FWIW, plaintext passwords is a requirement of some of the SASL mechanisms, such as CRAM-MD5. If you don't need CRAM-MD5 or similar mechanisms, you don't need plaintext passwords on the machine. Also, many, if not most, SASL mechanisms is not compatible with standard Unix username/password management since they derive secrets from the passphrase, which is impossible to access under Unix. (Alternatively, you could blame the Unix username/password system for the problems..)
Re: Sendmail package version weirdness
On Fri, Sep 19, 2003 at 01:47:28AM -0400, Robert Brockway wrote: On Fri, 19 Sep 2003, Matt Zimmerman wrote: On Thu, Sep 18, 2003 at 10:58:49PM -0400, Robert Brockway wrote: Was there any particular reason that this newer fixed version has a version number the makes it look older than the exploitable version? Simple: it doesn't. The version in stable is 8.12.3-4, and the version on security.debian.org is 8.12.3-6.6. Your package came from someplace else. Hi Matt. Thanks for clearing that up. FYI I located the origin of the version I was using: http://people.debian.org/~cowboy/sendmail_8.12.3-7woody_i386.changes Just like anyone using debian.seabone.net for the debian-ipv6 repository for woody would have 8.12.9-3 installed... Regards, Jeremy Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) The earth is but one country and mankind its citizens -Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] signature.asc Description: Digital signature
STARTTLS wierdness in sendmail 8.12.10-1
I cannot get STARTTLS to work with the newest snendmail in unstable. It *always* complains that the key file is group readable! Now, before you scream RTFM, I did use GroupReadableKeyFile! I updated to sendmail 8.12.10-1 to patch CAN-2003-0681 CAN-2003-0694 When I startup I get... sm-mta[30148]: starting daemon (8.12.10): SMTP sm-mta[30148]: STARTTLS=server: file /etc/mail/tls/sendmail-common.key unsafe: Group readable file Fine, so GroupReadableKeyFile was not set by default as was before, so I stuck this in starttls.m4 define(`confDONT_BLAME_SENDMAIL', `GroupReadableKeyFile') Which does work and puts this in submit.cf O DontBlameSendmail=GroupReadableKeyFile But, I *still* get: sm-mta[6346]: starting daemon (8.12.10): SMTP sm-mta[6346]: STARTTLS=server: file /etc/mail/tls/sendmail-common.key unsafe: Group readable file Back on previous versions from testing and stable I do not get these messages. sm-mta[31901]: starting daemon (8.12.9): SMTP sm-mta[3719]: starting daemon (8.12.3): SMTP Anyone else see this? later, -Brian signature.asc Description: This is a digitally signed message part
Re: STARTTLS wierdness in sendmail 8.12.10-1
On Friday 19 September 2003 17:59, Brian Rectanus wrote: Hi Brian, I cannot get STARTTLS to work with the newest snendmail in unstable. It *always* complains that the key file is group readable! Now, before you scream RTFM, I did use GroupReadableKeyFile! please copy /usr/share/sendmail/examples/starttls.m4 to /etc/mail/tls and execute 'sendmailconfig' after you copied the file over. It's an updated file you have to use by now. You should have read the install message by the sendmail update and the changelog too ;p You have to do the same with SASLv2 m4 if you use SASLv2. Anyone else see this? yes, Solution above. Anyway, even after that, TLS does not work anylonger. I always get verify=NOT if I try to send mail with my other clients. 8.12.9-latest from SID before 8.12.10-1 works fine. -- ciao, Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: STARTTLS wierdness in sendmail 8.12.10-1
Hey, On Fri, 2003-09-19 at 13:33, Marc-Christian Petersen wrote: On Friday 19 September 2003 17:59, Brian Rectanus wrote: Hi Brian, I cannot get STARTTLS to work with the newest snendmail in unstable. It *always* complains that the key file is group readable! Now, before you scream RTFM, I did use GroupReadableKeyFile! please copy /usr/share/sendmail/examples/starttls.m4 to /etc/mail/tls and execute 'sendmailconfig' after you copied the file over. It's an updated file you have to use by now. You should have read the install message by the sendmail update and the changelog too ;p You have to do the same with SASLv2 m4 if you use SASLv2. Yeah, I had done that (for tls and sasl). It puts this in submit.cf: O DontBlameSendmail=,GroupReadableKeyFile I thought maybe that screwed things up starting with a comma, so (as I wrote earlier) I just added a straight define(`confDONT_BLAME_SENDMAIL', `GroupReadableKeyFile') to give O DontBlameSendmail=GroupReadableKeyFile But *neither* work. Both put GroupReadableKeyFile in submit.cf, and seem to ignore it, giving me: STARTTLS=server: file /etc/mail/tls/sendmail-common.key unsafe: Group readable file Anyone else see this? yes, Solution above. Anyway, even after that, TLS does not work anylonger. I always get verify=NOT if I try to send mail with my other clients. 8.12.9-latest from SID before 8.12.10-1 works fine. -- ciao, Marc I have gone to using the stable version until a fixed version is in unstable. Thanks, -Brian signature.asc Description: This is a digitally signed message part
Re: STARTTLS wierdness in sendmail 8.12.10-1
On Friday 19 September 2003 23:27, Richard A Nelson wrote:
Hi Richard,
aha... in my case (all my boxen, in fact) the certificate just
expired !!!
I ran /usr/share/sendmail/update_tls new to create a new set of
certificates and things are now kosher !
Sep 19 21:22:20 renegade sendmail[22155]: STARTTLS=client,
relay=localhost.badlands.org., version=TLSv1/SSLv3, verify=OK,
cipher=DHE-RSA-AES256-SHA, bits=256/256
Sep 19 21:22:20 renegade sm-mta[22156]: STARTTLS=server, relay=localhost
[127.0.0.1], version=TLSv1/SSLv3, verify=OK, cipher=DHE-RSA-AES256-SHA,
bits=256/256
so, if you get a FAIL message, please check your expiration dates!
#openssl x509 -in /etc/mail/tls/sendmail-{server,client}.crt -enddate
that was my first try after I saw verify=NOT and it does not help at all, at
least not for me. My certificates are valid until January 2004!
--
ciao, Marc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sendmail package version weirdness
On Thu, Sep 18, 2003 at 10:58:49PM -0400, Robert Brockway wrote: Was there any particular reason that this newer fixed version has a version number the makes it look older than the exploitable version? Simple: it doesn't. The version in stable is 8.12.3-4, and the version on security.debian.org is 8.12.3-6.6. Your package came from someplace else. -- - mdz
Re: Sendmail package version weirdness
On Fri, 19 Sep 2003, Matt Zimmerman wrote: On Thu, Sep 18, 2003 at 10:58:49PM -0400, Robert Brockway wrote: Was there any particular reason that this newer fixed version has a version number the makes it look older than the exploitable version? Simple: it doesn't. The version in stable is 8.12.3-4, and the version on security.debian.org is 8.12.3-6.6. Your package came from someplace else. Hi Matt. Thanks for clearing that up. FYI I located the origin of the version I was using: http://people.debian.org/~cowboy/sendmail_8.12.3-7woody_i386.changes Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) The earth is but one country and mankind its citizens -Baha'u'llah
Re: Sendmail package version weirdness
On Fri, Sep 19, 2003 at 01:47:28AM -0400, Robert Brockway wrote: On Fri, 19 Sep 2003, Matt Zimmerman wrote: On Thu, Sep 18, 2003 at 10:58:49PM -0400, Robert Brockway wrote: Was there any particular reason that this newer fixed version has a version number the makes it look older than the exploitable version? Simple: it doesn't. The version in stable is 8.12.3-4, and the version on security.debian.org is 8.12.3-6.6. Your package came from someplace else. Hi Matt. Thanks for clearing that up. FYI I located the origin of the version I was using: http://people.debian.org/~cowboy/sendmail_8.12.3-7woody_i386.changes Just like anyone using debian.seabone.net for the debian-ipv6 repository for woody would have 8.12.9-3 installed... Regards, Jeremy Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) The earth is but one country and mankind its citizens -Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] signature.asc Description: Digital signature
STARTTLS wierdness in sendmail 8.12.10-1
I cannot get STARTTLS to work with the newest snendmail in unstable. It *always* complains that the key file is group readable! Now, before you scream RTFM, I did use GroupReadableKeyFile! I updated to sendmail 8.12.10-1 to patch CAN-2003-0681 CAN-2003-0694 When I startup I get... sm-mta[30148]: starting daemon (8.12.10): SMTP sm-mta[30148]: STARTTLS=server: file /etc/mail/tls/sendmail-common.key unsafe: Group readable file Fine, so GroupReadableKeyFile was not set by default as was before, so I stuck this in starttls.m4 define(`confDONT_BLAME_SENDMAIL', `GroupReadableKeyFile') Which does work and puts this in submit.cf O DontBlameSendmail=GroupReadableKeyFile But, I *still* get: sm-mta[6346]: starting daemon (8.12.10): SMTP sm-mta[6346]: STARTTLS=server: file /etc/mail/tls/sendmail-common.key unsafe: Group readable file Back on previous versions from testing and stable I do not get these messages. sm-mta[31901]: starting daemon (8.12.9): SMTP sm-mta[3719]: starting daemon (8.12.3): SMTP Anyone else see this? later, -Brian signature.asc Description: This is a digitally signed message part
Re: STARTTLS wierdness in sendmail 8.12.10-1
On Friday 19 September 2003 17:59, Brian Rectanus wrote: Hi Brian, I cannot get STARTTLS to work with the newest snendmail in unstable. It *always* complains that the key file is group readable! Now, before you scream RTFM, I did use GroupReadableKeyFile! please copy /usr/share/sendmail/examples/starttls.m4 to /etc/mail/tls and execute 'sendmailconfig' after you copied the file over. It's an updated file you have to use by now. You should have read the install message by the sendmail update and the changelog too ;p You have to do the same with SASLv2 m4 if you use SASLv2. Anyone else see this? yes, Solution above. Anyway, even after that, TLS does not work anylonger. I always get verify=NOT if I try to send mail with my other clients. 8.12.9-latest from SID before 8.12.10-1 works fine. -- ciao, Marc
Re: STARTTLS wierdness in sendmail 8.12.10-1
Hey, On Fri, 2003-09-19 at 13:33, Marc-Christian Petersen wrote: On Friday 19 September 2003 17:59, Brian Rectanus wrote: Hi Brian, I cannot get STARTTLS to work with the newest snendmail in unstable. It *always* complains that the key file is group readable! Now, before you scream RTFM, I did use GroupReadableKeyFile! please copy /usr/share/sendmail/examples/starttls.m4 to /etc/mail/tls and execute 'sendmailconfig' after you copied the file over. It's an updated file you have to use by now. You should have read the install message by the sendmail update and the changelog too ;p You have to do the same with SASLv2 m4 if you use SASLv2. Yeah, I had done that (for tls and sasl). It puts this in submit.cf: O DontBlameSendmail=,GroupReadableKeyFile I thought maybe that screwed things up starting with a comma, so (as I wrote earlier) I just added a straight define(`confDONT_BLAME_SENDMAIL', `GroupReadableKeyFile') to give O DontBlameSendmail=GroupReadableKeyFile But *neither* work. Both put GroupReadableKeyFile in submit.cf, and seem to ignore it, giving me: STARTTLS=server: file /etc/mail/tls/sendmail-common.key unsafe: Group readable file Anyone else see this? yes, Solution above. Anyway, even after that, TLS does not work anylonger. I always get verify=NOT if I try to send mail with my other clients. 8.12.9-latest from SID before 8.12.10-1 works fine. -- ciao, Marc I have gone to using the stable version until a fixed version is in unstable. Thanks, -Brian signature.asc Description: This is a digitally signed message part
Re: STARTTLS wierdness in sendmail 8.12.10-1
On Friday 19 September 2003 23:27, Richard A Nelson wrote:
Hi Richard,
aha... in my case (all my boxen, in fact) the certificate just
expired !!!
I ran /usr/share/sendmail/update_tls new to create a new set of
certificates and things are now kosher !
Sep 19 21:22:20 renegade sendmail[22155]: STARTTLS=client,
relay=localhost.badlands.org., version=TLSv1/SSLv3, verify=OK,
cipher=DHE-RSA-AES256-SHA, bits=256/256
Sep 19 21:22:20 renegade sm-mta[22156]: STARTTLS=server, relay=localhost
[127.0.0.1], version=TLSv1/SSLv3, verify=OK, cipher=DHE-RSA-AES256-SHA,
bits=256/256
so, if you get a FAIL message, please check your expiration dates!
#openssl x509 -in /etc/mail/tls/sendmail-{server,client}.crt -enddate
that was my first try after I saw verify=NOT and it does not help at all, at
least not for me. My certificates are valid until January 2004!
--
ciao, Marc
Re: about sendmail hole - relay restrictions bypassed
In all fairness, if this issue is in regards to the Verisign cluster fsck I don't think this has any place in Sendmail personally but rather in getting Verisign to un-fsck the problem and/or fix DNS servers not to respond in that manner as to allow that to happen... Regards, Jeremy On Thu, Sep 18, 2003 at 12:49:38PM +0900, Hideki Yamane wrote: Hi list, You know, as DSA-384-1, sendmail buffer overflow vulnerability is fixed but another hole sendmail relay access restrictions can be bypassed with bogus DNS(*) is NOT fixed yet. * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174907 Do you know why maintainer let this issue alone ? or not effect Debian package? (if so, this bug should be closed.) -- Regards, Hideki Yamanemailto:henrich @ iijmio-mail.jp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] signature.asc Description: Digital signature
Sendmail package version weirdness
Hi all. I took preventative measures to protect my exploitable sendmail until I could get the new package installed on my mail server (running Debian Stable). I did the usual sudo apt-get update sudo apt-get upgrade but wasn't seeing the new package. A little bit of investigation showed the problem. The version I was running (exploitable) was 8.12.3-7woody so when I tried to upgrade to the newer fixed version (8.12.3-6.6) it ways always seeing this as an older version failing to install it. Was there any particular reason that this newer fixed version has a version number the makes it look older than the exploitable version? Surely this will make life harder for people wanting to upgrade since the normal apt0-get method will fail. Was it just a mjessup with version numbering? :) If it was I'd suggest the fixed sendmail be re-issued with a higher version number to fix the problem. Thanks again, must have been a busy few days for you :) Cheers, Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) The earth is but one country and mankind its citizens -Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sendmail package version weirdness
On Thu, Sep 18, 2003 at 10:58:49PM -0400, Robert Brockway wrote: Was there any particular reason that this newer fixed version has a version number the makes it look older than the exploitable version? Simple: it doesn't. The version in stable is 8.12.3-4, and the version on security.debian.org is 8.12.3-6.6. Your package came from someplace else. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sendmail package version weirdness
On Fri, 19 Sep 2003, Matt Zimmerman wrote: On Thu, Sep 18, 2003 at 10:58:49PM -0400, Robert Brockway wrote: Was there any particular reason that this newer fixed version has a version number the makes it look older than the exploitable version? Simple: it doesn't. The version in stable is 8.12.3-4, and the version on security.debian.org is 8.12.3-6.6. Your package came from someplace else. Hi Matt. Thanks for clearing that up. FYI I located the origin of the version I was using: http://people.debian.org/~cowboy/sendmail_8.12.3-7woody_i386.changes Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) The earth is but one country and mankind its citizens -Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: about sendmail hole - relay restrictions bypassed
In all fairness, if this issue is in regards to the Verisign cluster fsck I don't think this has any place in Sendmail personally but rather in getting Verisign to un-fsck the problem and/or fix DNS servers not to respond in that manner as to allow that to happen... Regards, Jeremy On Thu, Sep 18, 2003 at 12:49:38PM +0900, Hideki Yamane wrote: Hi list, You know, as DSA-384-1, sendmail buffer overflow vulnerability is fixed but another hole sendmail relay access restrictions can be bypassed with bogus DNS(*) is NOT fixed yet. * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174907 Do you know why maintainer let this issue alone ? or not effect Debian package? (if so, this bug should be closed.) -- Regards, Hideki Yamanemailto:henrich @ iijmio-mail.jp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] signature.asc Description: Digital signature
Sendmail package version weirdness
Hi all. I took preventative measures to protect my exploitable sendmail until I could get the new package installed on my mail server (running Debian Stable). I did the usual sudo apt-get update sudo apt-get upgrade but wasn't seeing the new package. A little bit of investigation showed the problem. The version I was running (exploitable) was 8.12.3-7woody so when I tried to upgrade to the newer fixed version (8.12.3-6.6) it ways always seeing this as an older version failing to install it. Was there any particular reason that this newer fixed version has a version number the makes it look older than the exploitable version? Surely this will make life harder for people wanting to upgrade since the normal apt0-get method will fail. Was it just a mjessup with version numbering? :) If it was I'd suggest the fixed sendmail be re-issued with a higher version number to fix the problem. Thanks again, must have been a busy few days for you :) Cheers, Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) The earth is but one country and mankind its citizens -Baha'u'llah
[SECURITY] [DSA-384-1] New sendmail packages fix buffer overflows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 384-1 [EMAIL PROTECTED] http://www.debian.org/security/ Matt Zimmerman September 17th, 2003http://www.debian.org/security/faq - -- Package: sendmail Vulnerability : buffer overflows Problem-Type : remote Debian-specific: no CVE Ids: CAN-2003-0681 CAN-2003-0694 Two vulnerabilities were reported in sendmail. - CAN-2003-0681 A potential buffer overflow in ruleset parsing for Sendmail 8.12.9, when using the nonstandard rulesets (1) recipient (2), final, or (3) mailer-specific envelope recipients, has unknown consequences. - CAN-2003-0694 The prescan function in Sendmail 8.12.9 allows remote attackers to execute arbitrary code via buffer overflow attacks, as demonstrated using the parseaddr function in parseaddr.c. For the stable distribution (woody) these problems have been fixed in sendmail version 8.12.3-6.6 and sendmail-wide version 8.12.3+3.5Wbeta-5.5. For the unstable distribution (sid) these problems have been fixed in sendmail version 8.12.10-1. We recommend that you update your sendmail package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.6.dsc Size/MD5 checksum: 751 a7d0da0bedbe35592233cb9ce710f551 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.6.diff.gz Size/MD5 checksum: 255026 5a86a93275a55af8c92677469c4a8cd3 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3.orig.tar.gz Size/MD5 checksum: 1840401 b198b346b10b3b5afc8cb4e12c07ff4d http://security.debian.org/pool/updates/main/s/sendmail-wide/sendmail-wide_8.12.3+3.5Wbeta-5.5.dsc Size/MD5 checksum: 738 cc23a68bcf23332d560086c3c55cd16a http://security.debian.org/pool/updates/main/s/sendmail-wide/sendmail-wide_8.12.3+3.5Wbeta-5.5.diff.gz Size/MD5 checksum: 327218 7f2fc2d0efe7935713b2d77dec66359c http://security.debian.org/pool/updates/main/s/sendmail-wide/sendmail-wide_8.12.3+3.5Wbeta.orig.tar.gz Size/MD5 checksum: 1870451 4c7036e8042bae10a90da4a84a717963 Architecture independent components: http://security.debian.org/pool/updates/main/s/sendmail/sendmail-doc_8.12.3-6.6_all.deb Size/MD5 checksum: 747778 9c4362147654d4f28d8346fa4ad84ed0 Alpha architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.6_alpha.deb Size/MD5 checksum: 267842 4f53274558b9e29ca341721a68fb4adc http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.6_alpha.deb Size/MD5 checksum: 1109340 78cb6eb6b340e5dc52982889532a844a http://security.debian.org/pool/updates/main/s/sendmail-wide/sendmail-wide_8.12.3+3.5Wbeta-5.5_alpha.deb Size/MD5 checksum: 440712 b22b97caba3652ef2a7d9f35633e3040 ARM architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.6_arm.deb Size/MD5 checksum: 247568 ac8f0778eb56f7c0a852fdc54ef071b1 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.6_arm.deb Size/MD5 checksum: 979454 6b9898686e6361abe657c5fd75d962c5 http://security.debian.org/pool/updates/main/s/sendmail-wide/sendmail-wide_8.12.3+3.5Wbeta-5.5_arm.deb Size/MD5 checksum: 369568 3baf5caa46b2c9d0b67c6d60f47d8030 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.6_i386.deb Size/MD5 checksum: 237374 0662e6e9bb58db37a1d8f511e4ba2fce http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.6_i386.deb Size/MD5 checksum: 917848 3717265bb7ed3f5bd81fb9a712826cec http://security.debian.org/pool/updates/main/s/sendmail-wide/sendmail-wide_8.12.3+3.5Wbeta-5.5_i386.deb Size/MD5 checksum: 328914 23af5c312cef6a53f000f4663980b11d Intel IA-64 architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.6_ia64.deb Size/MD5 checksum: 282028 a35b9ca4cfc7a1c1ec6bdb1f2e00d8bb http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.6_ia64.deb Size/MD5 checksum: 1332734 9f4ae78c3aa4644366e7e3f4bb787096
about sendmail hole - relay restrictions bypassed
Hi list, You know, as DSA-384-1, sendmail buffer overflow vulnerability is fixed but another hole sendmail relay access restrictions can be bypassed with bogus DNS(*) is NOT fixed yet. * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174907 Do you know why maintainer let this issue alone ? or not effect Debian package? (if so, this bug should be closed.) -- Regards, Hideki Yamanemailto:henrich @ iijmio-mail.jp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
about sendmail hole - relay restrictions bypassed
Hi list, You know, as DSA-384-1, sendmail buffer overflow vulnerability is fixed but another hole sendmail relay access restrictions can be bypassed with bogus DNS(*) is NOT fixed yet. * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174907 Do you know why maintainer let this issue alone ? or not effect Debian package? (if so, this bug should be closed.) -- Regards, Hideki Yamanemailto:henrich @ iijmio-mail.jp
odd process running /usr/sbin/sendmail -i -CronDaemon -odi -oem root
I have had some problems with attempted hacks on my box and posted here the last few days. So I've been checking the processing running on my box and I see this. PID TTY STAT TIME COMMAND 28406 ?S 0:00 /usr/sbin/sendmail -i -FCronDaemon -odi -oem root I have postfix installed, and I'm not sure if this is a normal thing, or else a rogue process, or just a cron job that got stuck. As around the sametime my apache and apache-ssl both restarted wtih errors below. And this command has been running. I looked it up in google and only found 4 instances of it, most in other languages so it makes me think that it is not a normal process that should be running. If someone knows please share the info. Thanks for the help. apache/error.log:[Thu Jun 19 06:27:27 2003] [notice] SIGUSR1 received. Doing graceful restart apache/error.log:[Thu Jun 19 06:27:28 2003] [warn] module config_log_module is already loaded, sk ipping -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: odd process running /usr/sbin/sendmail -i -CronDaemon -odi -oem root
That is the process that sends out mail for a cronjob. I have had problems with those getting stuck if the mail message (output from the cron job) is more than 1 meg I think... it might have been more than 11 megs. I can't remember exactly but that is a normal process. I don't think it should stay in your process list for that long though... what does your pstree show? What is the parent process? you should be able to find out which cron it is being sent from as well. - Original Message - From: Robert Ebright [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 19, 2003 9:10 AM Subject: odd process running /usr/sbin/sendmail -i -CronDaemon -odi -oem root I have had some problems with attempted hacks on my box and posted here the last few days. So I've been checking the processing running on my box and I see this. PID TTY STAT TIME COMMAND 28406 ?S 0:00 /usr/sbin/sendmail -i -FCronDaemon -odi -oem root I have postfix installed, and I'm not sure if this is a normal thing, or else a rogue process, or just a cron job that got stuck. As around the sametime my apache and apache-ssl both restarted wtih errors below. And this command has been running. I looked it up in google and only found 4 instances of it, most in other languages so it makes me think that it is not a normal process that should be running. If someone knows please share the info. Thanks for the help. apache/error.log:[Thu Jun 19 06:27:27 2003] [notice] SIGUSR1 received. Doing graceful restart apache/error.log:[Thu Jun 19 06:27:28 2003] [warn] module config_log_module is already loaded, sk ipping -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: odd process running /usr/sbin/sendmail -i -CronDaemon -odi -oem root
On Thursday, 2003-06-19 at 10:10:10 -0500, Robert Ebright wrote: I have had some problems with attempted hacks on my box and posted here the last few days. So I've been checking the processing running on my box and I see this. PID TTY STAT TIME COMMAND 28406 ?S 0:00 /usr/sbin/sendmail -i -FCronDaemon -odi -oem root You may want to check with lsof which process is feeding STDIN of this sendmail process. lsof -p 28406 You'll see something like this: sendmail 27413 lupe0r FIFO0,5 2637562 pipe There is probably a better way, but I do this then: lsof | grep 2637562 And I find I started a sleep command that (never) feeds the sendmail process: sleep 27412 lupe1w FIFO0,5 2637562 pipe HTH, Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Violence is the resort of the violent Lu Tze | | Thief of Time, Terry Pratchett | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: odd process running /usr/sbin/sendmail -i -CronDaemon -odi -oem root
Robert Ebright [EMAIL PROTECTED] writes: I have had some problems with attempted hacks on my box and posted here the last few days. So I've been checking the processing running on my box and I see this. PID TTY STAT TIME COMMAND 28406 ?S 0:00 /usr/sbin/sendmail -i -FCronDaemon -odi -oem root I have postfix installed, and I'm not sure if this is a normal thing, or else a rogue process, or just a cron job that got stuck. As around the Nearly every MTA out there has a - more or less compatible - sendmail interface. Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
odd process running /usr/sbin/sendmail -i -CronDaemon -odi -oem root
I have had some problems with attempted hacks on my box and posted here the last few days. So I've been checking the processing running on my box and I see this. PID TTY STAT TIME COMMAND 28406 ?S 0:00 /usr/sbin/sendmail -i -FCronDaemon -odi -oem root I have postfix installed, and I'm not sure if this is a normal thing, or else a rogue process, or just a cron job that got stuck. As around the sametime my apache and apache-ssl both restarted wtih errors below. And this command has been running. I looked it up in google and only found 4 instances of it, most in other languages so it makes me think that it is not a normal process that should be running. If someone knows please share the info. Thanks for the help. apache/error.log:[Thu Jun 19 06:27:27 2003] [notice] SIGUSR1 received. Doing graceful restart apache/error.log:[Thu Jun 19 06:27:28 2003] [warn] module config_log_module is already loaded, sk ipping
Re: odd process running /usr/sbin/sendmail -i -CronDaemon -odi -oem root
That is the process that sends out mail for a cronjob. I have had problems with those getting stuck if the mail message (output from the cron job) is more than 1 meg I think... it might have been more than 11 megs. I can't remember exactly but that is a normal process. I don't think it should stay in your process list for that long though... what does your pstree show? What is the parent process? you should be able to find out which cron it is being sent from as well. - Original Message - From: Robert Ebright [EMAIL PROTECTED] To: debian-security@lists.debian.org Sent: Thursday, June 19, 2003 9:10 AM Subject: odd process running /usr/sbin/sendmail -i -CronDaemon -odi -oem root I have had some problems with attempted hacks on my box and posted here the last few days. So I've been checking the processing running on my box and I see this. PID TTY STAT TIME COMMAND 28406 ?S 0:00 /usr/sbin/sendmail -i -FCronDaemon -odi -oem root I have postfix installed, and I'm not sure if this is a normal thing, or else a rogue process, or just a cron job that got stuck. As around the sametime my apache and apache-ssl both restarted wtih errors below. And this command has been running. I looked it up in google and only found 4 instances of it, most in other languages so it makes me think that it is not a normal process that should be running. If someone knows please share the info. Thanks for the help. apache/error.log:[Thu Jun 19 06:27:27 2003] [notice] SIGUSR1 received. Doing graceful restart apache/error.log:[Thu Jun 19 06:27:28 2003] [warn] module config_log_module is already loaded, sk ipping -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: odd process running /usr/sbin/sendmail -i -CronDaemon -odi -oem root
On Thursday, 2003-06-19 at 10:10:10 -0500, Robert Ebright wrote: I have had some problems with attempted hacks on my box and posted here the last few days. So I've been checking the processing running on my box and I see this. PID TTY STAT TIME COMMAND 28406 ?S 0:00 /usr/sbin/sendmail -i -FCronDaemon -odi -oem root You may want to check with lsof which process is feeding STDIN of this sendmail process. lsof -p 28406 You'll see something like this: sendmail 27413 lupe0r FIFO0,5 2637562 pipe There is probably a better way, but I do this then: lsof | grep 2637562 And I find I started a sleep command that (never) feeds the sendmail process: sleep 27412 lupe1w FIFO0,5 2637562 pipe HTH, Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Violence is the resort of the violent Lu Tze | | Thief of Time, Terry Pratchett |
Re: odd process running /usr/sbin/sendmail -i -CronDaemon -odi -oem root
Robert Ebright [EMAIL PROTECTED] writes: I have had some problems with attempted hacks on my box and posted here the last few days. So I've been checking the processing running on my box and I see this. PID TTY STAT TIME COMMAND 28406 ?S 0:00 /usr/sbin/sendmail -i -FCronDaemon -odi -oem root I have postfix installed, and I'm not sure if this is a normal thing, or else a rogue process, or just a cron job that got stuck. As around the Nearly every MTA out there has a - more or less compatible - sendmail interface. Regards, Olaf.
[SECURITY] [DSA-305-1] New sendmail packages fix insecure temporary file creation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 305-1 [EMAIL PROTECTED] http://www.debian.org/security/ Matt Zimmerman May 15th, 2003 http://www.debian.org/security/faq - -- Package: sendmail Vulnerability : insecure temporary files Problem-Type : local Debian-specific: no Paul Szabo discovered bugs in three scripts included in the sendmail package where temporary files were created insecurely (expn, checksendmail and doublebounce.pl). These bugs could allow an attacker to gain the privileges of a user invoking the script (including root). For the stable distribution (woody) these problems have been fixed in version 8.12.3-6.4. For the old stable distribution (potato) these problems have been fixed in version 8.9.3-26.1. For the unstable distribution (sid) these problems have been fixed in version 8.12.9-2. We recommend that you update your sendmail package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.4.dsc Size/MD5 checksum: 751 a7ee211817b085cd9ec16b91d9b15e40 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.4.diff.gz Size/MD5 checksum: 254004 fdafe4a26c22db6844bfba3cf3f5c150 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3.orig.tar.gz Size/MD5 checksum: 1840401 b198b346b10b3b5afc8cb4e12c07ff4d Architecture independent components: http://security.debian.org/pool/updates/main/s/sendmail/sendmail-doc_8.12.3-6.4_all.deb Size/MD5 checksum: 747626 68962801ab229167f31f52d9b9aea4ca Alpha architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.4_alpha.deb Size/MD5 checksum: 267738 ac9f3641c7256cd406ea6d900fcf478d http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.4_alpha.deb Size/MD5 checksum: 1109330 1b259d1b5dc2b7c3d2ed35da6ff14c8d ARM architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.4_arm.deb Size/MD5 checksum: 247474 43abe86241c0ced4931b602505e8f194 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.4_arm.deb Size/MD5 checksum: 979268 8618fd412f56022ba4fab7c3c20bd633 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.4_i386.deb Size/MD5 checksum: 237226 2044308a32e930663f6a85d67ffe29df http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.4_i386.deb Size/MD5 checksum: 917564 ec4d0e7bec9c8b2ff8825d1cdb127609 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.4_ia64.deb Size/MD5 checksum: 281920 52d959e3200497065a01940ecdfcd2bc http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.4_ia64.deb Size/MD5 checksum: 1332584 bcc17145035c3489bc549394c439b39c HP Precision architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.4_hppa.deb Size/MD5 checksum: 261588 8a723a94e65fae545477c50bc5ddbde0 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.4_hppa.deb Size/MD5 checksum: 1081110 bd650bd43791051924346261e00ebdd6 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.4_m68k.deb Size/MD5 checksum: 231056 4a895563d173c29e44145799483c74c5 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.4_m68k.deb Size/MD5 checksum: 865698 f26fca022aa78eaf55c67eece4fd8b0e Big endian MIPS architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.4_mips.deb Size/MD5 checksum: 255082 245d7936db41f577318588ae8ae15379 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.4_mips.deb Size/MD5 checksum: 1022152 3ba322f09c8b7d55e737c0f3e483a950 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.4_mipsel.deb Size/MD5 checksum: 254774 b3dde1b51d7adfeae424d9b7ec28310f
Re: sendmail + mailscanner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 14 April 2003 21:31, Répási Tibor wrote: Hy, just follow the steps described in /usr/share/sendmail/examples/amavis download the lates sources and it works. I've installed it a few weeks ago and it is running well. I'm using it with f-prot, but You can config it for any antivir software You want. Regards, Tibor Repasi Hi Tibor! I followed your advice and installed mailscanner with f-prot. Now, when I fetch the mails and mailscanner scans them, I see in my /var/log/mail.log: May 2 14:11:17 blackhawk mailscanner[237]: Scanning 2 messages, 8063 bytes May 2 14:11:53 blackhawk mailscanner[237]: Either you've found a bug in MailScanner's F-Prot output parser, or F-Prot's output format has changed! F-Prot said this Search: .. Please mail the author of MailScanner May 2 14:11:53 blackhawk mailscanner[237]: Either you've found a bug in MailScanner's F-Prot output parser, or F-Prot's output format has changed! F-Prot said this Action: Report only. Please mail the author of MailScanner May 2 14:11:53 blackhawk mailscanner[237]: Either you've found a bug in MailScanner's F-Prot output parser, or F-Prot's output format has changed! F-Prot said this Files: Dumb scan of all files. Please mail the author of MailScanner May 2 14:11:53 blackhawk mailscanner[237]: Either you've found a bug in MailScanner's F-Prot output parser, or F-Prot's output format has changed! F-Prot said this Switches: -ARCHIVE -OLD. Please mail the author of MailScanner May 2 14:11:53 blackhawk mailscanner[237]: Scanned 2 messages, 8063 bytes in 0 seconds What's the problem here? How could I say to fetchmail (or mailscanner, I don't know!) that this is not a problem but only the output of the f-prot antivirus? Thanks for your help. Matteo - -- Debian GNU/Linux. The most software. The most people. The biggest is still the best. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+smQ/wpmiLhhMAcoRAsXNAJ0Zsb3q3sEVFUvk4q0Der1zHK1skwCfYX+v +CXnxtp3qdegPaGJ0BCg/to= =lG7/ -END PGP SIGNATURE-
Re: sendmail + mailscanner
Hy, please consider that amavis and mailscanner are completly different mail scanners. AFAIK: There is no standard debian package containing amavis for sendmail, only for postfix. The error messages in Your log are generated, by mailscanner. I would say that Your mailscanner expects an other version of f-prot than You use. What You can do is to mail the author of MailScanner. Regards, Tibor Repasi Matteo Vescovi wrote: May 2 14:11:53 blackhawk mailscanner[237]: Either you've found a bug in MailScanner's F-Prot output parser, or F-Prot's output format has changed! F-Prot said this Switches: -ARCHIVE -OLD. Please mail the author of MailScanner
sendmail + mailscanner
Hello! I know this is not specially a security topic, but I need to do this for My security :)) I'm using sendmail, and I want to use mailscanner and spamassassin with it. I don't know how to configure sendmail to work with mailscanner. The mailscanner's howtos are very outdated, and in the mailscanner's homepage, there is the same howtos. So, if someone knows what should I do, to work sendmail with mailscanner, please let me know. Thanks. Levai Daniel [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: sendmail + mailscanner
Hy, just follow the steps described in /usr/share/sendmail/examples/amavis download the lates sources and it works. I've installed it a few weeks ago and it is running well. I'm using it with f-prot, but You can config it for any antivir software You want. Regards, Tibor Repasi LeVA wrote: Hello! I know this is not specially a security topic, but I need to do this for My security :)) I'm using sendmail, and I want to use mailscanner and spamassassin with it. I don't know how to configure sendmail to work with mailscanner. The mailscanner's howtos are very outdated, and in the mailscanner's homepage, there is the same howtos. So, if someone knows what should I do, to work sendmail with mailscanner, please let me know. Thanks. Levai Daniel [EMAIL PROTECTED]
[SECURITY] [DSA 278-1] New sendmail packages fix denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 278-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze April 4th, 2003 http://www.debian.org/security/faq - -- Package: sendmail Vulnerability : char-to-int conversion Problem-Type : local, maybe remote Debian-specific: no CVE Id : CAN-2003-0161 CERT Id: VU#897604 CA-2003-12 Michal Zalewski discovered a buffer overflow, triggered by a char to int conversion, in the address parsing code in sendmail, a widely used powerful, efficient, and scalable mail transport agent. This problem is potentially remotely exploitable. For the stable distribution (woody) this problem has been fixed in version 8.12.3-6.2. For the stable distribution (woody) this problem has been fixed in version 8.9.3-26. For the unstable distribution (sid) this problem has been fixed in version 8.12.9-1. We recommend that you upgrade your sendmail packages. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 2.2 alias potato - - Source archives: http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26.dsc Size/MD5 checksum: 649 f11b024ef774130f7918b882a7318c78 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26.diff.gz Size/MD5 checksum: 143360 2e9868662e4e28e548ed9f6da2982b41 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3.orig.tar.gz Size/MD5 checksum: 1068290 efedacfbce84a71d1cfb0e617b84596e Alpha architecture: http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26_alpha.deb Size/MD5 checksum: 989736 a435c32c79785261bd0e7ec921718915 ARM architecture: http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26_arm.deb Size/MD5 checksum: 948306 1bdd277a28bd6a6c3c812053d11b1edd Intel IA-32 architecture: http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26_i386.deb Size/MD5 checksum: 931838 36c569e21502a246dbdfba711b54842e Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26_m68k.deb Size/MD5 checksum: 917632 8ed928ac433a6be8d3144bb435bf1cfd PowerPC architecture: http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26_powerpc.deb Size/MD5 checksum: 933820 000557eff8d57fa2e479e8df52348f0b Sun Sparc architecture: http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26_sparc.deb Size/MD5 checksum: 945760 c2e0e3d1edb05a00d3e5b0d8ca1053c8 Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.2.dsc Size/MD5 checksum: 761 9eae4393094b7b163ecdddcd16dad19e http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.2.diff.gz Size/MD5 checksum: 253152 1fcbf7838b267d06a8c6258d3ff56488 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3.orig.tar.gz Size/MD5 checksum: 1840401 b198b346b10b3b5afc8cb4e12c07ff4d Architecture independent components: http://security.debian.org/pool/updates/main/s/sendmail/sendmail-doc_8.12.3-6.2_all.deb Size/MD5 checksum: 747408 5d83e06ac78cb55eabb9334235ec82ab Alpha architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.2_alpha.deb Size/MD5 checksum: 267450 a8fd2edcabf581c8cef66fc1dcb5a8aa http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.2_alpha.deb Size/MD5 checksum: 1218398 cf5503083ecacd7049171922e2fe15c7 ARM architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.2_arm.deb Size/MD5 checksum: 247160 2a01bee8674426bc1a3ef3c40a39e4a1 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.2_arm.deb Size/MD5 checksum: 1066282 2dc41903235f6a88de369807e633f8c9 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.2_i386.deb Size/MD5 checksum: 236942 fb790940bcdfcd6231db136c6d381cb5 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.2_i386.deb
[SECURITY] [DSA 278-2] New sendmail packages fix DoS and arbitrary code execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 278-2 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze April 4th, 2003 http://www.debian.org/security/faq - -- Package: sendmail Vulnerability : char-to-int conversion Problem-Type : local, maybe remote Debian-specific: no CVE Id : CAN-2003-0161 CERT Id: VU#897604 CA-2003-12 This is a major brown paperbag update. The old packages for the stable distribution (woody) did not work as expected and you should only update to the neww packages mentioned in this advisory. The packages in the old stable distribution (potato) are working properly. I'm awfully sorry for the inconvenience. At the moment updated packages are only available for alpha, i386 and sparc. The original advisory was: Michal Zalewski discovered a buffer overflow, triggered by a char to int conversion, in the address parsing code in sendmail, a widely used powerful, efficient, and scalable mail transport agent. This problem is potentially remotely exploitable. For the stable distribution (woody) this problem has been fixed in version 8.12.3-6.3. We recommend that you upgrade your sendmail packages. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.3.dsc Size/MD5 checksum: 761 105b2619c72e95e90aec1f8dbe69fb6d http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.3.diff.gz Size/MD5 checksum: 253206 95f7f532f1f94061803d0b5407c7bd7a http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3.orig.tar.gz Size/MD5 checksum: 1840401 b198b346b10b3b5afc8cb4e12c07ff4d Architecture independent components: http://security.debian.org/pool/updates/main/s/sendmail/sendmail-doc_8.12.3-6.3_all.deb Size/MD5 checksum: 747428 b3ade8ee7ac5de3f7e9a66eaf51654c0 Alpha architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.3_alpha.deb Size/MD5 checksum: 267498 9616df6f9a46472c1fd6e3d2a418d9f8 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.3_alpha.deb Size/MD5 checksum: 1218434 23579de1583d6fb9976e1b1c2f59fc00 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.3_i386.deb Size/MD5 checksum: 236984 2a1bef62b8cbf587529a798b1090429c http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.3_i386.deb Size/MD5 checksum: 1003430 66deba993c135453e2e554faf4955615 Sun Sparc architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.3_sparc.deb Size/MD5 checksum: 244974 0a2bbdfec93148f2fa796874012dfc2a http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.3_sparc.deb Size/MD5 checksum: 1069450 cbe517ba8fbd191dc5dffe1604da4454 These files will probably be moved into the stable distribution on its next revision. - - For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: [EMAIL PROTECTED] Package info: `apt-cache show pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+jZ1cW5ql+IAeqTIRAi6LAJ9P5zic6h3qnrC9cLgaohqhkLEVkACfVYBQ RSwaaq8JX/n9MjU12wVRVFM= =58hR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
