[qmailtoaster] DNS Refresh?
Hello List, Just wondering if someone could help? I have a qmailtoaster running on CentOS 4.5 and I have a problem sending mail to a customer, they use our DNS Servers for their DNS and recently (about 9 days ago) they changed their DNS records for email however when I try to send them an email I get a bounce back from my toaster saying the message couldn't be sent due to remote host not accepting the mail - the problem is it is trying to send mail to pervious mail server not the new one. Im sure this is a DNS problem, is there anyway I can refresh DNS on the toaster like you do in XP ipconfig /flushdns? The TTL has been and gone on the updated record and I know the record has changed because the record is hosted on our servers. Any help much appreciated Thanks Chris
Re: [qmailtoaster] Hello and a question. :)
Eric Shubert wrote: David Fix wrote: Hey guys, I'm new to the list, and want to say thanks for a great product. :) I've never had any problems installing before, so this time has me a bit flummoxed. :) I've googled extensively with no result, so I thought I'd consult the experts. Here's the deal: I'm installing under CentOS 5.1, kernel 2.6.18-53.1.19.el5. I've installed all the dependencies, and everything went well in the install until it got to the point of rebuilding spamassassin-toaster-3.2.4-1.3.13.src.rpm. Here was the command line: rpmbuild --rebuild --with cnt50 spamassassin-toaster-3.2.4-1.3.13.src.rpm And everything proceeded up until this point: --- + install -m 0644 /usr/src/redhat/SOURCES/qmailtoaster.local.cf.bz2 /var/tmp/spamassassin-toaster-root/etc/mail/spamassassin/local.cf.bz2 install: cannot create regular file `/var/tmp/spamassassin-toaster-root/etc/mail/spamassassin/local.cf.bz2': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.67508 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.67508 (%install) --- Weird... So I tried running the install command, with the same result. I created the directory myself after, like this: # mkdir /var/tmp/spamassassin-toaster-root/etc/mail/spamassassin/ And then was able to install that package. However, if I try running the build again, it deletes that directory somewhere along the way, and it stops at the same spot with the cannot create regular file message there... Any ideas? :) Thanks in advance! Dave Welcome to the club. :) I'm glad you asked that question (again) because I've spent a good deal of time recently (days actually) nailing it down. To make a long story (relatively) short, there's a bug in the perl ExtUtils::MakeMaker module which makes building a binary rpm properly down right difficult (to say the least). Spamassassin itself requires MakeMaker 5.4.5. The DESTDIR parameter was introduced in MakeMaker 6.11, and is intended to be used for rpm type installs. The trouble is (besides the fact that MakeMaker is downright evil), the DESTDIR parameter has never worked as advertised (it's still broken). I've been able to hack the spamassassin-toaster spec file to the extent that it works properly with MakeMaker 6.44, thanks to a spamassassin bug report. That's the good news. The bad news is that MakeMaker is part of the main perl package. COS4 has perl-5.8.5-36.el4_5.2, which contains MakeMaker 6.17. COS5 has perl-5.8.8-10.el5_0.2, which contains MakeMaker 6.30. The only way I can find to install MakeMaker 6.44 is to upgrade CPAN. Note, not upgrade *using* CPAN, upgrade CPAN itself, as in perl -e 'use CPAN; install Bundle::CPAN'. The newer MakeMaker will be updated as a dependency of CPAN. So that's where things presently stand. spamassassin-toaster-3.2.4-1.3.16.src.rpm (a development version that I've sent to Erik Espinoza) installs ok, but only with MakeMaker 6.44. I'm not sure where things will go from here, whether someone might find a way to get rpmbuild working with various broken MakeMaker versions, or whether MakeMaker 6.44 will become a minimum dependency for spamassassin-toaster. Stay tuned. Well Well I never had any issues rebuilding spamassassin-toaster-3.2.4-1.3.13.src.rpm on any of my CentoOs 5 64Bit or even some old fc5/6 boxes as long as you have CPAN version 1.91+ or maybe even 1.90+ (not sure about that one) it will build w/o any issues the spamassassin-toaster-3.2.4-1.3.13.src.rpm version you find on the qtoaster site. -P
Re: [qmailtoaster] Auto responder
Micah Abrams wrote: Hey guys - I have a couple users who are receiving bounces from their mailing list msgs when they have their vacation msgs set. The error is: AUTORESPOND: I can't handle a message with a Mailing-List header. I am curious how others are dealing with this? I'm running toaster-5.4.17 with autorespond-toaster-2.0.4 Thanks - Micah That is the autoresponder letting you know that it's not going to be sending a vacation message to the mailing list address. There is nothing that needs to be done; the only one getting this message is the user who set the vacation message. It's not the mailing list sending the bounce message.
Re: [qmailtoaster] Help regarding mail relay
senthil vel wrote: Hi List, I am having a client. At first his domain was in a server, in which, send mail was running. if we put the command, host -t mx client.com http://client.com, it will show, client.com http://client.com mail is handled by 10 sendmail.one.com http://sendmail.one.com client.com http://client.com mail is handled by 20 sendmail.two.com http://sendmail.two.com Then we moved the domain client.com http://client.com to qmail server which is having qmail-toaster now if we put host -t mx client.com http://client.com, it will show client.com http://client.com mail is handled by 10 qmail.one.com http://qmail.one.com client.com http://client.com mail is handled by 20 sendmail.two.com http://sendmail.two.com Now the problem is, one mail from the [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] get bounced. It is bounced from the server sendmail.two.com(Secondary MX) telling that 553 5.3.0 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]... nouser No such user 550 5.1.1 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]... User unknown Now i removed the secondary mx record. But this is not a solution. My doubt is, Why a local mail is bounced from secondary server? The user used outlook, so he may use old settings. Because the domain is not completely deleted in the old server. But He is telling that few mails to user2 only bouncing. Please Please clarify. The user cannot send emails through the secondary server unless the accounts exist there. He will only be able to send emails through the server that actually has his account. If you want the secondary server to be a caching mail server for incoming mail you just have to add the domain to the rcpthosts file - look at the wiki, there's instructions on how to do this. For both the primary and secondary servers to allow email to be sent through them you'd need to set up a cluster type environment and I'd suggest you hire one of the consultants listed in the wiki: http://wiki.qmailtoaster.com/index.php/Main_Page#Additional_Resources
Re: [qmailtoaster] Help regarding mail relay
Thanks Jake. But the problem is, the primary server was not down. And why the local mail went to the secondary server even the primary server is alive. Please guide me. On Wed, May 14, 2008 at 4:05 PM, Jake Vickers [EMAIL PROTECTED] wrote: senthil vel wrote: Hi List, I am having a client. At first his domain was in a server, in which, send mail was running. if we put the command, host -t mx client.com, it will show, client.com mail is handled by 10 sendmail.one.com client.com mail is handled by 20 sendmail.two.com Then we moved the domain client.com to qmail server which is having qmail-toaster now if we put host -t mx client.com, it will show client.com mail is handled by 10 qmail.one.com client.com mail is handled by 20 sendmail.two.com Now the problem is, one mail from the [EMAIL PROTECTED] to [EMAIL PROTECTED] bounced. It is bounced from the server sendmail.two.com(Secondary MX) telling that 553 5.3.0 [EMAIL PROTECTED]... nouser No such user 550 5.1.1 [EMAIL PROTECTED]... User unknown Now i removed the secondary mx record. But this is not a solution. My doubt is, Why a local mail is bounced from secondary server? The user used outlook, so he may use old settings. Because the domain is not completely deleted in the old server. But He is telling that few mails to user2 only bouncing. Please Please clarify. The user cannot send emails through the secondary server unless the accounts exist there. He will only be able to send emails through the server that actually has his account. If you want the secondary server to be a caching mail server for incoming mail you just have to add the domain to the rcpthosts file - look at the wiki, there's instructions on how to do this. For both the primary and secondary servers to allow email to be sent through them you'd need to set up a cluster type environment and I'd suggest you hire one of the consultants listed in the wiki: http://wiki.qmailtoaster.com/index.php/Main_Page#Additional_Resources -- Thanks and Regards, S.Senthilvel, Webindia Internet Services Chennai - 600 029, India.
Re: [qmailtoaster] DNS Refresh?
Chris Bird wrote: Hello List, Just wondering if someone could help? I have a qmailtoaster running on CentOS 4.5 and I have a problem sending mail to a customer, they use our DNS Servers for their DNS and recently (about 9 days ago) they changed their DNS records for email however when I try to send them an email I get a bounce back from my toaster saying the message couldn't be sent due to remote host not accepting the mail -- the problem is it is trying to send mail to pervious mail server not the new one. Im sure this is a DNS problem, is there anyway I can refresh DNS on the toaster like you do in XP ipconfig /flushdns? The TTL has been and gone on the updated record and I know the record has changed because the record is hosted on our servers. Any help much appreciated Thanks Chris service named restart will flush the DNS. You need to look at where your machine is getting the DNS information from (it will use the name servers located in /etc/resolv.conf). If you're using a big ISP they may be caching longer than they are supposed to (T-Mobile's wireless caches DNS info for 12 days, regardless of what you set the TTL as). You may also want to post the domain name to us here on the list or use a tool like dnsstuff.com to make sure that DNS was done correctly.
RE: [qmailtoaster] DNS Refresh?
Check your smtproutes in the /var/qmail/control dir. And in your Qmail Toaster “dig @127.0.0.1 customerdomain.com mx” and see if it gives correct results. Biju Jose _ From: Chris Bird [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 14, 2008 3:27 PM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] DNS Refresh? Hello List, Just wondering if someone could help? I have a qmailtoaster running on CentOS 4.5 and I have a problem sending mail to a customer, they use our DNS Servers for their DNS and recently (about 9 days ago) they changed their DNS records for email however when I try to send them an email I get a bounce back from my toaster saying the message couldn’t be sent due to remote host not accepting the mail – the problem is it is trying to send mail to pervious mail server not the new one. Im sure this is a DNS problem, is there anyway I can refresh DNS on the toaster like you do in XP ipconfig /flushdns? The TTL has been and gone on the updated record and I know the record has changed because the record is hosted on our servers. Any help much appreciated Thanks Chris No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.16/1429 - Release Date: 5/12/2008 6:14 PM No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.16/1429 - Release Date: 5/12/2008 6:14 PM
Re: [qmailtoaster] Hello and a question. :)
Philip wrote: Well Well I never had any issues rebuilding spamassassin-toaster-3.2.4-1.3.13.src.rpm on any of my CentoOs 5 64Bit or even some old fc5/6 boxes as long as you have CPAN version 1.91+ or maybe even 1.90+ (not sure about that one) it will build w/o any issues the spamassassin-toaster-3.2.4-1.3.13.src.rpm version you find on the qtoaster site. -P Updating CPAN will update MakeMaker. If you just install perl from the OS repo it will have the older versions of MakeMaker on them, so you're forced to upgrade CPAN.
RE: [qmailtoaster] DNS Refresh?
Hi Jake, Thanks for that. We are the ISP, however they have moved their email (they had a hosted Plesk box n our data centre) to rackspace or appriver not sure the customers are an American company and we are based in UK so not sure who it is exactly they are using - but we have the DNS for their domain. I know some of the larger ISP's in UK seem to ignore the TTL's (Plusnet are the main ones I have problems with, had several problems with them in past). The customer in the UK branches uses our ADSL and SDSL services and therefore our DNS - which is why I didn't understand the problem I was having. I'll try restarting the named service on the toaster and see if that solves the problem. If not I'll post the domain name. Thanks again Chris _ From: Jake Vickers [mailto:[EMAIL PROTECTED] Sent: 14 May 2008 11:44 To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] DNS Refresh? Chris Bird wrote: Hello List, Just wondering if someone could help? I have a qmailtoaster running on CentOS 4.5 and I have a problem sending mail to a customer, they use our DNS Servers for their DNS and recently (about 9 days ago) they changed their DNS records for email however when I try to send them an email I get a bounce back from my toaster saying the message couldn't be sent due to remote host not accepting the mail - the problem is it is trying to send mail to pervious mail server not the new one. Im sure this is a DNS problem, is there anyway I can refresh DNS on the toaster like you do in XP ipconfig /flushdns? The TTL has been and gone on the updated record and I know the record has changed because the record is hosted on our servers. Any help much appreciated Thanks Chris service named restart will flush the DNS. You need to look at where your machine is getting the DNS information from (it will use the name servers located in /etc/resolv.conf). If you're using a big ISP they may be caching longer than they are supposed to (T-Mobile's wireless caches DNS info for 12 days, regardless of what you set the TTL as). You may also want to post the domain name to us here on the list or use a tool like dnsstuff.com to make sure that DNS was done correctly.
Re: [qmailtoaster] Help regarding mail relay
senthil vel wrote: Thanks Jake. But the problem is, the primary server was not down. And why the local mail went to the secondary server even the primary server is alive. Please guide me. If you have 2 MX records, mail will go to both. Some mailers (other people sending to you) will send to the lowest MX, others will send to the highest. You have no control over their mail server and who it decides to send emails to.
Re: [qmailtoaster] Domain Keys
Kisakye ALex wrote: Greetings, Am seeing many of these in my spamd logs warn: Use of uninitialized value in string eq at /usr/lib/perl5/site_perl/5.8.5/Mail/DomainKeys/Key/Public.pm line 67, GEN500 line 149. Can someone help me sort this out. A few changed I had done to this box were disabling domain keys, could that be responsible and on another note, a few of my outlook users are getting errors connecting to the smtp server. from smtp i can see a few of these @4000482aaa0b11cfa77c TIMEOUT from: [EMAIL PROTECTED] I have already increased my idle-timeout-secs=660 Any help and pointers? Log into CPAN and update Bundle::CPAN and Mail::DomainKeys and see if the error resolves itself. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Help regarding mail relay
Oh...Ok. Ok...Thank a ton Jack.Now i am clear. On Wed, May 14, 2008 at 4:34 PM, Jake Vickers [EMAIL PROTECTED] wrote: senthil vel wrote: Thanks Jake. But the problem is, the primary server was not down. And why the local mail went to the secondary server even the primary server is alive. Please guide me. If you have 2 MX records, mail will go to both. Some mailers (other people sending to you) will send to the lowest MX, others will send to the highest. You have no control over their mail server and who it decides to send emails to. -- Thanks and Regards, S.Senthilvel, Webindia Internet Services Chennai - 600 029, India.
Re: [qmailtoaster] Hello and a question. :)
Cheers Eric. My spamassassin-toaster actually installed fine on CentOS 5 with (I presume) MakeMaker 6.30, however have just updated it to 6.44 the way you recommended to prevent any further issues. James On 14 May 2008, at 04:14, Eric Shubert wrote: perl -e 'use CPAN; install Bundle::CPAN - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Hello and a question. :)
I wish you hadn't have updated CPAN so we could tell for sure. :( Which version of spamassassin-toaster did you install? James Palmer wrote: Cheers Eric. My spamassassin-toaster actually installed fine on CentOS 5 with (I presume) MakeMaker 6.30, however have just updated it to 6.44 the way you recommended to prevent any further issues. James On 14 May 2008, at 04:14, Eric Shubert wrote: perl -e 'use CPAN; install Bundle::CPAN -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Domain keys
Kisakye ALex wrote: Greetings, I followed the following to disable domain keys, can anyone show me how to re-enable it cd /var/qmail/bin ln -sf qmail-queue.orig qmail-queue And then restart qmail: qmailctl restart thanks ALex cd /var/qmail/bin ln -sf qmail-dk qmail-queue qmailctl restart -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Hello and a question. :)
I installed 1.4.13, same as Philip. Installed fine on a fresh CentOS 5 install, no issues whatsoever. James On 14 May 2008, at 14:54, Eric Shubert wrote: I wish you hadn't have updated CPAN so we could tell for sure. :( Which version of spamassassin-toaster did you install? James Palmer wrote: Cheers Eric. My spamassassin-toaster actually installed fine on CentOS 5 with (I presume) MakeMaker 6.30, however have just updated it to 6.44 the way you recommended to prevent any further issues. James On 14 May 2008, at 04:14, Eric Shubert wrote: perl -e 'use CPAN; install Bundle::CPAN -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Domain keys
To reverse what you did (restoring the toaster to it's original state): # cd /var/qmail/bin # ln -sf qmail-dk qmail-queue This is the answer from Eric. I've tested and it's working. Charles Law Kisakye ALex wrote: Greetings, I followed the following to disable domain keys, can anyone show me how to re-enable it cd /var/qmail/bin ln -sf qmail-queue.orig qmail-queue And then restart qmail: qmailctl restart thanks ALex - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Help regarding mail relay
Jake Vickers wrote: senthil vel wrote: Thanks Jake. But the problem is, the primary server was not down. And why the local mail went to the secondary server even the primary server is alive. Please guide me. If you have 2 MX records, mail will go to both. Some mailers (other people sending to you) will send to the lowest MX, others will send to the highest. You have no control over their mail server and who it decides to send emails to. Hi Jake, I'm fairly new to this list (didn't administer my own mailserver for a few years) but have done a few qmail installations previously (nothing comparable to most people on the list probably though). During my education and after that in 'real life', I've always been told that the priority in the DNS record is used to determine to which server to send first. I've had a look at (what I believe is) the current RFC document about DNS MX records, which can be found here: ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt. If I read it correctly the priority number should be used to determine the order in which the mailservers are to be tried. Here is the part from the RFC which mentions prioritizing MX records )chapter 5): Multiple MX records contain a preference indication that MUST be used in sorting (see below). Lower numbers are more preferred than higher ones. If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by recognition of an easily-reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization. I know that a RFC is only that (no obligations) and I know that spammers sometimes (on purpose) use the lower priority MX record to circumvent graylisting and so on. But in principle, the primary server should have been used in the described situation (assuming there was no connection error somewhere in between). Could you tell me on what information your reply is based? Perhaps the RFC I mentioned is superceded... I'm always willing to learn that I've been taught incorrectly. It wouldn't be the first time it happened... Kind regards, Marc Rietman - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[qmailtoaster] Re: spamassassin woes [was: Hello and a question.]
Hmmm. Let me attempt to clarify what's gone on with this. This problem was first reported as: `/var/tmp/spamassassin-toaster-root/etc/mail/spamassassin/local.cf.bz2': No such file or directory What was happening was that the /v/t/s-t-r/etc/mail/spamassassin directory wasn't being created by the %makeinstall command, because it found that the files already existed (in the main /etc/mail/spamassassin directory, not the /v/t/s-t-r/ buildroot). Simple enough. The fix for this in the past has been to remove any installed spamassassin-toaster package before *building* a newer package. This would cause %makeinstall to always create the subject directory. But this was no longer working on some toasters, while it still succeeded on others. What was different? Amongst all of the variations out there, along had come version 6.44 of perl's ExtUtils::MakeMaker that nobody took much notice of, largely because it wasn't part of the stock perl packages for CentOS4 and 5 (I'm not sure about FC). The only way it came into play (on CentOS at least) was by doing an 'install Bundle::CPAN'. (If anyone has experienced this error with spamassassin-toaster-3.2.4-1.3.13 and anything but MakeMaker 6.44 I'd sure like to see it). I attempted to fix the spec file with versions 1.3.14 and 1.3.15, with varying degrees of success. I've also created version 1.3.16 that I think is the best fix. In testing 1.3.16 however, I discovered that it works with MakeMaker 6.44, but fails with all older MakeMaker versions. :( What's more is that the only way I know of to get the spec file working with both versions is to add code to check which version is installed and use whatever parameters might be appropriate for each. :(( Not a good solution. MakeMaker is EVIL! ;) While 6.44 was a valiant attempt to fix it's DESTDIR parameter (introduced in 6.11), MakeMaker 6.44 is (still) broken, although 1.3.16 contains a hack to get around its bugs. I'd like to note what German Molano mentioned in a related post (http://www.mail-archive.com/qmailtoaster-list@qmailtoaster.com/msg17858.html): The curious thing is that the files are generated on the rpm compile process but they landed on their final destiny, /etc/mail/spamassassin, without installing the generated rpm. Upon close examination of a build log that Marco Cordeior submitted on the same thread, I see that the rules in the /usr/share/spamassassin/ directory were being installed directly there during the rpmbuild process as well, and not in buildroot directory (and hence not in the binary rpm). So it's apparent that spamassassin-toaster has had its problems, which I attribute largely to perl's MakeMaker module. The (somewhat stealthy) release of version 6.44 is (TTBOMK) what caused this error, even though at the same time this version came a long way toward fixing its bugs. So how does one accomplish the upgrade? It depends on which version of MakeMaker you have: # grep '^our $VERSION' /usr/lib/perl5/5.8.?/ExtUtils/MakeMaker.pm If your version is pre-6.44, you should be able to upgrade to spamassassin-toaster-3.2.4-1.3.13 with no problem. If you use qtp-newmodel, you can only use versions of qmailtoaster-plus-0.3.0-1.4.0 or previous with this version (and previous) of spamassassin-toaster. If you upgrade manually, be sure to remove the existing version before building the binary rpm. If you have MakeMaker 6.44, you'll (almost?) certainly have a problem with spamassassin-toaster-3.2.4-1.3.13. You should wait for spamassassin-toaster-3.2.4-1.3.16 to be posted to the site. At that point you can use any version of qtp-newmodel you'd like (the most recent is usually best), and you should no longer need to remove the previous spamassassin-toaster package if you upgrade manually. Who knows what future versions of MakeMaker will have in store? I expect that some future version will require yet more changes to the spamassassin-toaster spec file, but will hopefully only involve removing the hack that's required to make it work around the bugs remaining in MakeMaker 6.44. James Palmer wrote: I installed 1.4.13, same as Philip. Installed fine on a fresh CentOS 5 install, no issues whatsoever. James On 14 May 2008, at 14:54, Eric Shubert wrote: I wish you hadn't have updated CPAN so we could tell for sure. :( Which version of spamassassin-toaster did you install? James Palmer wrote: Cheers Eric. My spamassassin-toaster actually installed fine on CentOS 5 with (I presume) MakeMaker 6.30, however have just updated it to 6.44 the way you recommended to prevent any further issues. James On 14 May 2008, at 04:14, Eric Shubert wrote: perl -e 'use CPAN; install Bundle::CPAN -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: [qmailtoaster] Help regarding mail relay
Marc Rietman wrote: I'm fairly new to this list (didn't administer my own mailserver for a few years) but have done a few qmail installations previously (nothing comparable to most people on the list probably though). During my education and after that in 'real life', I've always been told that the priority in the DNS record is used to determine to which server to send first. I've had a look at (what I believe is) the current RFC document about DNS MX records, which can be found here: ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt. If I read it correctly the priority number should be used to determine the order in which the mailservers are to be tried. Welcome to the list! Always nice to see a new face. Yes, the priority number is supposed to be used to determine delivery preference. I know that a RFC is only that (no obligations) and I know that spammers sometimes (on purpose) use the lower priority MX record to circumvent graylisting and so on. But in principle, the primary server should have been used in the described situation (assuming there was no connection error somewhere in between). Could you tell me on what information your reply is based? Perhaps the RFC I mentioned is superceded... I'm always willing to learn that I've been taught incorrectly. It wouldn't be the first time it happened... Kind regards, My reply was based on experiences with my own servers and those that I've worked on for other people/companies. The RFC is great and all but as you said there are no obligations. When it comes down to it, we follow the rules that the biggies such as AOL, Yahoo, Google, Microsoft, etc. set. I have a couple domains that have 3 MX records and I see mail delivered to all 3 machines regardless of priority or whether or not the others are answering. As far as I know that particular RFC has not been superceded but I'd say that roughly (without actually creating some boiled down metrics) 70%-80% of the servers that send me message actually follow that particular one. AOL has been seen delivering to all 3 of my MX records regardless of machine status. There's a couple other broadband companies that operate in the same manner that I've seen. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Help regarding mail relay
Jake Vickers wrote: My reply was based on experiences with my own servers and those that I've worked on for other people/companies. The RFC is great and all but as you said there are no obligations. When it comes down to it, we follow the rules that the biggies such as AOL, Yahoo, Google, Microsoft, etc. set. I have a couple domains that have 3 MX records and I see mail delivered to all 3 machines regardless of priority or whether or not the others are answering. As far as I know that particular RFC has not been superceded but I'd say that roughly (without actually creating some boiled down metrics) 70%-80% of the servers that send me message actually follow that particular one. AOL has been seen delivering to all 3 of my MX records regardless of machine status. There's a couple other broadband companies that operate in the same manner that I've seen. Ok, that clears things up. It's obviously the usual 'standard' which we 'all' follow... Thanks for the answer, Marc - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] duplicate emails
I have same problem, but i found out when user modify preference through webmail ( enable forwarding or out of office ) this is happening. On 2008.05.12, at 00:20, John wrote: I recently posted a message about this and found a solution but with negative effects. I determined that only one email address was receiving duplicate emails. I found that by moving that account's .qmail file out of the way the duplicates stopped. Here's the contents of .qmail: |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: maildrop-toaster' /etc/mail/mailfilter /home/vpopmail/domains/ boubion.com/dominic/Maildir/ Don't I need this for the spambox I set up? Memory and server loads are pretty consistent as not much has changed on this server in recent months so I don't think this is a RAM issue as has been suggested in other threads. Only odd thing is the timestamp on .qmail for the user is April 30th. I looked back in my trash can and can easily see the duplicates started after the file was modified. To be honest I don't remember what I might have done to modify the file. spamassassin-toaster-3.1.8-1.3.8 clamav-toaster-0.93-1.3.18 Thanks, John - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: [qmailtoaster] Re: spamassassin woes [was: Hello and a question.]
Eric Shubert wrote: So how does one accomplish the upgrade? It depends on which version of MakeMaker you have: # grep '^our $VERSION' /usr/lib/perl5/5.8.?/ExtUtils/MakeMaker.pm That will find version 6.44, but not earlier ones. :( Dang that MM! Try this instead: # grep '$VERSION' /usr/lib/perl5/5.8.?/ExtUtils/MakeMaker.pm | head -n1 -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Help regarding mail relay
On Wed, 14 May 2008 20:58:43 +0200, Marc Rietman wrote: Jake Vickers wrote: My reply was based on experiences with my own servers and those that I've worked on for other people/companies. The RFC is great and all but as you said there are no obligations. When it comes down to it, we follow the rules that the biggies such as AOL, Yahoo, Google, Microsoft, etc. set. I have a couple domains that have 3 MX records and I see mail delivered to all 3 machines regardless of priority or whether or not the others are answering. As far as I know that particular RFC has not been superceded but I'd say that roughly (without actually creating some boiled down metrics) 70%-80% of the servers that send me message actually follow that particular one. AOL has been seen delivering to all 3 of my MX records regardless of machine status. There's a couple other broadband companies that operate in the same manner that I've seen.Ok, that clears things up. It's obviously the usual 'standard' which we 'all' follow...Thanks for the answer, Marc This is something that worries me... Setting a secondary mail server for backup purposes means that messages will be received in duplicate in many cases? I could handle that, but for many users would (for sure) complain about it :( Or am I confusing this matter? Regards, António Lima
Re: [qmailtoaster] Help regarding mail relay
António Pedro Lima wrote: On Wed, 14 May 2008 20:58:43 +0200, Marc Rietman wrote: Jake Vickers wrote: My reply was based on experiences with my own servers and those that I've worked on for other people/companies. The RFC is great and all but as you said there are no obligations. When it comes down to it, we follow the rules that the biggies such as AOL, Yahoo, Google, Microsoft, etc. set. I have a couple domains that have 3 MX records and I see mail delivered to all 3 machines regardless of priority or whether or not the others are answering. As far as I know that particular RFC has not been superceded but I'd say that roughly (without actually creating some boiled down metrics) 70%-80% of the servers that send me message actually follow that particular one. AOL has been seen delivering to all 3 of my MX records regardless of machine status. There's a couple other broadband companies that operate in the same manner that I've seen. Ok, that clears things up. It's obviously the usual 'standard' which we 'all' follow... Thanks for the answer, Marc This is something that worries me... Setting a secondary mail server for backup purposes means that messages will be received in duplicate in many cases? I could handle that, but for many users would (for sure) complain about it :( Or am I confusing this matter? Yes, you're confusing the matter. ;) When there's a secondary server, the message will only be sent to one *or* the other, not both. Once it is sent successfully to one or the other, the sending server quits. At least it's supposed to. ;) -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [qmailtoaster] 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.5.3 - chkuser)
Actually I think I have an idea of what's going on. I have a list of my domains in teh rcpthosts config. I have it set with wildcards to my domains. If I set it to accept all domains it works, however doesn't that create an open relay? If so then disabling that rcpthosts file is out of the question. the domains I have in there are localhost Servername .domain1.com .domain2.com .domain3.com I also noticed in my locals that I didn't have all my domains in there so I added them as well. same result however... So i'm thinking that its the rcpthosts file. Is there something I can do that won't make an open relay but will at least accept email from the outside world? Glen - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.5.3 - chkuser)
Glen Vickers wrote: Actually I think I have an idea of what's going on. I have a list of my domains in teh rcpthosts config. I have it set with wildcards to my domains. If I set it to accept all domains it works, however doesn't that create an open relay? If so then disabling that rcpthosts file is out of the question. the domains I have in there are localhost Servername .domain1.com .domain2.com .domain3.com I also noticed in my locals that I didn't have all my domains in there so I added them as well. same result however... So i'm thinking that its the rcpthosts file. Is there something I can do that won't make an open relay but will at least accept email from the outside world? Glen Have these domains ever successfully received mail from outside? Did you use vqadmin to create the domains? -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
