[qmailtoaster] re: qtp-newmodel failure
I have a fresh install of the QMTISO with yum updates completed and qtp installed. I tried to update the toaster using the newmodel and got this error. Would you like a unionfs/overlay sandbox? (recommended) [y]/n: Using FUSE union filesystem ... qtp-mount-sandbox v0.3.3 qtp-mount-sandbox - updating dependencies ... Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons: mirror.san.fastserv.com * base: centos.promopeddler.com * extras: mirror.hmc.edu * rpmforge: apt.sw.be * updates: mirrors.cat.pdx.edu Setting up Update Process No Packages marked for Update fuse: device not found, try 'modprobe fuse' first FATAL: Module fuse not found. fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first mount: mount point /mnt/qtp-sandbox/var/lib/rpm does not exist cp: target `/mnt/qtp-sandbox/var/lib/rpm' is not a directory qtp-mount-sandbox: sandbox was not mounted successfully qtp-newmodel - qtp-mount-sandbox failed, exiting # modprobe fuse FATAL: Module fuse not found. -- Cecil Yother, Jr. "cj" cj's 2318 Clement Ave Alameda, CA 94501 tel 510.865.2787 http://yother.com Check out the new Volvo classified resource http://www.volvoclassified.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] re: qtp-newmodel failure
Hi, Do you have the fuse utilities installed? yum install fuse Perhaps that's what you're missing... Martin -- Martin Waschbüsch IT-Dienstleistungen Lautensackstr. 16 80687 München Telefon: +49 89 57005708 Fax: +49 89 57868023 Mobil: +49 170 2189794 mar...@waschbuesch.de http://martin.waschbuesch.de Am 28.10.2010 um 10:34 schrieb Maxwell Smart: > I have a fresh install of the QMTISO with yum updates completed and qtp > installed. I tried to update the toaster using the newmodel and got this > error. > > Would you like a unionfs/overlay sandbox? (recommended) [y]/n: > > Using FUSE union filesystem ... > qtp-mount-sandbox v0.3.3 > qtp-mount-sandbox - updating dependencies ... > Loaded plugins: fastestmirror > Loading mirror speeds from cached hostfile > * addons: mirror.san.fastserv.com > * base: centos.promopeddler.com > * extras: mirror.hmc.edu > * rpmforge: apt.sw.be > * updates: mirrors.cat.pdx.edu > Setting up Update Process > No Packages marked for Update > fuse: device not found, try 'modprobe fuse' first > FATAL: Module fuse not found. > fuse: device not found, try 'modprobe fuse' first > fuse: device not found, try 'modprobe fuse' first > fuse: device not found, try 'modprobe fuse' first > fuse: device not found, try 'modprobe fuse' first > fuse: device not found, try 'modprobe fuse' first > fuse: device not found, try 'modprobe fuse' first > fuse: device not found, try 'modprobe fuse' first > fuse: device not found, try 'modprobe fuse' first > fuse: device not found, try 'modprobe fuse' first > fuse: device not found, try 'modprobe fuse' first > fuse: device not found, try 'modprobe fuse' first > fuse: device not found, try 'modprobe fuse' first > mount: mount point /mnt/qtp-sandbox/var/lib/rpm does not exist > cp: target `/mnt/qtp-sandbox/var/lib/rpm' is not a directory > qtp-mount-sandbox: sandbox was not mounted successfully > > qtp-newmodel - qtp-mount-sandbox failed, exiting > > > # modprobe fuse > > FATAL: Module fuse not found. > > > > -- > Cecil Yother, Jr. "cj" > cj's > 2318 Clement Ave > Alameda, CA 94501 > > tel 510.865.2787 > http://yother.com > Check out the new Volvo classified resource http://www.volvoclassified.com > > > - > Qmailtoaster is sponsored by Vickers Consulting Group > (www.vickersconsulting.com) > Vickers Consulting Group offers Qmailtoaster support and installations. > If you need professional help with your setup, contact them today! > - >Please visit qmailtoaster.com for the latest news, updates, and packages. > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] re: qtp-newmodel failure
You could try this to find out first... [r...@myserver]# rpm -qa | grep fuse fuse-2.7.4-8.el5 fuse-libs-2.7.4-8.el5 fuse-unionfs-0.23-1.el5.rf dkms-fuse-2.7.4-1.nodist.rf Then if you get no results or notthe same as a bove try this.. [r...@indialau ntfsprogs-2.0.0]# yum -y install fuse On 28/10/2010 7:34 PM, Maxwell Smart wrote: I have a fresh install of the QMTISO with yum updates completed and qtp installed. I tried to update the toaster using the newmodel and got this error. Would you like a unionfs/overlay sandbox? (recommended) [y]/n: Using FUSE union filesystem ... qtp-mount-sandbox v0.3.3 qtp-mount-sandbox - updating dependencies ... Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons: mirror.san.fastserv.com * base: centos.promopeddler.com * extras: mirror.hmc.edu * rpmforge: apt.sw.be * updates: mirrors.cat.pdx.edu Setting up Update Process No Packages marked for Update fuse: device not found, try 'modprobe fuse' first FATAL: Module fuse not found. fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first mount: mount point /mnt/qtp-sandbox/var/lib/rpm does not exist cp: target `/mnt/qtp-sandbox/var/lib/rpm' is not a directory qtp-mount-sandbox: sandbox was not mounted successfully qtp-newmodel - qtp-mount-sandbox failed, exiting # modprobe fuse FATAL: Module fuse not found. -- best wishes Tony White - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Qmail & Ical server invitation reply
Problem: manage replay to invitations managed from iCal server ( the syntax of responses is Using postfix the solution is set the recipient_delimiter = + There is a similar solution with qmail? Thanks. -- Davide E. Bovolenta - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] smtp greeting banner frustration
Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 cpa2.localdomain - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin
RE: [qmailtoaster] smtp greeting banner frustration
This happens because you smtp service is listening on all ip addresses. If you want to send separate greeting message individual domains you'll have to configure multiples instances of smtp services for all the domains on your server. I am not an expert but this my own understanding, I could be wrong. Regards, Anil Aliyan From: Edward Finlayson [mailto:edward.finlay...@btinternet.com] Sent: 28 October 2010 16:02 To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] smtp greeting banner frustration Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 cpa2.localdomain - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin
RE: [qmailtoaster] smtp greeting banner frustration
This happens because you smtp service is listening on all ip addresses. If you want to send separate greeting message individual domains you'll have to configure multiples instances of smtp services for all the domains listening to the specific ip address bindings on your server. I am not an expert but this my own understanding, I could be wrong. Regards, Anil Aliyan From: Edward Finlayson [mailto:edward.finlay...@btinternet.com] Sent: 28 October 2010 16:02 To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] smtp greeting banner frustration Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 cpa2.localdomain - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin
RE: [qmailtoaster] smtp greeting banner frustration
Thanks for your reply Anil, I was afraid that you might say that. Doesn't that mean that I need complete installations of toaster? I was hoping that someone had patched the daemon L Thanks again, Fin PS: Just in case... any Uber-Geeks out there with alternate suggestions? From: Anil Aliyan [mailto:acali...@gnvfc.net] Sent: 28 October 2010 12:34 To: qmailtoaster-list@qmailtoaster.com Subject: RE: [qmailtoaster] smtp greeting banner frustration This happens because you smtp service is listening on all ip addresses. If you want to send separate greeting message individual domains you'll have to configure multiples instances of smtp services for all the domains listening to the specific ip address bindings on your server. I am not an expert but this my own understanding, I could be wrong. Regards, Anil Aliyan From: Edward Finlayson [mailto:edward.finlay...@btinternet.com] Sent: 28 October 2010 16:02 To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] smtp greeting banner frustration Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 cpa2.localdomain - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin
RE: [qmailtoaster] smtp greeting banner frustration
May be you can get some help from the link given below: http://www.gossamer-threads.com/lists/qmail/users/129252 Regards, Anil Aliyan From: Edward Finlayson [mailto:edward.finlay...@btinternet.com] Sent: 28 October 2010 17:14 To: qmailtoaster-list@qmailtoaster.com Subject: RE: [qmailtoaster] smtp greeting banner frustration Thanks for your reply Anil, I was afraid that you might say that. Doesn't that mean that I need complete installations of toaster? I was hoping that someone had patched the daemon L Thanks again, Fin PS: Just in case... any Uber-Geeks out there with alternate suggestions? From: Anil Aliyan [mailto:acali...@gnvfc.net] Sent: 28 October 2010 12:34 To: qmailtoaster-list@qmailtoaster.com Subject: RE: [qmailtoaster] smtp greeting banner frustration This happens because you smtp service is listening on all ip addresses. If you want to send separate greeting message individual domains you'll have to configure multiples instances of smtp services for all the domains listening to the specific ip address bindings on your server. I am not an expert but this my own understanding, I could be wrong. Regards, Anil Aliyan From: Edward Finlayson [mailto:edward.finlay...@btinternet.com] Sent: 28 October 2010 16:02 To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] smtp greeting banner frustration Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 cpa2.localdomain - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin
Re: [qmailtoaster] smtp greeting banner frustration
My first reply does not seem to have arrive so I will try again... If I understand your question it should be as easy as editing the smtpgreeting file to reflect the rDNS value. ie edit /var/qmail.control/smtpgreeting to mail.domain.com On 28/10/2010 10:31 PM, Anil Aliyan wrote: This happens because you smtp service is listening on all ip addresses. If you want to send separate greeting message individual domains you’ll have to configure multiples instances of smtp services for all the domains on your server. I am not an expert but this my own understanding, I could be wrong. Regards, Anil Aliyan *From:*Edward Finlayson [mailto:edward.finlay...@btinternet.com] *Sent:* 28 October 2010 16:02 *To:* qmailtoaster-list@qmailtoaster.com *Subject:* [qmailtoaster] smtp greeting banner frustration Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin -- best wishes Tony White - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Domainpop
I don't know how to thank you. You have just same me right now and I am so glad. Thank you very much. The link you provided helped me and I now have what I wanted. Thank you. --- On Tue, 10/26/10, Amit Dalia wrote: From: Amit Dalia Subject: Re: [qmailtoaster] Re: Domainpop To: "qmailtoaster-list@qmailtoaster.com" Date: Tuesday, October 26, 2010, 6:56 AM Please go through below wiki link: http://wiki.qmailtoaster.com/index.php/How_to_Setup_Google_As_Backup_Server you can skip first 5 steps. Amit At Wednesday, 27-10-2010 on 0:02 Emmanuel Buamah wrote: Yes, I am trying to download mails from remote catchall account and deliver those mail to respective users. Yes, people have mention fetchmail, but how to make it work with QMT is my problem. Can you help me out. --- On Tue, 10/26/10, Amit Dalia wrote: From: Amit Dalia Subject: Re: [qmailtoaster] Re: Domainpop To: "qmailtoaster-list@qmailtoaster.com" Date: Tuesday, October 26, 2010, 4:29 AM Are you trying trying to download mails from remote catchall account and deliver those mail to respective users. As far as I worked on MDaemon and Exchange POP they work in same manner. If this is what you trying to accomplish then fetchmail is the very simple option. Amit At Tuesday, 26-10-2010 on 20:08 Emmanuel Buamah wrote: No, that will not help with what am actually trying to do. Example is if you look at MDaemon which is a windows base, it has as domain pop function, and also Exchange uses native pop. That is the kind of thing I want to do. --- On Tue, 10/26/10, Eric Shubert wrote: From: Eric Shubert Subject: [qmailtoaster] Re: Domainpop To: qmailtoaster-list@qmailtoaster.com Date: Tuesday, October 26, 2010, 2:21 AM So in addition to setting up fetchmail, set up a forward (using qmailadmin) for the local address (myqmtacct) that sends it to as many addresses (local or remote) as you'd like. Wouldn't that take care of it? -- -Eric 'shubes' On 10/26/2010 05:30 AM, Emmanuel Buamah wrote: > Thank you very much. But what I actually looking for is that, I have a > mail server wich is a pop of course. On that pop server, I have only one > account for the domain which is turn catch-all acount. Any mail for my > domain to all users will be send to the catch-all account. > > So I want to configure fetchmail to download mails and distribute it to > the various users. > > This is where mails are stored on the qmail server: > /home/vpopmail/domains/domain/user/Maildir/ > > What you wrote is actually going to work for local users only. > > > --- On *Mon, 10/25/10, Eric Shubert //* wrote: > > > From: Eric Shubert > Subject: [qmailtoaster] Re: Domainpop > To: qmailtoaster-list@qmailtoaster.com > Date: Monday, October 25, 2010, 3:47 AM > > On 10/25/2010 06:53 AM, Jake Vickers wrote: > > On 10/25/2010 07:05 AM, Emmanuel Buamah wrote: > >> Thank you but I have tried fetch mail some time back but didn't work > >> for me. The issue is qmail uses virtual users and the fetchmail > is not > >> capable of handling virtual domain and all this. Well if it is, I > >> haven't come accross it so if some one have any idea, I will > love it. > >> > > > > fetchmail does indeed work. I've used it myself in the past. > Search the > > archives: > > http://www.mail-archive.com/qmailtoaster-list@qmailtoaster.com > > It's been discussed a couple of times how to set it up to POP > mail from > > somewhere else and deliver it to a QMT user. > > > > Fetchmail surely does work with QMT. Here's a sample > /root/.fetchmailrc (configuration) file: > > # These are global options > set no bouncemail > set postmaster postmas...@mydomain.com > > set syslog > # These are server/user options > poll pop.west.cox.net \ > protocol pop3 \ > timeout 120 > username "mycoxuser" there \ > is "myqmta...@mydomain.com " > here \ > antispam 554 \ > fetchall \ > password "mycoxpassword" \ > smtphost localhost \ > ssl \ > sslcertck > > Perhaps we should have a wiki page describing how to do it (if there > isn't one already). Would someone like to tackle this? > > -- -Eric 'shubes' > > > >- > Qmailtoaster is sponsored by Vickers Consulting Group > (www.vickersconsulting.com) > Vickers Consulting Group offers Qmailtoaster support and installations. > If you need professional help with your setup, contact them today! > >- > Please visit qmailtoaster.com for the latest news, updates, and > packages. > To unsubscribe, e-mail: > qmailtoaster-list-unsubscr...@qmailtoaster.com > > For additional commands, e-mail: > qmailtoaster-list-h...@qmailtoaster.com > > > > -
RE: [qmailtoaster] smtp greeting banner frustration
Hi Tony, This would be true for a single domain, however my setup is more like that below: 127.0.1.1 mail.domina1.com 127.0.1.2 smtp.domain2.co.uk 127.0.8.30 mail.domain30.net 127.0.8.90 mail.domain90.com 127.2.1.112 mx1.domain112.org Obviously, I've obfuscated the real addresses and domains but the layout above is representative. Thanks again Tony, Fin -Original Message- From: Tony White [mailto:t...@ycs.com.au] Sent: 28 October 2010 13:17 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration My first reply does not seem to have arrive so I will try again... If I understand your question it should be as easy as editing the smtpgreeting file to reflect the rDNS value. ie edit /var/qmail.control/smtpgreeting to mail.domain.com On 28/10/2010 10:31 PM, Anil Aliyan wrote: > > This happens because you smtp service is listening on all ip addresses. If you want to send separate greeting message > individual domains you'll have to configure multiples instances of smtp services for all the domains on your server. I am > not an expert but this my own understanding, I could be wrong. > > Regards, > > Anil Aliyan > > *From:*Edward Finlayson [mailto:edward.finlay...@btinternet.com] > *Sent:* 28 October 2010 16:02 > *To:* qmailtoaster-list@qmailtoaster.com > *Subject:* [qmailtoaster] smtp greeting banner frustration > > Hi Everyone, > > I was wondering if any list member would be able to help. > > I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same > SMTP greeting: > > 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP > > Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com > > Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 > > Any help will be gratefully received, > > Fin > -- best wishes Tony White - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] smtp greeting banner frustration
I am not sure why you would want this configuration though! Surely the idea of virtual domains covers the things you are trying to do? On 28/10/2010 11:25 PM, Edward Finlayson wrote: Hi Tony, This would be true for a single domain, however my setup is more like that below: 127.0.1.1 mail.domina1.com 127.0.1.2 smtp.domain2.co.uk 127.0.8.30 mail.domain30.net 127.0.8.90 mail.domain90.com 127.2.1.112 mx1.domain112.org Obviously, I've obfuscated the real addresses and domains but the layout above is representative. Thanks again Tony, Fin -Original Message- From: Tony White [mailto:t...@ycs.com.au] Sent: 28 October 2010 13:17 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration My first reply does not seem to have arrive so I will try again... If I understand your question it should be as easy as editing the smtpgreeting file to reflect the rDNS value. ie edit /var/qmail.control/smtpgreeting to mail.domain.com On 28/10/2010 10:31 PM, Anil Aliyan wrote: This happens because you smtp service is listening on all ip addresses. If you want to send separate greeting message individual domains you'll have to configure multiples instances of smtp services for all the domains on your server. I am not an expert but this my own understanding, I could be wrong. Regards, Anil Aliyan *From:*Edward Finlayson [mailto:edward.finlay...@btinternet.com] *Sent:* 28 October 2010 16:02 *To:* qmailtoaster-list@qmailtoaster.com *Subject:* [qmailtoaster] smtp greeting banner frustration Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin -- best wishes Tony White Yea Computing Services http://www.ycs.com.au 4 The Crescent Yea Victoria Australia 3717 Telephone No's VIC : 03 5797 3344 VIC : 03 9008 5614 TAS : 03 6107 9099 NT : 08 8921 4049 SA : 08 7123 0847 NSW : 02 8014 5547 QLD : 07 3123 6647 WA : 08 6365 2199 FAX : 03 9008 5610 (FAX2Email) FAX : 03 5797-3288 IMPORTANT NOTICE This communication including any file attachments is intended solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient, or the person responsible for delivering this communication to the intended recipient, please immediately notify the sender by email and delete the original transmission and its contents. Any unauthorised use, dissemination, forwarding, printing or copying of this communication including file attachments is prohibited. It is your responsibility to scan this communication including any file attachments for viruses and other defects. To the extent permitted by law, Yea Computing Services and its associates will not be liable for any loss or damage arising in any way from this communication including any file attachments. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] smtp greeting banner frustration
Well, it is perfectly ok to have the same FQDN listed as MX for several domains. the MX's FQDN does not have to be of the same domain. So, you could greet everyone with the same, valid, FQDN and never worry about the other stuff? Martin -- Martin Waschbüsch IT-Dienstleistungen Lautensackstr. 16 80687 München Telefon: +49 89 57005708 Fax: +49 89 57868023 Mobil: +49 170 2189794 mar...@waschbuesch.de http://martin.waschbuesch.de Am 28.10.2010 um 14:25 schrieb Edward Finlayson: > Hi Tony, > > This would be true for a single domain, however my setup is more like that > below: > > 127.0.1.1 mail.domina1.com > 127.0.1.2 smtp.domain2.co.uk > 127.0.8.30mail.domain30.net > 127.0.8.90mail.domain90.com > 127.2.1.112 mx1.domain112.org > > Obviously, I've obfuscated the real addresses and domains but the layout > above is representative. > > Thanks again Tony, > > Fin > > > -Original Message- > From: Tony White [mailto:t...@ycs.com.au] > Sent: 28 October 2010 13:17 > To: qmailtoaster-list@qmailtoaster.com > Subject: Re: [qmailtoaster] smtp greeting banner frustration > > My first reply does not seem to have arrive so I will try again... > > If I understand your question it should be as easy as > editing the smtpgreeting file to reflect the rDNS value. > > ie edit /var/qmail.control/smtpgreeting to > mail.domain.com > > > > > On 28/10/2010 10:31 PM, Anil Aliyan wrote: >> >> This happens because you smtp service is listening on all ip addresses. If > you want to send separate greeting message >> individual domains you'll have to configure multiples instances of smtp > services for all the domains on your server. I am >> not an expert but this my own understanding, I could be wrong. >> >> Regards, >> >> Anil Aliyan >> >> *From:*Edward Finlayson [mailto:edward.finlay...@btinternet.com] >> *Sent:* 28 October 2010 16:02 >> *To:* qmailtoaster-list@qmailtoaster.com >> *Subject:* [qmailtoaster] smtp greeting banner frustration >> >> Hi Everyone, >> >> I was wondering if any list member would be able to help. >> >> I have a number of domains, on separate IP addresses but whenever a server > connects to the server it receives the same >> SMTP greeting: >> >> 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server > ESMTP >> >> Whereas the hostname should only be the one which reverse resolves in DNS > i.e. mail.domain.com >> >> Does anyone know how I would go about enabling this compliance with RFC821 > 4.3 and RFC2821 4.3.1 >> >> Any help will be gratefully received, >> >> Fin >> > > -- > best wishes > Tony White > > > > > > - > Qmailtoaster is sponsored by Vickers Consulting Group > (www.vickersconsulting.com) >Vickers Consulting Group offers Qmailtoaster support and installations. > If you need professional help with your setup, contact them today! > > - > Please visit qmailtoaster.com for the latest news, updates, and > packages. > > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: > qmailtoaster-list-h...@qmailtoaster.com > > > > - > Qmailtoaster is sponsored by Vickers Consulting Group > (www.vickersconsulting.com) >Vickers Consulting Group offers Qmailtoaster support and installations. > If you need professional help with your setup, contact them today! > - > Please visit qmailtoaster.com for the latest news, updates, and packages. > > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Clamav update trouble
I did the following: [r...@mail ~]# rpm -V perl* package perlpkginstalledviayum is not installed Also: [r...@mail ~]# rpm -qa | grep perl* [r...@mail ~]# It seems non of my perl modules are installed via rpm. Is there an easy way of uninstalling the cpan installed modules and replacing them with the rpm based? Any guidance would be greatly appreciated. Francisco "Paco" Peralta From: Francisco Paco Peralta To: qmailtoaster-list@qmailtoaster.com Sent: Tue, October 26, 2010 10:42:02 AM Subject: Re: [qmailtoaster] Re: Clamav update trouble Well, I won't have to worry about using pastebin, here is the results: [r...@mail ~]# rpm -V perl [r...@mail ~]# Thanks for the help. Francisco "Paco" Peralta From: Steve Huff To: qmailtoaster-list@qmailtoaster.com Sent: Tue, October 26, 2010 9:57:58 AM Subject: Re: [qmailtoaster] Re: Clamav update trouble On Oct 25, 2010, at 5:51 PM, Eric Shubert wrote: > Perhaps a perl expert here (Steve maybe?) might help with how to straighten >things out. I'm not real strong with CPAN. hi! i have been (a bit belatedly) following this thread. Paco, please run `rpm -V perl` (as root) and capture the output. if the output is, say, 10 lines or fewer, then please post it to the list; if it's longer, please stick it up on a pastebin somewhere and send us a link. my first guess as to what is wrong is that by using the CPAN shell you have clobbered some element of the system perl package, and now it is misbehaving. on a system with package management (e.g. RHEL/CentOS, Debian, Ubuntu, Gentoo, Solaris, *BSD, etc.) you should not use the CPAN shell ever, for any reason, at all, no matter what it says in a wiki or a README (and if you know enough to know when you can disregard that statement, more power to you :) ). -shuff -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v PGP 8477B706 (A92A 1F7E 6D76 16A0 BFF9 E61D AD54 0251 8477 B706)
Re: [qmailtoaster] smtp greeting banner frustration
Exactly my point! On 29/10/2010 12:08 AM, Martin Waschbüsch wrote: Well, it is perfectly ok to have the same FQDN listed as MX for several domains. the MX's FQDN does not have to be of the same domain. So, you could greet everyone with the same, valid, FQDN and never worry about the other stuff? Martin -- Martin Waschbüsch IT-Dienstleistungen Lautensackstr. 16 80687 München Telefon: +49 89 57005708 Fax: +49 89 57868023 Mobil: +49 170 2189794 mar...@waschbuesch.de http://martin.waschbuesch.de Am 28.10.2010 um 14:25 schrieb Edward Finlayson: Hi Tony, This would be true for a single domain, however my setup is more like that below: 127.0.1.1 mail.domina1.com 127.0.1.2 smtp.domain2.co.uk 127.0.8.30 mail.domain30.net 127.0.8.90 mail.domain90.com 127.2.1.112 mx1.domain112.org Obviously, I've obfuscated the real addresses and domains but the layout above is representative. Thanks again Tony, Fin -Original Message- From: Tony White [mailto:t...@ycs.com.au] Sent: 28 October 2010 13:17 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration My first reply does not seem to have arrive so I will try again... If I understand your question it should be as easy as editing the smtpgreeting file to reflect the rDNS value. ie edit /var/qmail.control/smtpgreeting to mail.domain.com On 28/10/2010 10:31 PM, Anil Aliyan wrote: This happens because you smtp service is listening on all ip addresses. If you want to send separate greeting message individual domains you'll have to configure multiples instances of smtp services for all the domains on your server. I am not an expert but this my own understanding, I could be wrong. Regards, Anil Aliyan *From:*Edward Finlayson [mailto:edward.finlay...@btinternet.com] *Sent:* 28 October 2010 16:02 *To:* qmailtoaster-list@qmailtoaster.com *Subject:* [qmailtoaster] smtp greeting banner frustration Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin -- best wishes Tony White - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com -- best wishes Tony White Yea Computing Services http://www.ycs.com.au 4 The Crescent Yea Victoria Australia 3717 Telephone No's VIC : 03 5797 3344 VIC : 03 9008 5614 TAS : 03 6107 9099 NT : 08 8921 4049 SA : 08 7123 0847 NSW : 02 8014 5547 QLD : 07 3123 6647 WA : 08 6365 2199 FAX : 03 9008 5610 (FAX2Email) FAX : 03 5797-3288 IMPORTANT NOTICE This communication including any file attachments is intended solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient, or the person responsible for deliver
RE: [qmailtoaster] smtp greeting banner frustration
Hi Martin, Thanks for your response. Unfortunately, I'm unable to have common mx servers. My clients have to have 'isolation' from one another and insist that all their 'servers' are within their own namespace / IP range. This means that I have to have inbound SMTP servers (mx) within the same domain as everything else and that the IPs used for the servers resolve in both directions. This in turn means, of course, that the IPs have to be dedicated to purpose. The knock on effect is that I have to have the SMTP greeting banner for a given IP address match the domain to which it is associated in order to comply fully with the RFCs and best practice. Thanks for your suggestion though, in most other cases I would completely agree, Fin -Original Message- From: Martin Waschbüsch [mailto:mar...@waschbuesch.de] Sent: 28 October 2010 14:08 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration Well, it is perfectly ok to have the same FQDN listed as MX for several domains. the MX's FQDN does not have to be of the same domain. So, you could greet everyone with the same, valid, FQDN and never worry about the other stuff? Martin -- Martin Waschbüsch IT-Dienstleistungen Lautensackstr. 16 80687 München Telefon: +49 89 57005708 Fax: +49 89 57868023 Mobil: +49 170 2189794 mar...@waschbuesch.de http://martin.waschbuesch.de Am 28.10.2010 um 14:25 schrieb Edward Finlayson: > Hi Tony, > > This would be true for a single domain, however my setup is more like that > below: > > 127.0.1.1 mail.domina1.com > 127.0.1.2 smtp.domain2.co.uk > 127.0.8.30mail.domain30.net > 127.0.8.90mail.domain90.com > 127.2.1.112 mx1.domain112.org > > Obviously, I've obfuscated the real addresses and domains but the layout > above is representative. > > Thanks again Tony, > > Fin > > > -Original Message- > From: Tony White [mailto:t...@ycs.com.au] > Sent: 28 October 2010 13:17 > To: qmailtoaster-list@qmailtoaster.com > Subject: Re: [qmailtoaster] smtp greeting banner frustration > > My first reply does not seem to have arrive so I will try again... > > If I understand your question it should be as easy as > editing the smtpgreeting file to reflect the rDNS value. > > ie edit /var/qmail.control/smtpgreeting to > mail.domain.com > > > > > On 28/10/2010 10:31 PM, Anil Aliyan wrote: >> >> This happens because you smtp service is listening on all ip addresses. If > you want to send separate greeting message >> individual domains you'll have to configure multiples instances of smtp > services for all the domains on your server. I am >> not an expert but this my own understanding, I could be wrong. >> >> Regards, >> >> Anil Aliyan >> >> *From:*Edward Finlayson [mailto:edward.finlay...@btinternet.com] >> *Sent:* 28 October 2010 16:02 >> *To:* qmailtoaster-list@qmailtoaster.com >> *Subject:* [qmailtoaster] smtp greeting banner frustration >> >> Hi Everyone, >> >> I was wondering if any list member would be able to help. >> >> I have a number of domains, on separate IP addresses but whenever a server > connects to the server it receives the same >> SMTP greeting: >> >> 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server > ESMTP >> >> Whereas the hostname should only be the one which reverse resolves in DNS > i.e. mail.domain.com >> >> Does anyone know how I would go about enabling this compliance with RFC821 > 4.3 and RFC2821 4.3.1 >> >> Any help will be gratefully received, >> >> Fin >> > > -- > best wishes > Tony White > > > > > > - > Qmailtoaster is sponsored by Vickers Consulting Group > (www.vickersconsulting.com) >Vickers Consulting Group offers Qmailtoaster support and installations. > If you need professional help with your setup, contact them today! > > - > Please visit qmailtoaster.com for the latest news, updates, and > packages. > > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: > qmailtoaster-list-h...@qmailtoaster.com > > > > - > Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) >Vickers Consulting Group offers Qmailtoaster support and installations. > If you need professional help with your setup, contact them today! > - > Please visit qmailtoaster.com for the latest news, updates, and packages. > > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > - Qmailtoaste
Re: [qmailtoaster] smtp greeting banner frustration
Are they not on the same physical box? On 29/10/2010 12:58 AM, Edward Finlayson wrote: Hi Martin, Thanks for your response. Unfortunately, I'm unable to have common mx servers. My clients have to have 'isolation' from one another and insist that all their 'servers' are within their own namespace / IP range. This means that I have to have inbound SMTP servers (mx) within the same domain as everything else and that the IPs used for the servers resolve in both directions. This in turn means, of course, that the IPs have to be dedicated to purpose. The knock on effect is that I have to have the SMTP greeting banner for a given IP address match the domain to which it is associated in order to comply fully with the RFCs and best practice. Thanks for your suggestion though, in most other cases I would completely agree, Fin -Original Message- From: Martin Waschbüsch [mailto:mar...@waschbuesch.de] Sent: 28 October 2010 14:08 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration Well, it is perfectly ok to have the same FQDN listed as MX for several domains. the MX's FQDN does not have to be of the same domain. So, you could greet everyone with the same, valid, FQDN and never worry about the other stuff? Martin -- Martin Waschbüsch IT-Dienstleistungen Lautensackstr. 16 80687 München Telefon: +49 89 57005708 Fax: +49 89 57868023 Mobil: +49 170 2189794 mar...@waschbuesch.de http://martin.waschbuesch.de Am 28.10.2010 um 14:25 schrieb Edward Finlayson: Hi Tony, This would be true for a single domain, however my setup is more like that below: 127.0.1.1 mail.domina1.com 127.0.1.2 smtp.domain2.co.uk 127.0.8.30 mail.domain30.net 127.0.8.90 mail.domain90.com 127.2.1.112 mx1.domain112.org Obviously, I've obfuscated the real addresses and domains but the layout above is representative. Thanks again Tony, Fin -Original Message- From: Tony White [mailto:t...@ycs.com.au] Sent: 28 October 2010 13:17 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration My first reply does not seem to have arrive so I will try again... If I understand your question it should be as easy as editing the smtpgreeting file to reflect the rDNS value. ie edit /var/qmail.control/smtpgreeting to mail.domain.com On 28/10/2010 10:31 PM, Anil Aliyan wrote: This happens because you smtp service is listening on all ip addresses. If you want to send separate greeting message individual domains you'll have to configure multiples instances of smtp services for all the domains on your server. I am not an expert but this my own understanding, I could be wrong. Regards, Anil Aliyan *From:*Edward Finlayson [mailto:edward.finlay...@btinternet.com] *Sent:* 28 October 2010 16:02 *To:* qmailtoaster-list@qmailtoaster.com *Subject:* [qmailtoaster] smtp greeting banner frustration Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin -- best wishes Tony White - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmail
RE: [qmailtoaster] smtp greeting banner frustration
Hi Tony, Yes they are indeed. But they need to appear independently to one-another. Cheers, Fin -Original Message- From: Tony White [mailto:t...@ycs.com.au] Sent: 28 October 2010 15:10 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration Are they not on the same physical box? On 29/10/2010 12:58 AM, Edward Finlayson wrote: > Hi Martin, > > Thanks for your response. > > Unfortunately, I'm unable to have common mx servers. My clients have to have > 'isolation' from one another and insist that all their 'servers' are within > their own namespace / IP range. This means that I have to have inbound SMTP > servers (mx) within the same domain as everything else and that the IPs used > for the servers resolve in both directions. This in turn means, of course, > that the IPs have to be dedicated to purpose. The knock on effect is that I > have to have the SMTP greeting banner for a given IP address match the > domain to which it is associated in order to comply fully with the RFCs and > best practice. > > Thanks for your suggestion though, in most other cases I would completely > agree, > > Fin > > -Original Message- > From: Martin Waschbüsch [mailto:mar...@waschbuesch.de] > Sent: 28 October 2010 14:08 > To: qmailtoaster-list@qmailtoaster.com > Subject: Re: [qmailtoaster] smtp greeting banner frustration > > Well, it is perfectly ok to have the same FQDN listed as MX for several > domains. the MX's FQDN does not have to be of the same domain. > So, you could greet everyone with the same, valid, FQDN and never worry > about the other stuff? > > Martin > > -- > Martin Waschbüsch > IT-Dienstleistungen > Lautensackstr. 16 > 80687 München > > Telefon: +49 89 57005708 > Fax: +49 89 57868023 > Mobil: +49 170 2189794 > mar...@waschbuesch.de > http://martin.waschbuesch.de > > Am 28.10.2010 um 14:25 schrieb Edward Finlayson: > >> Hi Tony, >> >> This would be true for a single domain, however my setup is more like that >> below: >> >> 127.0.1.1mail.domina1.com >> 127.0.1.2smtp.domain2.co.uk >> 127.0.8.30 mail.domain30.net >> 127.0.8.90 mail.domain90.com >> 127.2.1.112 mx1.domain112.org >> >> Obviously, I've obfuscated the real addresses and domains but the layout >> above is representative. >> >> Thanks again Tony, >> >> Fin >> >> >> -Original Message- >> From: Tony White [mailto:t...@ycs.com.au] >> Sent: 28 October 2010 13:17 >> To: qmailtoaster-list@qmailtoaster.com >> Subject: Re: [qmailtoaster] smtp greeting banner frustration >> >> My first reply does not seem to have arrive so I will try again... >> >> If I understand your question it should be as easy as >> editing the smtpgreeting file to reflect the rDNS value. >> >> ie edit /var/qmail.control/smtpgreeting to >> mail.domain.com >> >> >> >> >> On 28/10/2010 10:31 PM, Anil Aliyan wrote: >>> This happens because you smtp service is listening on all ip addresses. > If >> you want to send separate greeting message >>> individual domains you'll have to configure multiples instances of smtp >> services for all the domains on your server. I am >>> not an expert but this my own understanding, I could be wrong. >>> >>> Regards, >>> >>> Anil Aliyan >>> >>> *From:*Edward Finlayson [mailto:edward.finlay...@btinternet.com] >>> *Sent:* 28 October 2010 16:02 >>> *To:* qmailtoaster-list@qmailtoaster.com >>> *Subject:* [qmailtoaster] smtp greeting banner frustration >>> >>> Hi Everyone, >>> >>> I was wondering if any list member would be able to help. >>> >>> I have a number of domains, on separate IP addresses but whenever a > server >> connects to the server it receives the same >>> SMTP greeting: >>> >>> 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server >> ESMTP >>> Whereas the hostname should only be the one which reverse resolves in DNS >> i.e. mail.domain.com >>> Does anyone know how I would go about enabling this compliance with > RFC821 >> 4.3 and RFC2821 4.3.1 >>> Any help will be gratefully received, >>> >>> Fin >>> >> -- >> best wishes >>Tony White >> >> >> >> >> > >> - >> Qmailtoaster is sponsored by Vickers Consulting Group >> (www.vickersconsulting.com) >> Vickers Consulting Group offers Qmailtoaster support and installations. >> If you need professional help with your setup, contact them today! >> > >> - >> Please visit qmailtoaster.com for the latest news, updates, and >> packages. >> >> To unsubscribe, e-mail: > qmailtoaster-list-unsubscr...@qmailtoaster.com >> For additional commands, e-mail: >> qmailtoaster-list-h...@qmailtoaster.com >> >> >> >> > > - >> Qmailtoaster is sponsored by Vickers Consulting Group > (www.vickersconsulting.com) >> Vickers Consulting Group offers Qmailtoaster
Re: [qmailtoaster] smtp greeting banner frustration
What about virtualising each server in its own VMWare space? That way you can guaranteee separation! On 29/10/2010 12:58 AM, Edward Finlayson wrote: Hi Martin, Thanks for your response. Unfortunately, I'm unable to have common mx servers. My clients have to have 'isolation' from one another and insist that all their 'servers' are within their own namespace / IP range. This means that I have to have inbound SMTP servers (mx) within the same domain as everything else and that the IPs used for the servers resolve in both directions. This in turn means, of course, that the IPs have to be dedicated to purpose. The knock on effect is that I have to have the SMTP greeting banner for a given IP address match the domain to which it is associated in order to comply fully with the RFCs and best practice. Thanks for your suggestion though, in most other cases I would completely agree, Fin -Original Message- From: Martin Waschbüsch [mailto:mar...@waschbuesch.de] Sent: 28 October 2010 14:08 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration Well, it is perfectly ok to have the same FQDN listed as MX for several domains. the MX's FQDN does not have to be of the same domain. So, you could greet everyone with the same, valid, FQDN and never worry about the other stuff? Martin -- Martin Waschbüsch IT-Dienstleistungen Lautensackstr. 16 80687 München Telefon: +49 89 57005708 Fax: +49 89 57868023 Mobil: +49 170 2189794 mar...@waschbuesch.de http://martin.waschbuesch.de Am 28.10.2010 um 14:25 schrieb Edward Finlayson: Hi Tony, This would be true for a single domain, however my setup is more like that below: 127.0.1.1 mail.domina1.com 127.0.1.2 smtp.domain2.co.uk 127.0.8.30 mail.domain30.net 127.0.8.90 mail.domain90.com 127.2.1.112 mx1.domain112.org Obviously, I've obfuscated the real addresses and domains but the layout above is representative. Thanks again Tony, Fin -Original Message- From: Tony White [mailto:t...@ycs.com.au] Sent: 28 October 2010 13:17 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration My first reply does not seem to have arrive so I will try again... If I understand your question it should be as easy as editing the smtpgreeting file to reflect the rDNS value. ie edit /var/qmail.control/smtpgreeting to mail.domain.com On 28/10/2010 10:31 PM, Anil Aliyan wrote: This happens because you smtp service is listening on all ip addresses. If you want to send separate greeting message individual domains you'll have to configure multiples instances of smtp services for all the domains on your server. I am not an expert but this my own understanding, I could be wrong. Regards, Anil Aliyan *From:*Edward Finlayson [mailto:edward.finlay...@btinternet.com] *Sent:* 28 October 2010 16:02 *To:* qmailtoaster-list@qmailtoaster.com *Subject:* [qmailtoaster] smtp greeting banner frustration Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin -- best wishes Tony White - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vic
Re: [qmailtoaster] smtp greeting banner frustration
Jake has a VMWare iso and here is a page that might help. http://wiki.qmailtoaster.com/index.php?title=VMware&printable=yes On 29/10/2010 1:12 AM, Edward Finlayson wrote: Hi Tony, Yes they are indeed. But they need to appear independently to one-another. Cheers, Fin -Original Message- From: Tony White [mailto:t...@ycs.com.au] Sent: 28 October 2010 15:10 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration Are they not on the same physical box? On 29/10/2010 12:58 AM, Edward Finlayson wrote: Hi Martin, Thanks for your response. Unfortunately, I'm unable to have common mx servers. My clients have to have 'isolation' from one another and insist that all their 'servers' are within their own namespace / IP range. This means that I have to have inbound SMTP servers (mx) within the same domain as everything else and that the IPs used for the servers resolve in both directions. This in turn means, of course, that the IPs have to be dedicated to purpose. The knock on effect is that I have to have the SMTP greeting banner for a given IP address match the domain to which it is associated in order to comply fully with the RFCs and best practice. Thanks for your suggestion though, in most other cases I would completely agree, Fin -Original Message- From: Martin Waschbüsch [mailto:mar...@waschbuesch.de] Sent: 28 October 2010 14:08 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration Well, it is perfectly ok to have the same FQDN listed as MX for several domains. the MX's FQDN does not have to be of the same domain. So, you could greet everyone with the same, valid, FQDN and never worry about the other stuff? Martin -- Martin Waschbüsch IT-Dienstleistungen Lautensackstr. 16 80687 München Telefon: +49 89 57005708 Fax: +49 89 57868023 Mobil: +49 170 2189794 mar...@waschbuesch.de http://martin.waschbuesch.de Am 28.10.2010 um 14:25 schrieb Edward Finlayson: Hi Tony, This would be true for a single domain, however my setup is more like that below: 127.0.1.1 mail.domina1.com 127.0.1.2 smtp.domain2.co.uk 127.0.8.30 mail.domain30.net 127.0.8.90 mail.domain90.com 127.2.1.112 mx1.domain112.org Obviously, I've obfuscated the real addresses and domains but the layout above is representative. Thanks again Tony, Fin -Original Message- From: Tony White [mailto:t...@ycs.com.au] Sent: 28 October 2010 13:17 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration My first reply does not seem to have arrive so I will try again... If I understand your question it should be as easy as editing the smtpgreeting file to reflect the rDNS value. ie edit /var/qmail.control/smtpgreeting to mail.domain.com On 28/10/2010 10:31 PM, Anil Aliyan wrote: This happens because you smtp service is listening on all ip addresses. If you want to send separate greeting message individual domains you'll have to configure multiples instances of smtp services for all the domains on your server. I am not an expert but this my own understanding, I could be wrong. Regards, Anil Aliyan *From:*Edward Finlayson [mailto:edward.finlay...@btinternet.com] *Sent:* 28 October 2010 16:02 *To:* qmailtoaster-list@qmailtoaster.com *Subject:* [qmailtoaster] smtp greeting banner frustration Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin -- best wishes Tony White - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! --
[qmailtoaster] Re: Clamav update trouble
You should do: # rpm -qa | grep ^perl to see which perl packages are installed. You must have some. Your rpm -V command isn't quite right either, but I don't think we really need to do that. I don't know about removing CPAN modules. Steve, would that really be necessary? You wouldn't want to go too far in that direction, because you might cripple yum in the process. I'd simply try installing the perl packages you're missing with yum. Here are the perl packages I have on my QMT: perl-5.8.8-27.el5 perl-Archive-Tar-1.30-1.fc6 perl-Compress-Raw-Zlib-2.003-1.el5.rf perl-Compress-Zlib-1.42-1.fc6 perl-Crypt-OpenSSL-Bignum-0.04-1.el5.rf perl-Crypt-OpenSSL-RSA-0.25-1.el5.rf perl-DBD-MySQL-3.0007-2.el5 perl-DBI-1.52-2.el5 perl-Digest-HMAC-1.01-15 perl-Digest-SHA1-2.11-1.2.1 perl-Digest-SHA-5.45-1.el5.rf perl-Encode-Detect-1.01-1.el5.rf perl-Error-0.17012-1.el5.rf perl-Geography-Countries-1.4-2.2.el5.rf perl-HTML-Parser-3.55-1.fc6 perl-HTML-Tagset-3.10-2.1.1 perl-IO-Compress-Base-2.003-1.el5.rf perl-IO-Compress-Zlib-2.003-1.el5.rf perl-IO-Socket-INET6-2.51-2.fc6 perl-IO-Socket-SSL-1.01-1.fc6 perl-IO-Zlib-1.04-4.2.1 perl-IP-Country-2.24-1.el5.rf perl-libwww-perl-5.805-1.1.1 perl-Mail-DKIM-0.30.1-1.el5.rf perl-Mail-DomainKeys-1.0-1.el5.rf perl-Mail-SPF-2.005-1.el5.rf perl-Mail-SPF-Query-1.999.1-2.el5.rf perl-MailTools-2.02-1.el5.rf perl-NetAddr-IP-4.007-1.el5.rf perl-Net-CIDR-0.10-8 perl-Net-CIDR-Lite-0.15-8 perl-Net-DNS-0.59-3.el5 perl-Net-Ident-1.20-1.2.el5.rf perl-Net-IP-1.25-2.fc6 perl-Net-SSLeay-1.30-4.fc6 perl-Razor-Agent-2.84-1.el5.rf perl-rrdtool-1.4.2-1.el5.rf perl-Socket6-0.19-3.fc6 perl-String-CRC32-1.4-2.fc6 perl-Sys-Hostname-Long-1.2-8 perl-TimeDate-1.16-5.el5 perl-URI-1.35-3 perl-version-0.74-1.el5.rf Since you've updated recently, you should already have the rpmforge repo installed, but it probably is not enabled. Your yum command should look like this: # yum --enablerepo=rpmforge install perl perl-Archive-Tar (...) Use each package name that you're missing, short of the version stuff. I expect that will take care of things. Please report back your results. -- -Eric 'shubes' On 10/28/2010 06:27 AM, Francisco Paco Peralta wrote: I did the following: [r...@mail ~]# rpm -V perl* package perlpkginstalledviayum is not installed Also: [r...@mail ~]# rpm -qa | grep perl* [r...@mail ~]# It seems non of my perl modules are installed via rpm. Is there an easy way of uninstalling the cpan installed modules and replacing them with the rpm based? Any guidance would be greatly appreciated. Francisco "Paco" Peralta *From:* Francisco Paco Peralta *To:* qmailtoaster-list@qmailtoaster.com *Sent:* Tue, October 26, 2010 10:42:02 AM *Subject:* Re: [qmailtoaster] Re: Clamav update trouble Well, I won't have to worry about using pastebin, here is the results: [r...@mail ~]# rpm -V perl [r...@mail ~]# Thanks for the help. Francisco "Paco" Peralta *From:* Steve Huff *To:* qmailtoaster-list@qmailtoaster.com *Sent:* Tue, October 26, 2010 9:57:58 AM *Subjec t:* Re: [qmailtoaster] Re: Clamav update trouble On Oct 25, 2010, at 5:51 PM, Eric Shubert wrote: > Perhaps a perl expert here (Steve maybe?) might help with how to straighten things out. I'm not real strong with CPAN. hi! i have been (a bit belatedly) following this thread. Paco, please run `rpm -V perl` (as root) and capture the output. if the output is, say, 10 lines or fewer, then please post it to the list; if it's longer, please stick it up on a pastebin somewhere and send us a link. my first guess as to what is wrong is that by using the CPAN shell you have clobbered some element of the system perl package, and now it is misbehaving. on a system with package management (e.g. RHEL/CentOS, Debian, Ubuntu, Gentoo, Solaris, *BSD, etc.) you should not use the CPAN shell ever, fo r any reason, at all, no matter what it says in a wiki or a README (and if you know enough to know when you can disregard that statement, more power to you :) ). -shuff -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v PGP 8477B706 (A92A 1F7E 6D76 16A0 BFF9 E61D AD54 0251 8477 B706) - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: qtp-newmodel failure
qtp-newmodel invokes teh qtp-build-sandbox script, which should take care of installing all the packages (including fuse) that you need. What versions are you running? # rpm -qa | grep toaster # qtp-whatami I might not have the latest fuse packages in the repo yet. -- -Eric 'shubes' On 10/28/2010 01:34 AM, Maxwell Smart wrote: I have a fresh install of the QMTISO with yum updates completed and qtp installed. I tried to update the toaster using the newmodel and got this error. Would you like a unionfs/overlay sandbox? (recommended) [y]/n: Using FUSE union filesystem ... qtp-mount-sandbox v0.3.3 qtp-mount-sandbox - updating dependencies ... Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons: mirror.san.fastserv.com * base: centos.promopeddler.com * extras: mirror.hmc.edu * rpmforge: apt.sw.be * updates: mirrors.cat.pdx.edu Setting up Update Process No Packages marked for Update fuse: device not found, try 'modprobe fuse' first FATAL: Module fuse not found. fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first fuse: device not found, try 'modprobe fuse' first mount: mount point /mnt/qtp-sandbox/var/lib/rpm does not exist cp: target `/mnt/qtp-sandbox/var/lib/rpm' is not a directory qtp-mount-sandbox: sandbox was not mounted successfully qtp-newmodel - qtp-mount-sandbox failed, exiting # modprobe fuse FATAL: Module fuse not found. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: Qmail & Ical server invitation reply
On 10/28/2010 01:52 AM, Davide Enrico Bovolenta wrote: Problem: manage replay to invitations managed from iCal server ( the syntax of responses is Using postfix the solution is set the recipient_delimiter = + There is a similar solution with qmail? Thanks. QMT (and qmail in general) uses - (dash/minus) as the delimiter. Can ical use this instead of + ? That would seem to be the simplest solution. Otherwise, I think you would need to modify the qmail source code, as there's no run time configuration parameter for this that I know of. -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: smtp greeting banner frustration
On 10/28/2010 03:31 AM, Edward Finlayson wrote: Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Not exactly true. Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin What RFC 2821 says is this: " An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only." So you see, the name in the EHLO message merely needs to be resolvable. Change the name in your /var/qmail/control/smtpgreeting file to be any one of your valid hosts (an MX name is good), and you should have no problem. -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: smtp greeting banner frustration
On 10/28/2010 06:58 AM, Edward Finlayson wrote: Hi Martin, Thanks for your response. Unfortunately, I'm unable to have common mx servers. My clients have to have 'isolation' from one another and insist that all their 'servers' are within their own namespace / IP range. This means that I have to have inbound SMTP servers (mx) within the same domain as everything else and that the IPs used for the servers resolve in both directions. This in turn means, of course, that the IPs have to be dedicated to purpose. The knock on effect is that I have to have the SMTP greeting banner for a given IP address match the domain to which it is associated in order to comply fully with the RFCs and best practice. This is simply not true. See my previous post on RFC2821. -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] smtp greeting banner frustration
Il 28/10/2010 15:58, Edward Finlayson ha scritto: Hi Martin, Thanks for your response. Unfortunately, I'm unable to have common mx servers. My clients have to have 'isolation' from one another and insist that all their 'servers' are within their own namespace / IP range. This means that I have to have inbound SMTP servers (mx) within the same domain as everything else and that the IPs used for the servers resolve in both directions. This in turn means, of course, that the IPs have to be dedicated to purpose. The knock on effect is that I have to have the SMTP greeting banner for a given IP address match the domain to which it is associated in order to comply fully with the RFCs and best practice. I don't understand such problem. Unless customers want specific logs, because each one of them want to access his own logs as they like, there is no reason to have different MX and different senders. Could again make sense if you give different bandwith to different IPs. If you have different IP, but unique log, same shared bandwith, it has no sense. If you want different IP, different logs, dedicated bandwith, you must setup one qmail environment for each customer. Regards, Tonino Thanks for your suggestion though, in most other cases I would completely agree, Fin -Original Message- From: Martin Waschbüsch [mailto:mar...@waschbuesch.de] Sent: 28 October 2010 14:08 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration Well, it is perfectly ok to have the same FQDN listed as MX for several domains. the MX's FQDN does not have to be of the same domain. So, you could greet everyone with the same, valid, FQDN and never worry about the other stuff? Martin -- Martin Waschbüsch IT-Dienstleistungen Lautensackstr. 16 80687 München Telefon: +49 89 57005708 Fax: +49 89 57868023 Mobil: +49 170 2189794 mar...@waschbuesch.de http://martin.waschbuesch.de Am 28.10.2010 um 14:25 schrieb Edward Finlayson: Hi Tony, This would be true for a single domain, however my setup is more like that below: 127.0.1.1 mail.domina1.com 127.0.1.2 smtp.domain2.co.uk 127.0.8.30 mail.domain30.net 127.0.8.90 mail.domain90.com 127.2.1.112 mx1.domain112.org Obviously, I've obfuscated the real addresses and domains but the layout above is representative. Thanks again Tony, Fin -Original Message- From: Tony White [mailto:t...@ycs.com.au] Sent: 28 October 2010 13:17 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration My first reply does not seem to have arrive so I will try again... If I understand your question it should be as easy as editing the smtpgreeting file to reflect the rDNS value. ie edit /var/qmail.control/smtpgreeting to mail.domain.com On 28/10/2010 10:31 PM, Anil Aliyan wrote: This happens because you smtp service is listening on all ip addresses. If you want to send separate greeting message individual domains you'll have to configure multiples instances of smtp services for all the domains on your server. I am not an expert but this my own understanding, I could be wrong. Regards, Anil Aliyan *From:*Edward Finlayson [mailto:edward.finlay...@btinternet.com] *Sent:* 28 October 2010 16:02 *To:* qmailtoaster-list@qmailtoaster.com *Subject:* [qmailtoaster] smtp greeting banner frustration Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin -- best wishes Tony White - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! --
Re: [qmailtoaster] Re: qtp-newmodel failure
[r...@viktorya ~]# rpm -qa | grep toaster qmail-toaster-1.03-1.3.15 maildrop-toaster-devel-2.0.3-1.3.5 vpopmail-toaster-5.4.17-1.3.4 ezmlm-toaster-0.53.324-1.3.3 squirrelmail-toaster-1.4.15-1.3.10 libdomainkeys-toaster-0.68-1.3.3 courier-authlib-toaster-0.59.2-1.3.6 control-panel-toaster-0.5-1.3.4 qmailmrtg-toaster-4.2-1.3.3 vqadmin-toaster-2.3.4-1.3.3 ripmime-toaster-1.4.0.6-1.3.3 daemontools-toaster-0.76-1.3.3 libsrs2-toaster-1.0.18-1.3.3 courier-imap-toaster-4.1.2-1.3.7 qmailadmin-toaster-1.2.11-1.3.4 isoqlog-toaster-2.1-1.3.4 clamav-toaster-0.94-1.3.21 qmailtoaster-plus-0.3.2-1.4.16 ucspi-tcp-toaster-0.88-1.3.5 autorespond-toaster-2.0.4-1.3.3 ezmlm-cgi-toaster-0.53.324-1.3.3 spamassassin-toaster-3.2.5-1.3.14 qmail-pop3d-toaster-1.03-1.3.15 maildrop-toaster-2.0.3-1.3.5 simscan-toaster-1.3.1-1.3.6 qmailtoaster-plus.repo-0.2-2 qtp-whatami v0.3.7 Thu Oct 28 09:00:23 PDT 2010 DISTRO=CentOS OSVER=5.5 QTARCH=i686 QTKERN=2.6.18-92.1.13.el5 BUILD_DIST=cnt50 BUILD_DIR=/usr/src/redhat This machine's OS is supported and has been tested On 10/28/2010 08:03 AM, Eric Shubert wrote: rpm -qa | grep toaster -- Cecil Yother, Jr. "cj" cj's 2318 Clement Ave Alameda, CA 94501 tel 510.865.2787 http://yother.com Check out the new Volvo classified resource http://www.volvoclassified.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: qtp-newmodel failure
You're not running the latest kernel that you have installed. You need to reboot after upgrading the kernel package. Try rebooting, and run qtp-newmodel again. -- -Eric 'shubes' On 10/28/2010 10:00 AM, Maxwell Smart wrote: [r...@viktorya ~]# rpm -qa | grep toaster qmail-toaster-1.03-1.3.15 maildrop-toaster-devel-2.0.3-1.3.5 vpopmail-toaster-5.4.17-1.3.4 ezmlm-toaster-0.53.324-1.3.3 squirrelmail-toaster-1.4.15-1.3.10 libdomainkeys-toaster-0.68-1.3.3 courier-authlib-toaster-0.59.2-1.3.6 control-panel-toaster-0.5-1.3.4 qmailmrtg-toaster-4.2-1.3.3 vqadmin-toaster-2.3.4-1.3.3 ripmime-toaster-1.4.0.6-1.3.3 daemontools-toaster-0.76-1.3.3 libsrs2-toaster-1.0.18-1.3.3 courier-imap-toaster-4.1.2-1.3.7 qmailadmin-toaster-1.2.11-1.3.4 isoqlog-toaster-2.1-1.3.4 clamav-toaster-0.94-1.3.21 qmailtoaster-plus-0.3.2-1.4.16 ucspi-tcp-toaster-0.88-1.3.5 autorespond-toaster-2.0.4-1.3.3 ezmlm-cgi-toaster-0.53.324-1.3.3 spamassassin-toaster-3.2.5-1.3.14 qmail-pop3d-toaster-1.03-1.3.15 maildrop-toaster-2.0.3-1.3.5 simscan-toaster-1.3.1-1.3.6 qmailtoaster-plus.repo-0.2-2 qtp-whatami v0.3.7 Thu Oct 28 09:00:23 PDT 2010 DISTRO=CentOS OSVER=5.5 QTARCH=i686 QTKERN=2.6.18-92.1.13.el5 BUILD_DIST=cnt50 BUILD_DIR=/usr/src/redhat This machine's OS is supported and has been tested On 10/28/2010 08:03 AM, Eric Shubert wrote: rpm -qa | grep toaster - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
RE: [qmailtoaster] Re: smtp greeting banner frustration
Hi Eric, Please don't take this the wrong way but we appear to be talking at cross purposes. You reference the EHLO string which is of course the outbound string, used to identify a server to the recipient host. I am referring to the SMTP Greeting String used to identify the local Receiving sever to the remotely connecting sending server. It is also called the SMTP Banner depending upon the tech used. The EHLO String, in operational terms, has to be both correctly authorised for the sending domain (present in SPF and/or listed as an MX server) and reverse resolvable to the same FQDN. I agree that this is not in the RFCs but it is certainly affecting sending reputation when this is not the case. Therefore the sending 'servers' for a given domain, if they are themselves within that domain, in practical terms, must forward and reverse resolve mirroring each other and offer both the correct banner greeting EHLO and SMTP Greeting in order to be considered complete within the domain space itself. I am not saying that my requirement is either right or wrong; workable, practical or even sensible. I concur that the vast majority of clients, my own included, would never even look at these factors, let alone understand them. However I have to get this resolved in order to eliminate the perceived 'issue'. This is a classic case of business requirement over practicality. I fully agree with all that has been said with regard to what is possible. However, I simply have a requirement to be a able to prove isolation of domains for my clients. Therefore, I have to support what 'should' be possible i.e. dedicated IP addresses within a name space and the correct identification of servers at an 'operational level'. This means that I have to have the correct SMTP greeting for incoming connections. Outbound are in fact already supported on the system in question via domain dependant EHLO strings. With regard to your comment re the RFCs, yes I aware of what they state (otherwise, wouldn't have quoted them myself). However, as these are only 'guidelines' according to Hotmail, Yahoo, Google et al and each tend to selectively choose which and how to implement them; it is better therefore to comply as much as possible. to that end RFC821 4.3 specifically states: 4.3. SEQUENCING OF COMMANDS AND REPLIES The communication between the sender and receiver is intended to be an alternating dialogue, controlled by the sender. As such, the sender issues a command and the receiver responds with a reply. The sender must wait for this response before sending further commands. One important reply is the connection greeting. Normally, a receiver will send a 220 "Service ready" reply when the connection is completed. The sender should wait for this greeting message before sending any commands. Note: all the greeting type replies have the official name of the server host as the first word following the reply code. For example, 220 USC-ISIF.ARPA Service ready And RFC2821 4.3.1 details: Note: all the greeting-type replies have the official name (the fully-qualified primary domain name) of the server host as the first word following the reply code. Sometimes the host will have no meaningful name. ... For example, 220 ISIF.USC.EDU Service ready or 220 mail.foo.com SuperSMTP v 6.1.2 Service ready ... It is for this reason that I have found myself having to look for a way to implement this and installation of separate machines is not financially feasible. Please note that I am discussing the SMTP Greeting String here not the EHLO string. My core problem is that this is stupidly simple for my clients to prove out, as they are using DNSStuff.com for validation of configuration and this is the last item that is being highlighted as an 'issue' for them. Sorry if this mail is a bit long and tiresome, it reflects my own frustration with the situation. Regards to all, Fin -Original Message- From: Eric Shubert [mailto:e...@shubes.net] Sent: 28 October 2010 16:36 To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Re: smtp greeting banner frustration On 10/28/2010 06:58 AM, Edward Finlayson wrote: > Hi Martin, > > Thanks for your response. > > Unfortunately, I'm unable to have common mx servers. My clients have to have > 'isolation' from one another and insist that all their 'servers' are within > their own namespace / IP range. This means that I have to have inbound SMTP > servers (mx) within the same domain as everything else and that the IPs used > for the servers resolve in both directions. This in turn means, of course, > that the IPs have to be dedicated to purpose. The knock on effect is that I > have to have the SMTP greeting banner for a given IP address match the > domain to which it is associated in order to comply fully with the RFCs and > best practice. > This is simply not true. Se
RE: [qmailtoaster] smtp greeting banner frustration
Hi everyone, Thanks to all for your input and help in this irksome matter. If it weren't for the relative importance of these clients I wouldn't have gone to these lengths myself. To that end I will have to take the best advice offered to date and install multiple SMTP daemons; each monitoring their own IP addresses. Thereby getting over the 'issue'. Thanks again for the input, Fin -Original Message- From: Tonix (Antonio Nati) [mailto:to...@interazioni.it] Sent: 28 October 2010 16:54 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration Il 28/10/2010 15:58, Edward Finlayson ha scritto: > Hi Martin, > > Thanks for your response. > > Unfortunately, I'm unable to have common mx servers. My clients have to have > 'isolation' from one another and insist that all their 'servers' are within > their own namespace / IP range. This means that I have to have inbound SMTP > servers (mx) within the same domain as everything else and that the IPs used > for the servers resolve in both directions. This in turn means, of course, > that the IPs have to be dedicated to purpose. The knock on effect is that I > have to have the SMTP greeting banner for a given IP address match the > domain to which it is associated in order to comply fully with the RFCs and > best practice. > I don't understand such problem. Unless customers want specific logs, because each one of them want to access his own logs as they like, there is no reason to have different MX and different senders. Could again make sense if you give different bandwith to different IPs. If you have different IP, but unique log, same shared bandwith, it has no sense. If you want different IP, different logs, dedicated bandwith, you must setup one qmail environment for each customer. Regards, Tonino > Thanks for your suggestion though, in most other cases I would completely > agree, > > Fin > > -Original Message- > From: Martin Waschbüsch [mailto:mar...@waschbuesch.de] > Sent: 28 October 2010 14:08 > To: qmailtoaster-list@qmailtoaster.com > Subject: Re: [qmailtoaster] smtp greeting banner frustration > > Well, it is perfectly ok to have the same FQDN listed as MX for several > domains. the MX's FQDN does not have to be of the same domain. > So, you could greet everyone with the same, valid, FQDN and never worry > about the other stuff? > > Martin > > -- > Martin Waschbüsch > IT-Dienstleistungen > Lautensackstr. 16 > 80687 München > > Telefon: +49 89 57005708 > Fax: +49 89 57868023 > Mobil: +49 170 2189794 > mar...@waschbuesch.de > http://martin.waschbuesch.de > > Am 28.10.2010 um 14:25 schrieb Edward Finlayson: > >> Hi Tony, >> >> This would be true for a single domain, however my setup is more like that >> below: >> >> 127.0.1.1mail.domina1.com >> 127.0.1.2smtp.domain2.co.uk >> 127.0.8.30 mail.domain30.net >> 127.0.8.90 mail.domain90.com >> 127.2.1.112 mx1.domain112.org >> >> Obviously, I've obfuscated the real addresses and domains but the layout >> above is representative. >> >> Thanks again Tony, >> >> Fin >> >> >> -Original Message- >> From: Tony White [mailto:t...@ycs.com.au] >> Sent: 28 October 2010 13:17 >> To: qmailtoaster-list@qmailtoaster.com >> Subject: Re: [qmailtoaster] smtp greeting banner frustration >> >> My first reply does not seem to have arrive so I will try again... >> >> If I understand your question it should be as easy as >> editing the smtpgreeting file to reflect the rDNS value. >> >> ie edit /var/qmail.control/smtpgreeting to >> mail.domain.com >> >> >> >> >> On 28/10/2010 10:31 PM, Anil Aliyan wrote: >>> This happens because you smtp service is listening on all ip addresses. > If >> you want to send separate greeting message >>> individual domains you'll have to configure multiples instances of smtp >> services for all the domains on your server. I am >>> not an expert but this my own understanding, I could be wrong. >>> >>> Regards, >>> >>> Anil Aliyan >>> >>> *From:*Edward Finlayson [mailto:edward.finlay...@btinternet.com] >>> *Sent:* 28 October 2010 16:02 >>> *To:* qmailtoaster-list@qmailtoaster.com >>> *Subject:* [qmailtoaster] smtp greeting banner frustration >>> >>> Hi Everyone, >>> >>> I was wondering if any list member would be able to help. >>> >>> I have a number of domains, on separate IP addresses but whenever a > server >> connects to the server it receives the same >>> SMTP greeting: >>> >>> 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server >> ESMTP >>> Whereas the hostname should only be the one which reverse resolves in DNS >> i.e. mail.domain.com >>> Does anyone know how I would go about enabling this compliance with > RFC821 >> 4.3 and RFC2821 4.3.1 >>> Any help will be gratefully received, >>> >>> Fin >>> >> -- >> best wishes >>Tony White >> >> >> >> >> > >> - >> Qmailtoaster is sponsored by Vickers Consulting Group >> (
Re: [qmailtoaster] Re: smtp greeting banner frustration
> Hi Eric, > > Please don't take this the wrong way but we appear to be talking at cross > purposes. You reference the EHLO string which is of course the outbound > string, used to identify a server to the recipient host. I am referring to > the SMTP Greeting String used to identify the local Receiving sever to the > remotely connecting sending server. It is also called the SMTP Banner > depending upon the tech used. The EHLO String, in operational terms, has to > be both correctly authorised for the sending domain (present in SPF and/or > listed as an MX server) and reverse resolvable to the same FQDN. I agree > that this is not in the RFCs but it is certainly affecting sending > reputation when this is not the case. Therefore the sending 'servers' for a > given domain, if they are themselves within that domain, in practical terms, > must forward and reverse resolve mirroring each other and offer both the > correct banner greeting EHLO and SMTP Greeting in order to be considered > complete within the domain space itself. > See, that is what I don't understand. Imagine you have three domains, domain1/2/3.tld. all of them could have an MX entry like this: IN MX 10 server.yetanotherdomain.org and that would be 100% correct and compliant with the RFCs. You can then add the IP of that server to those domains SPF record, add domainkeys and whatnot. IF any receiving mail server has a problem with server.yetanotherdomain.org sending in the name of either of your three domains, then I would argue that that receiving mail server does not conform to the RFCs in question. Granted, if, for any reason, someone explicitly wants that sort of setup where the MX for domain1.tld is of that domain, then that is a different story. But that is just a (valid) subset of the more generic (also 100% valid) way this can be implemented. So, I guess it really comes down to a decision of: Do you want to comply with the, let's say "not really necessary, but of course valid" request of your clients or do you fall back on the more generic way the RFCs specify how mail works? Or in other words: To my knowledge, there is nothing in the RFCs that prevents you from doing what I described above. Of course, it's still your choice. Martin - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: qtp-newmodel failure
OK, will do. On 10/28/2010 09:21 AM, Eric Shubert wrote: You're not running the latest kernel that you have installed. You need to reboot after upgrading the kernel package. Try rebooting, and run qtp-newmodel again. -- Cecil Yother, Jr. "cj" cj's 2318 Clement Ave Alameda, CA 94501 tel 510.865.2787 http://yother.com Check out the new Volvo classified resource http://www.volvoclassified.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
RE: [qmailtoaster] Re: smtp greeting banner frustration
Hi again Martin, Indeed they could, and I would advocate this very approach myself. However, at the risk of sounding like a broken record: a typical domain that I MUST be able to prove to these clients would look this the DNS snippet below: ## # == mydomain.co.uk =# ## # Name server records for domain # The format used here does NOT create A or SOA records but does NS Zmydomain.co.uk:ns1.mydomain.co.uk:hostmaster.mydomain.co.uk:2010030401:3600 :1800:1209600:2560 &mydomain.co.uk::ns1.mydomain.co.uk &mydomain.co.uk::ns2.mydomain.co.uk &mydomain.co.uk::ns3.mydomain.co.uk # Mail exchanger data for domain @mydomain.co.uk::mail.mydomain.co.uk.:10:3600 ^104.1.1.127.in-addr.arpa:mail.mydomain.co.uk.:3600 # Alias Records For The Domain +mydomain.co.uk:127.1.1.157:86400 +ftp.mydomain.co.uk:127.1.1.157:86400 +www.mydomain.co.uk:127.1.1.157:86400 +mail.mydomain.co.uk:127.1.1.104:1800 +ns1.mydomain.co.uk.:127.1.1.161:3600 +ns2.mydomain.co.uk.:127.1.1.187:3600 +ns3.mydomain.co.uk.:10.1.1.187:3600 # TYPE 99 SPF # In the record below '\65' is an octal 'byte' representing the length of the string between and including 'v=...' and '...-all:':mydomain.co.uk:99:\65v=spf1 a mx ptr mx\072mail.mydomain.co.uk -all:3600 'mydomain.co.uk:v=spf1 a mx ptr mx\072mail.mydomain.co.uk -all 'mydomain.co.uk:v=spf2.0/pra mx mx\072mail.mydomain.co.uk -all As can be seen from the above all the mail service for this domain are within the domain itself, and it is this very format the I must prove to the client via DNSStuff.com which additionally checks the SMTP Greeting banner. Which in turn is WHY I need to have this set to the corresponding value from above before my clients will sign off. Regards, Fin -Original Message- From: Martin Waschbüsch [mailto:mar...@waschbuesch.de] Sent: 28 October 2010 17:46 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Re: smtp greeting banner frustration > Hi Eric, > > Please don't take this the wrong way but we appear to be talking at cross > purposes. You reference the EHLO string which is of course the outbound > string, used to identify a server to the recipient host. I am referring to > the SMTP Greeting String used to identify the local Receiving sever to the > remotely connecting sending server. It is also called the SMTP Banner > depending upon the tech used. The EHLO String, in operational terms, has to > be both correctly authorised for the sending domain (present in SPF and/or > listed as an MX server) and reverse resolvable to the same FQDN. I agree > that this is not in the RFCs but it is certainly affecting sending > reputation when this is not the case. Therefore the sending 'servers' for a > given domain, if they are themselves within that domain, in practical terms, > must forward and reverse resolve mirroring each other and offer both the > correct banner greeting EHLO and SMTP Greeting in order to be considered > complete within the domain space itself. > See, that is what I don't understand. Imagine you have three domains, domain1/2/3.tld. all of them could have an MX entry like this: IN MX 10 server.yetanotherdomain.org and that would be 100% correct and compliant with the RFCs. You can then add the IP of that server to those domains SPF record, add domainkeys and whatnot. IF any receiving mail server has a problem with server.yetanotherdomain.org sending in the name of either of your three domains, then I would argue that that receiving mail server does not conform to the RFCs in question. Granted, if, for any reason, someone explicitly wants that sort of setup where the MX for domain1.tld is of that domain, then that is a different story. But that is just a (valid) subset of the more generic (also 100% valid) way this can be implemented. So, I guess it really comes down to a decision of: Do you want to comply with the, let's say "not really necessary, but of course valid" request of your clients or do you fall back on the more generic way the RFCs specify how mail works? Or in other words: To my knowledge, there is nothing in the RFCs that prevents you from doing what I described above. Of course, it's still your choice. Martin - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] smtp greeting banner frustration
Edward, I'm just trying to understand others needs. As I am an ISP, I could be I'm missing something important for my customers too. How is it possible to speak about isolation level, when all logs are mixed together? The same about sending queue. All customers are using a single output queue, so how can we speak about isolation when a huge sending of one customer can afflict all others? Am I missing something? It it only a "cosmetic" issue? Cheers, Tonino Il 28/10/2010 17:54, Tonix (Antonio Nati) ha scritto: Il 28/10/2010 15:58, Edward Finlayson ha scritto: Hi Martin, Thanks for your response. Unfortunately, I'm unable to have common mx servers. My clients have to have 'isolation' from one another and insist that all their 'servers' are within their own namespace / IP range. This means that I have to have inbound SMTP servers (mx) within the same domain as everything else and that the IPs used for the servers resolve in both directions. This in turn means, of course, that the IPs have to be dedicated to purpose. The knock on effect is that I have to have the SMTP greeting banner for a given IP address match the domain to which it is associated in order to comply fully with the RFCs and best practice. I don't understand such problem. Unless customers want specific logs, because each one of them want to access his own logs as they like, there is no reason to have different MX and different senders. Could again make sense if you give different bandwith to different IPs. If you have different IP, but unique log, same shared bandwith, it has no sense. If you want different IP, different logs, dedicated bandwith, you must setup one qmail environment for each customer. Regards, Tonino Thanks for your suggestion though, in most other cases I would completely agree, Fin -Original Message- From: Martin Waschbüsch [mailto:mar...@waschbuesch.de] Sent: 28 October 2010 14:08 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration Well, it is perfectly ok to have the same FQDN listed as MX for several domains. the MX's FQDN does not have to be of the same domain. So, you could greet everyone with the same, valid, FQDN and never worry about the other stuff? Martin -- Martin Waschbüsch IT-Dienstleistungen Lautensackstr. 16 80687 München Telefon: +49 89 57005708 Fax: +49 89 57868023 Mobil: +49 170 2189794 mar...@waschbuesch.de http://martin.waschbuesch.de Am 28.10.2010 um 14:25 schrieb Edward Finlayson: Hi Tony, This would be true for a single domain, however my setup is more like that below: 127.0.1.1mail.domina1.com 127.0.1.2smtp.domain2.co.uk 127.0.8.30mail.domain30.net 127.0.8.90mail.domain90.com 127.2.1.112mx1.domain112.org Obviously, I've obfuscated the real addresses and domains but the layout above is representative. Thanks again Tony, Fin -Original Message- From: Tony White [mailto:t...@ycs.com.au] Sent: 28 October 2010 13:17 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration My first reply does not seem to have arrive so I will try again... If I understand your question it should be as easy as editing the smtpgreeting file to reflect the rDNS value. ie edit /var/qmail.control/smtpgreeting to mail.domain.com On 28/10/2010 10:31 PM, Anil Aliyan wrote: This happens because you smtp service is listening on all ip addresses. If you want to send separate greeting message individual domains you'll have to configure multiples instances of smtp services for all the domains on your server. I am not an expert but this my own understanding, I could be wrong. Regards, Anil Aliyan *From:*Edward Finlayson [mailto:edward.finlay...@btinternet.com] *Sent:* 28 October 2010 16:02 *To:* qmailtoaster-list@qmailtoaster.com *Subject:* [qmailtoaster] smtp greeting banner frustration Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin -- best wishes Tony White - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubs
RE: [qmailtoaster] smtp greeting banner frustration
Hi Tonino, Sorry if the thread seems to be talking about different issues, but it is primarily a cosmetic issue but my clients are insistent on this perceived isolation, the logs and the outbound queues are also split by client domain after application of an in house patch. To this end there is a level of separation of outbound mail. It is sent on the IP, using the correct EHLO string, but inbound is still using a common SMTP Greeting Banner despite being contacted on the correct IPs. I cannot use a common outbound IP as this mixes the reputation of the sending domains into one based upon said IP, and my clients are using this service for transactional mailings so virtually demand independent reputation. The inbound server is primarily cosmetic, but is checked by the tool that they are using for verification, and is being flagged as a warning for not being compliant with RFC2821 specifically point 4.3.1 by issuing a SMTP greeting that corresponds to the FQDN of the host which is being connected to. I hope this clears up my dilemma and doesn't cause any confusion, Fin -Original Message- From: Tonix (Antonio Nati) [mailto:to...@interazioni.it] Sent: 28 October 2010 18:11 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration Edward, I'm just trying to understand others needs. As I am an ISP, I could be I'm missing something important for my customers too. How is it possible to speak about isolation level, when all logs are mixed together? The same about sending queue. All customers are using a single output queue, so how can we speak about isolation when a huge sending of one customer can afflict all others? Am I missing something? It it only a "cosmetic" issue? Cheers, Tonino Il 28/10/2010 17:54, Tonix (Antonio Nati) ha scritto: > Il 28/10/2010 15:58, Edward Finlayson ha scritto: >> Hi Martin, >> >> Thanks for your response. >> >> Unfortunately, I'm unable to have common mx servers. My clients have >> to have >> 'isolation' from one another and insist that all their 'servers' are >> within >> their own namespace / IP range. This means that I have to have >> inbound SMTP >> servers (mx) within the same domain as everything else and that the >> IPs used >> for the servers resolve in both directions. This in turn means, of >> course, >> that the IPs have to be dedicated to purpose. The knock on effect is >> that I >> have to have the SMTP greeting banner for a given IP address match the >> domain to which it is associated in order to comply fully with the >> RFCs and >> best practice. >> > > I don't understand such problem. Unless customers want specific logs, > because each one of them want to access his own logs as they like, > there is no reason to have different MX and different senders. > Could again make sense if you give different bandwith to different IPs. > > If you have different IP, but unique log, same shared bandwith, it has > no sense. > > If you want different IP, different logs, dedicated bandwith, you must > setup one qmail environment for each customer. > > Regards, > > Tonino > > >> Thanks for your suggestion though, in most other cases I would >> completely >> agree, >> >> Fin >> >> -Original Message- >> From: Martin Waschbüsch [mailto:mar...@waschbuesch.de] >> Sent: 28 October 2010 14:08 >> To: qmailtoaster-list@qmailtoaster.com >> Subject: Re: [qmailtoaster] smtp greeting banner frustration >> >> Well, it is perfectly ok to have the same FQDN listed as MX for several >> domains. the MX's FQDN does not have to be of the same domain. >> So, you could greet everyone with the same, valid, FQDN and never worry >> about the other stuff? >> >> Martin >> >> -- >> Martin Waschbüsch >> IT-Dienstleistungen >> Lautensackstr. 16 >> 80687 München >> >> Telefon: +49 89 57005708 >> Fax: +49 89 57868023 >> Mobil: +49 170 2189794 >> mar...@waschbuesch.de >> http://martin.waschbuesch.de >> >> Am 28.10.2010 um 14:25 schrieb Edward Finlayson: >> >>> Hi Tony, >>> >>> This would be true for a single domain, however my setup is more >>> like that >>> below: >>> >>> 127.0.1.1mail.domina1.com >>> 127.0.1.2smtp.domain2.co.uk >>> 127.0.8.30mail.domain30.net >>> 127.0.8.90mail.domain90.com >>> 127.2.1.112mx1.domain112.org >>> >>> Obviously, I've obfuscated the real addresses and domains but the >>> layout >>> above is representative. >>> >>> Thanks again Tony, >>> >>> Fin >>> >>> >>> -Original Message- >>> From: Tony White [mailto:t...@ycs.com.au] >>> Sent: 28 October 2010 13:17 >>> To: qmailtoaster-list@qmailtoaster.com >>> Subject: Re: [qmailtoaster] smtp greeting banner frustration >>> >>> My first reply does not seem to have arrive so I will try again... >>> >>> If I understand your question it should be as easy as >>> editing the smtpgreeting file to reflect the rDNS value. >>> >>> ie edit /var/qmail.control/smtpgreeting to >>> mail.domain.com >>> >>> >>> >>> >>> On 28/10/2010 10:31 PM, Anil
Re: [qmailtoaster] smtp greeting banner frustration
Probably you need a small patch against qmail-smtpd. Before reading "me" file, it should try a file named like "100.100.100.100.me". IP is taken by $TCPLOCALIP variable. Ciao! Tonino Il 28/10/2010 19:29, Edward Finlayson ha scritto: Hi Tonino, Sorry if the thread seems to be talking about different issues, but it is primarily a cosmetic issue but my clients are insistent on this perceived isolation, the logs and the outbound queues are also split by client domain after application of an in house patch. To this end there is a level of separation of outbound mail. It is sent on the IP, using the correct EHLO string, but inbound is still using a common SMTP Greeting Banner despite being contacted on the correct IPs. I cannot use a common outbound IP as this mixes the reputation of the sending domains into one based upon said IP, and my clients are using this service for transactional mailings so virtually demand independent reputation. The inbound server is primarily cosmetic, but is checked by the tool that they are using for verification, and is being flagged as a warning for not being compliant with RFC2821 specifically point 4.3.1 by issuing a SMTP greeting that corresponds to the FQDN of the host which is being connected to. I hope this clears up my dilemma and doesn't cause any confusion, Fin -Original Message- From: Tonix (Antonio Nati) [mailto:to...@interazioni.it] Sent: 28 October 2010 18:11 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration Edward, I'm just trying to understand others needs. As I am an ISP, I could be I'm missing something important for my customers too. How is it possible to speak about isolation level, when all logs are mixed together? The same about sending queue. All customers are using a single output queue, so how can we speak about isolation when a huge sending of one customer can afflict all others? Am I missing something? It it only a "cosmetic" issue? Cheers, Tonino Il 28/10/2010 17:54, Tonix (Antonio Nati) ha scritto: Il 28/10/2010 15:58, Edward Finlayson ha scritto: Hi Martin, Thanks for your response. Unfortunately, I'm unable to have common mx servers. My clients have to have 'isolation' from one another and insist that all their 'servers' are within their own namespace / IP range. This means that I have to have inbound SMTP servers (mx) within the same domain as everything else and that the IPs used for the servers resolve in both directions. This in turn means, of course, that the IPs have to be dedicated to purpose. The knock on effect is that I have to have the SMTP greeting banner for a given IP address match the domain to which it is associated in order to comply fully with the RFCs and best practice. I don't understand such problem. Unless customers want specific logs, because each one of them want to access his own logs as they like, there is no reason to have different MX and different senders. Could again make sense if you give different bandwith to different IPs. If you have different IP, but unique log, same shared bandwith, it has no sense. If you want different IP, different logs, dedicated bandwith, you must setup one qmail environment for each customer. Regards, Tonino Thanks for your suggestion though, in most other cases I would completely agree, Fin -Original Message- From: Martin Waschbüsch [mailto:mar...@waschbuesch.de] Sent: 28 October 2010 14:08 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration Well, it is perfectly ok to have the same FQDN listed as MX for several domains. the MX's FQDN does not have to be of the same domain. So, you could greet everyone with the same, valid, FQDN and never worry about the other stuff? Martin -- Martin Waschbüsch IT-Dienstleistungen Lautensackstr. 16 80687 München Telefon: +49 89 57005708 Fax: +49 89 57868023 Mobil: +49 170 2189794 mar...@waschbuesch.de http://martin.waschbuesch.de Am 28.10.2010 um 14:25 schrieb Edward Finlayson: Hi Tony, This would be true for a single domain, however my setup is more like that below: 127.0.1.1mail.domina1.com 127.0.1.2smtp.domain2.co.uk 127.0.8.30mail.domain30.net 127.0.8.90mail.domain90.com 127.2.1.112mx1.domain112.org Obviously, I've obfuscated the real addresses and domains but the layout above is representative. Thanks again Tony, Fin -Original Message- From: Tony White [mailto:t...@ycs.com.au] Sent: 28 October 2010 13:17 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] smtp greeting banner frustration My first reply does not seem to have arrive so I will try again... If I understand your question it should be as easy as editing the smtpgreeting file to reflect the rDNS value. ie edit /var/qmail.control/smtpgreeting to mail.domain.com On 28/10/2010 10:31 PM, Anil Aliyan wrote: This happens because you smtp service is listening on all ip addresses. If you wa
[qmailtoaster] Re: smtp greeting banner frustration
You say you have a "requirement to be able to prove isolation of domains". That's a pretty broad term, meaning what exactly? Is "isolation of domains" defined anywhere? I think that using DNSStuff to verify isolation is pretty lame, and I expect you'd agree. Depending on how much isolation is really required, the use of virtual domains might not be acceptable. This requirement appears to "fly in the face" of virtual domains. In order for any host to be able to do what you're saying in order to pass the "DNSStuff test", there would (of course) need to be a mapping of some sort defined between an interface and domain. How else would the server know which name to use? There's no other bit of data (that I know of) which could be used to tell which domain the message (with no address yet identified) will be sent to. Some custom coding would be required to accomplish this. I think the best solution for your situation is to set up a QMT VM for each domain with such (lame as they may be) requirements. And be sure to charge a premium for such a configuration. ;) Regarding RFCs, I disagree that they are 'guidelines'. I'd like to see any official document from Hotmail, Yahoo, Google et al that says otherwise. Also, you quote RFC2821 section 4.3.1: > Note: all the greeting-type replies have the official name (the > fully-qualified primary domain name) of the server host as the first word > following the reply code. Sometimes the host will have no meaningful name. Notice that it says *primary* domain name. There can be only one *primary* domain name, no? -- -Eric 'shubes' On 10/28/2010 09:34 AM, Edward Finlayson wrote: Hi Eric, Please don't take this the wrong way but we appear to be talking at cross purposes. You reference the EHLO string which is of course the outbound string, used to identify a server to the recipient host. I am referring to the SMTP Greeting String used to identify the local Receiving sever to the remotely connecting sending server. It is also called the SMTP Banner depending upon the tech used. The EHLO String, in operational terms, has to be both correctly authorised for the sending domain (present in SPF and/or listed as an MX server) and reverse resolvable to the same FQDN. I agree that this is not in the RFCs but it is certainly affecting sending reputation when this is not the case. Therefore the sending 'servers' for a given domain, if they are themselves within that domain, in practical terms, must forward and reverse resolve mirroring each other and offer both the correct banner greeting EHLO and SMTP Greeting in order to be considered complete within the domain space itself. I am not saying that my requirement is either right or wrong; workable, practical or even sensible. I concur that the vast majority of clients, my own included, would never even look at these factors, let alone understand them. However I have to get this resolved in order to eliminate the perceived 'issue'. This is a classic case of business requirement over practicality. I fully agree with all that has been said with regard to what is possible. However, I simply have a requirement to be a able to prove isolation of domains for my clients. Therefore, I have to support what 'should' be possible i.e. dedicated IP addresses within a name space and the correct identification of servers at an 'operational level'. This means that I have to have the correct SMTP greeting for incoming connections. Outbound are in fact already supported on the system in question via domain dependant EHLO strings. With regard to your comment re the RFCs, yes I aware of what they state (otherwise, wouldn't have quoted them myself). However, as these are only 'guidelines' according to Hotmail, Yahoo, Google et al and each tend to selectively choose which and how to implement them; it is better therefore to comply as much as possible. to that end RFC821 4.3 specifically states: 4.3. SEQUENCING OF COMMANDS AND REPLIES The communication between the sender and receiver is intended to be an alternating dialogue, controlled by the sender. As such, the sender issues a command and the receiver responds with a reply. The sender must wait for this response before sending further commands. One important reply is the connection greeting. Normally, a receiver will send a 220 "Service ready" reply when the connection is completed. The sender should wait for this greeting message before sending any commands. Note: all the greeting type replies have the official name of the server host as the first word following the reply code. For example, 220 USC-ISIF.ARPA Service ready And RFC2821 4.3.1 details: Note: all the greeting-type replies have the official name (the fully-qualified primary domain name) of the server host as the first word following the reply code. Sometimes the host will have no meaningful n
RE: [qmailtoaster] Re: smtp greeting banner frustration
Hi Eric, Please check out the following urls, hotmail for example simultaneously choose to treat the RFCs a standards and guidelines and simply cherry pick the ones they like: http://mail.live.com/mail/policies.aspx http://www.spamcop.net/fom-serve/cache/22.html Also it is common knowledge that Yahoo flout the RFCs in so much as the 'spam avoidance' techniques are concerned. Simply Google it. Your final point, there can only be one primary domain: quite true, a Primary domain Per IP Address... really the point is moot. As I said before, I need to support multiple email domains FULLY WITHIN THE RFC on a single machine. To that end I am simply going to install multiple smtpd Daemons, job done. Thanks for the input however, it was interesting. Fin -Original Message- From: Eric Shubert [mailto:e...@shubes.net] Sent: 28 October 2010 19:13 To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Re: smtp greeting banner frustration You say you have a "requirement to be able to prove isolation of domains". That's a pretty broad term, meaning what exactly? Is "isolation of domains" defined anywhere? I think that using DNSStuff to verify isolation is pretty lame, and I expect you'd agree. Depending on how much isolation is really required, the use of virtual domains might not be acceptable. This requirement appears to "fly in the face" of virtual domains. In order for any host to be able to do what you're saying in order to pass the "DNSStuff test", there would (of course) need to be a mapping of some sort defined between an interface and domain. How else would the server know which name to use? There's no other bit of data (that I know of) which could be used to tell which domain the message (with no address yet identified) will be sent to. Some custom coding would be required to accomplish this. I think the best solution for your situation is to set up a QMT VM for each domain with such (lame as they may be) requirements. And be sure to charge a premium for such a configuration. ;) Regarding RFCs, I disagree that they are 'guidelines'. I'd like to see any official document from Hotmail, Yahoo, Google et al that says otherwise. Also, you quote RFC2821 section 4.3.1: > Note: all the greeting-type replies have the official name (the > fully-qualified primary domain name) of the server host as the first word > following the reply code. Sometimes the host will have no meaningful name. Notice that it says *primary* domain name. There can be only one *primary* domain name, no? -- -Eric 'shubes' On 10/28/2010 09:34 AM, Edward Finlayson wrote: > Hi Eric, > > Please don't take this the wrong way but we appear to be talking at cross > purposes. You reference the EHLO string which is of course the outbound > string, used to identify a server to the recipient host. I am referring to > the SMTP Greeting String used to identify the local Receiving sever to the > remotely connecting sending server. It is also called the SMTP Banner > depending upon the tech used. The EHLO String, in operational terms, has to > be both correctly authorised for the sending domain (present in SPF and/or > listed as an MX server) and reverse resolvable to the same FQDN. I agree > that this is not in the RFCs but it is certainly affecting sending > reputation when this is not the case. Therefore the sending 'servers' for a > given domain, if they are themselves within that domain, in practical terms, > must forward and reverse resolve mirroring each other and offer both the > correct banner greeting EHLO and SMTP Greeting in order to be considered > complete within the domain space itself. > > I am not saying that my requirement is either right or wrong; workable, > practical or even sensible. I concur that the vast majority of clients, my > own included, would never even look at these factors, let alone understand > them. However I have to get this resolved in order to eliminate the > perceived 'issue'. > > This is a classic case of business requirement over practicality. I fully > agree with all that has been said with regard to what is possible. However, > I simply have a requirement to be a able to prove isolation of domains for > my clients. Therefore, I have to support what 'should' be possible i.e. > dedicated IP addresses within a name space and the correct identification of > servers at an 'operational level'. This means that I have to have the > correct SMTP greeting for incoming connections. Outbound are in fact already > supported on the system in question via domain dependant EHLO strings. > With regard to your comment re the RFCs, yes I aware of what they state > (otherwise, wouldn't have quoted them myself). However, as these are only > 'guidelines' according to Hotmail, Yahoo, Google et al and each tend to > selectively choose which and how to implement them; it is better therefore > to comply as much as possible. to that end RFC821 4.3 specifically states: > > 4.3. SEQUENCING OF C
[qmailtoaster] Re: smtp greeting banner frustration
Hey Edward, I'm not seeing any real RFC violations in those links. Spamcop claims that MS isn't following the RFC, but I believe that is a false claim. I don't believe there's anything in an RFC about how headers are *displayed*. I also googled it, and came up with nothing. I don't believe that any of the big mailers are in violation of any RFCs pertaining to email. That's not to say that they haven't implemented non-standard methods to mitigate spam. My point here is that your requirement is not a matter of RFC compliance. There is nothing in an RFC that says such. It may be a requirement for isolation and for your clients, but it is not a requirement for RFC compliance. -- -Eric 'shubes' On 10/28/2010 11:42 AM, Edward Finlayson wrote: Hi Eric, Please check out the following urls, hotmail for example simultaneously choose to treat the RFCs a standards and guidelines and simply cherry pick the ones they like: http://mail.live.com/mail/policies.aspx http://www.spamcop.net/fom-serve/cache/22.html Also it is common knowledge that Yahoo flout the RFCs in so much as the 'spam avoidance' techniques are concerned. Simply Google it. Your final point, there can only be one primary domain: quite true, a Primary domain Per IP Address... really the point is moot. As I said before, I need to support multiple email domains FULLY WITHIN THE RFC on a single machine. To that end I am simply going to install multiple smtpd Daemons, job done. Thanks for the input however, it was interesting. Fin -Original Message- From: Eric Shubert [mailto:e...@shubes.net] Sent: 28 October 2010 19:13 To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Re: smtp greeting banner frustration You say you have a "requirement to be able to prove isolation of domains". That's a pretty broad term, meaning what exactly? Is "isolation of domains" defined anywhere? I think that using DNSStuff to verify isolation is pretty lame, and I expect you'd agree. Depending on how much isolation is really required, the use of virtual domains might not be acceptable. This requirement appears to "fly in the face" of virtual domains. In order for any host to be able to do what you're saying in order to pass the "DNSStuff test", there would (of course) need to be a mapping of some sort defined between an interface and domain. How else would the server know which name to use? There's no other bit of data (that I know of) which could be used to tell which domain the message (with no address yet identified) will be sent to. Some custom coding would be required to accomplish this. I think the best solution for your situation is to set up a QMT VM for each domain with such (lame as they may be) requirements. And be sure to charge a premium for such a configuration. ;) Regarding RFCs, I disagree that they are 'guidelines'. I'd like to see any official document from Hotmail, Yahoo, Google et al that says otherwise. Also, you quote RFC2821 section 4.3.1: > Note: all the greeting-type replies have the official name (the > fully-qualified primary domain name) of the server host as the first word > following the reply code. Sometimes the host will have no meaningful name. Notice that it says *primary* domain name. There can be only one *primary* domain name, no? - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] pop attack on server
Hi everyone, I had an interesting day. Starting getting those calls about email clients asking for password. Red flag says "mail server way too busy" I investigate and find that vchkpw is taking all of the process load. I look at the number of connections and there were about 50 from one place in Bulgaria. The only way to drop that way to add a drop rule into the gateway. What is everyone using to stop this kind of force attack on the pop side? --Dave -- David Milholen Project Engineer P:501-318-1300
[qmailtoaster] Re: pop attack on server
On 10/28/2010 04:02 PM, David Milholen wrote: Hi everyone, I had an interesting day. Starting getting those calls about email clients asking for password. Red flag says "mail server way too busy" I investigate and find that vchkpw is taking all of the process load. I look at the number of connections and there were about 50 from one place in Bulgaria. The only way to drop that way to add a drop rule into the gateway. What is everyone using to stop this kind of force attack on the pop side? --Dave -- David Milholen Project Engineer P:501-318-1300 I know that some people here use fail2ban. Sounds like it would have thwarted this attack, if they were all from the same IP. I haven't gotten around to installing it myself. We should have a fail2ban page on the wiki, but I don't think anyone's written one yet. Search the archives, and you'll find references. Here's one from the spamdyke list: http://www.spamdyke.org/mailman/private/spamdyke-users/2010q3/002961.html (you must be a spamdyke list subscriber to view) -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: pop attack on server
I'm using OSSEC http://www.ossec.net Very nice and complete IDS/Log analysis package. Easy to install and manage. On Thu, Oct 28, 2010 at 8:49 PM, Eric Shubert wrote: > On 10/28/2010 04:02 PM, David Milholen wrote: > >> Hi everyone, >> I had an interesting day. Starting getting those calls about email >> clients asking for password. Red flag says "mail server way too busy" >> I investigate and find that vchkpw is taking all of the process load. I >> look at the number of connections and there were about 50 from one place >> in Bulgaria. The only way to drop that way to add a drop rule into the >> gateway. >> >> What is everyone using to stop this kind of force attack on the pop side? >> >> --Dave >> -- >> >> David Milholen >> Project Engineer >> P:501-318-1300 >> > > I know that some people here use fail2ban. Sounds like it would have > thwarted this attack, if they were all from the same IP. I haven't gotten > around to installing it myself. We should have a fail2ban page on the wiki, > but I don't think anyone's written one yet. Search the archives, and you'll > find references. Here's one from the spamdyke list: > http://www.spamdyke.org/mailman/private/spamdyke-users/2010q3/002961.html > (you must be a spamdyke list subscriber to view) > > -- > -Eric 'shubes' > > > > - > Qmailtoaster is sponsored by Vickers Consulting Group ( > www.vickersconsulting.com) > Vickers Consulting Group offers Qmailtoaster support and installations. > If you need professional help with your setup, contact them today! > > - >Please visit qmailtoaster.com for the latest news, updates, and > packages. > To unsubscribe, e-mail: > qmailtoaster-list-unsubscr...@qmailtoaster.com >For additional commands, e-mail: > qmailtoaster-list-h...@qmailtoaster.com > > >
Re: [qmailtoaster] smtp greeting banner frustration
If I understand your question it should be as easy as editing the smtpgreeting file to reflect the rDNS value. ie edit /var/qmail.control/smtpgreeting to mail.domain.com On 28/10/2010 9:31 PM, Edward Finlayson wrote: Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin -- best wishes Tony White Yea Computing Services http://www.ycs.com.au 4 The Crescent Yea Victoria Australia 3717 Telephone No's VIC : 03 5797 3344 VIC : 03 9008 5614 TAS : 03 6107 9099 NT : 08 8921 4049 SA : 08 7123 0847 NSW : 02 8014 5547 QLD : 07 3123 6647 WA : 08 6365 2199 FAX : 03 9008 5610 (FAX2Email) FAX : 03 5797-3288 IMPORTANT NOTICE This communication including any file attachments is intended solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient, or the person responsible for delivering this communication to the intended recipient, please immediately notify the sender by email and delete the original transmission and its contents. Any unauthorised use, dissemination, forwarding, printing or copying of this communication including file attachments is prohibited. It is your responsibility to scan this communication including any file attachments for viruses and other defects. To the extent permitted by law, Yea Computing Services and its associates will not be liable for any loss or damage arising in any way from this communication including any file attachments. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
RE: [qmailtoaster] pop attack on server
I setup a bridge firewall that way I can control what comes in our out of my network. Joel _ From: David Milholen [mailto:dmilho...@wletc.com] Sent: Thursday, October 28, 2010 6:03 PM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] pop attack on server Hi everyone, I had an interesting day. Starting getting those calls about email clients asking for password. Red flag says "mail server way too busy" I investigate and find that vchkpw is taking all of the process load. I look at the number of connections and there were about 50 from one place in Bulgaria. The only way to drop that way to add a drop rule into the gateway. What is everyone using to stop this kind of force attack on the pop side? --Dave -- David Milholen Project Engineer P:501-318-1300 _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1153 / Virus Database: 424/3225 - Release Date: 10/28/10 <>
[qmailtoaster] Auto-Response at server level
Hi Everyone, Is there anyway to setup auto-response at server level. Actually Diwali vacations are coming in India which is same like Christmas vacations, my users want to put out of office auto-response. Now on few server there are more than 300 users and users doesn't have access to qmailadmin. So is there anyway to put 1 auto-response at the server level. Amit
Re: [qmailtoaster] pop attack on server
Hi, I use this to stop immediate attacks... #!/bin/sh logf="/var/log/blockip.log" mdate=`date +%c` ### must be root ### if [ `whoami` != "root" ]; then echo "" echo "$0 must be ran as root" echo "" exit 1 fi export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin is_ip="grep -Ec '^[1-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9](\/[0-3]?[0-9])?$'" if [ `echo $1 |eval $is_ip` != "1" ]; then echo "$mdate Error in IP address $1" else iptables -I INPUT -s $1 -j DROP # echo out to rc file to start at reboot echo "iptables -I INPUT -s $1 -j DROP" >> /etc/rc.d/rc.blockedips echo "$mdate now dropping all packets from $1" >> $logf fi quick and dirty but you can remove it when you like... hope this helps... Also use bfd (brute force detection) on pop/ssh/ftp as well. Automatically stops attacks at 30 invalid login attempts from the same ip address. http://www.rfxn.com/projects/brute-force-detection/ On 29/10/2010 10:02 AM, David Milholen wrote: Hi everyone, I had an interesting day. Starting getting those calls about email clients asking for password. Red flag says "mail server way too busy" I investigate and find that vchkpw is taking all of the process load. I look at the number of connections and there were about 50 from one place in Bulgaria. The only way to drop that way to add a drop rule into the gateway. What is everyone using to stop this kind of force attack on the pop side? --Dave -- David Milholen Project Engineer P:501-318-1300 -- best wishes Tony White Yea Computing Services http://www.ycs.com.au 4 The Crescent Yea Victoria Australia 3717 Telephone No's VIC : 03 5797 3344 VIC : 03 9008 5614 TAS : 03 6107 9099 NT : 08 8921 4049 SA : 08 7123 0847 NSW : 02 8014 5547 QLD : 07 3123 6647 WA : 08 6365 2199 FAX : 03 9008 5610 (FAX2Email) FAX : 03 5797-3288 IMPORTANT NOTICE This communication including any file attachments is intended solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient, or the person responsible for delivering this communication to the intended recipient, please immediately notify the sender by email and delete the original transmission and its contents. Any unauthorised use, dissemination, forwarding, printing or copying of this communication including file attachments is prohibited. It is your responsibility to scan this communication including any file attachments for viruses and other defects. To the extent permitted by law, Yea Computing Services and its associates will not be liable for any loss or damage arising in any way from this communication including any file attachments. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com