Re: [qmailtoaster] Re: Server Mail
Eric Shubert wrote: I'd like to know if this works, but I don't expect it will. I believe that chkuser is not finding an MX record for the backup.mydomain.com domain, and this cannot be specified in the hosts file. An MX record for backup.mydomain.dom would need to be added to the authoritative DNS for the mydomain.com domain. While this would fix the problem, I don't think it's the best solution. Fixing the problem at its source is preferable. (more on that elsewhere) Adding an entry to DNS is the correct option. If a host does not have an MX record, it should not be sending mail. If a host without an MX record sends out mail, it's assumed that it's compromised and sending spam. I also believe there is an RFC about this. Here's a hypothetical scenario: Bob has 2 servers. He sets one up as an email server and correctly adds entries to DNS to support this (A record, MX record, PTR record, etc.). Bob sets the second server up for web hosting, monitoring, whatever. There is a MTA agent on the system (we'll say Exim), but he never configured it and does not monitor it. He does however monitor his email server's logs. One day, the web server starts sending mail to everyone is can find. Bob did not intend this server to send any mail, so he never configured DNS for it to support this (no MX record, no PTR record). It's easy for us to identify that messages from this server are not desired, since Bob never configured it in DNS to send mail. How else is the rest of the world supposed to know what hosts are allowed to send mail, and those that are not? Bob opens one of these messages (since he was emailed one, and he configured his system to accept mail from invalid mail servers with no MX records) and now has a virus. His home computer is now spewing out thousands of spam messages a second to everyone in his address book. Once again, it's easy for us to identify that messages from Bob's infected home computer are safe to drop since he never set up DNS to let us know it was intended to send emails (directly). As email administrators, we have a responsibility to the rest of the world to set things up correctly. We need to let the rest of the world know that we want a specific machine to send mail by setting up the proper structure for it (MX record, PTR record, etc.). Think of the supporting entries in DNS as the license to send mail, just like you need a license to drive a car. We trust our systems (legal, DNS, otherwise) to correctly identify individuals (or machines) to do certain things (drive, send email, whatever), otherwise we have anarchy and chaos. I understand that there are exceptions to every rule, and Mike has a valid exception to the above rules. The correct way for this to occur would be to set his other system up to authenticate to one of his QMT servers so it can send mail. Then he only has to manage one thing (DNS for 1 server). I've posted about a program called email in a past post about crons that would facilitate this. Failing that, a couple simple config changes in Sendmail should fix this as well - don't ask me what they are. I only work on Qmail and Postfix and am assuming that it is easily configurable like Postfix or Qmail. Just my 2-cents. - 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: Server Mail
Maxwell Smart wrote: Like this? ip.of.server.dotted:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/private,RBLSMTPD=,NOP0FCHECK=1 ip.of.server.dotted:allow If you want to apply a line to multiple consecutive hosts, you can do this: 192.168.1.:allow,[whatever-else] This equates out to allowing 192.168.1.0/24 (192.168.1.1 through 192.168.1.254) to do whatever it is you intend it to do by adding directives. If you only want to allow a couple machines (once again, they have to be consecutive): 192.168.1.20-25:allow,[whatever] This allows the hosts 192.168.1.20 through 192.168.1.25 to do whatever it is you intend them to do in the tcp.smtp file. - 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: Server Mail
W dniu 30.10.2009 18:32, Eric Shubert pisze: While I agree with your position and hypothetical scenario, I don't believe that adding an MX record for each host is the correct nor best solution. I don't see any purpose in adding an MX record for each host that sends email. [...] That's right, have to be in DNS the MX record or A record for literal after ,,@''. -- Pozdrawiam / Regards, Aleksander Podsiadły - 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: Server Mail
W dniu 30.10.2009 20:43, Eric Shubert pisze: I'm not (necessarily) disputing that. I believe that the sending server should probably not have the host name included in the address after the @. IE @host.domain.com should simply be @domain.com, and this is configured on the sending server. One other point I'd like to make. If you create an MX record for host.domain.com, shouldn't host.domain.com also be defined in your toaster as local or alias domain? I would think it should. So now you're talking about a configuration change in DNS and the toaster for each host that's going to submit email, as opposed to (simply) configuring each server to authenticate. The later seems simpler to me. http://www.ietf.org/rfc/rfc2821.txt ,,3.6 Domains Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the rule requiring FQDNs: - The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1. - The reserved mailbox name postmaster may be used in a RCPT command without domain qualification (see section 4.1.1.3) and MUST be accepted if so used.'' -- Pozdrawiam / Regards, Aleksander Podsiadły mail: a...@westside.kielce.pl jid: a...@jabber.westside.kielce.pl ICQ: 201121279 gg: 9150578 - 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: Server Mail
Eric Shubert wrote: While I agree with your position and hypothetical scenario, I don't believe that adding an MX record for each host is the correct nor best solution. I don't see any purpose in adding an MX record for each host that sends email. An MX record is intended as an indication of where to send mail for a specific domain (destination), not an indication of 'license to send' (as you put it). It has nothing to do with a source. (Please cite an RFC if I'm wrong on this). chkuser simply uses this as a (somewhat crude) way to verify the validity of the sender's domain, in case a bounce message would need to be sent later on. Adding an MX record to allow a host with a default configuration to send mail is also dangerous and irresponsible. Giving any ol' server that can send mail by default a 'license to send email' is not (imo) a good practice. Any server that's sending mail should be properly configured, which I don't believe most default configurations are. BL, these servers in question are problematic because their default configuration is set to use acco...@host.domain.com as the sending address. While adding an MX record will indeed allow such email to pass chkuser's filter, this MX record also announces to the world that mail to host.domain.com is being accepted by the specified server in the DNS record, which is clearly not the case. I believe that properly configuring the sending server to authenticate itself, just like everyone else who submits email, is the best solution. No, a MX record is not the best choice for Mike's scenario. Don't confuse this with correct, nor twist it to mean that adding a MX record for any unconfigured host is correct or implied. We have two issues that look similar here. His best choice will be to authenticate, IMHO, and we both agree on this. RFCs do state that a domain must accept bounce messages if it sends messages (IIRC, paraphrased). How do I send a bounce to host.domain.com if there is no MX record? If you're sending as host.domain.com then there must be an MX record to accept bounces/abuse/postmaster emails. I may have misinterpreted RFCs here. No, I won't go dig up RFCs on this. If someone wants to take the time to dig them up then I'm sure we'll all be appreciative. (And why should I accept mail for a host that is incorrectly configured to send mail anyway? ) You're implying that I should change the default settings of chkuser to allow domains that do not have MX records, to make it easier to accept mail from servers that are not correctly configured, unless I'm misreading what you're typing. Seems to me this would cause one (most likely more) of 3 things: more spam in everyone's boxes additional load on spamassassin/clamav everyone to go and change the tcp.smtp file to turn MX checking back on IMHO the best choice is to leave it as is, and for those that want/need it changed to go and change it in their configuration. I'd rather not change something to make it easier for 10 people, and cause 100 other people to have to configure their systems to turn it back on. Even if it is just an entry in tcp.smtp. Not to mention documentation changes, typo-downtimes, traffic on the list, etc. A wiki page explaining how to recompile to change this setting seems the best choice for those that need to change it. - 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: Server Mail
OK, here's my setup, slightly different, but seems to be same issue. I have a production mail server it's working perfectly fine. I have a test server on the LAN 192.168.0.195 I want it to be able to send the logwatch e mails to my address on my production server, but I get this error. Connected to 64.168.70.133 but sender was rejected. Remote host said: 511 sorry, can't find a valid MX for sender domain (#5.1.1 - chkuser) My understanding is that I can make these changes change my current tcp.smtp 127.:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/private,RBLSMTPD=,NOP0FCHECK=1 :allow,BADMIMETYPE=,BADLOADERTYPE=M,CHKUSER_RCPTLIMIT=50,CHKUSER_WRONGRCPTLIMIT=10,QMAILQUEUE=/var/qmail/bin/simscan,DKSIGN=/var/qmail/control/domainkeys/%/private,NOP0FCHECK=1 to this 127.:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/private,RBLSMTPD=,NOP0FCHECK=1 192.168.0.195:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/private,RBLSMTPD=,NOP0FCHECK=1 :allow,BADMIMETYPE=,BADLOADERTYPE=M,CHKUSER_RCPTLIMIT=50,CHKUSER_WRONGRCPTLIMIT=10,QMAILQUEUE=/var/qmail/bin/simscan,DKSIGN=/var/qmail/control/domainkeys/%/private,NOP0FCHECK=1 run service qmail cdb And I should be able to send mail to the production. Is this the recommended way of doing this? I have tried and it doesn't work for me, but I will try again if this is the correct method. This is not critical nor necessary. This server will only be on the LAN for a few day. I really just want to know how it's correctly done. Eric Shubert wrote: Aleksander Podsiadly wrote: W dniu 30.10.2009 18:32, Eric Shubert pisze: While I agree with your position and hypothetical scenario, I don't believe that adding an MX record for each host is the correct nor best solution. I don't see any purpose in adding an MX record for each host that sends email. [...] That's right, have to be in DNS the MX record or A record for literal after ,,@''. I'm not (necessarily) disputing that. I believe that the sending server should probably not have the host name included in the address after the @. IE @host.domain.com should simply be @domain.com, and this is configured on the sending server. One other point I'd like to make. If you create an MX record for host.domain.com, shouldn't host.domain.com also be defined in your toaster as local or alias domain? I would think it should. So now you're talking about a configuration change in DNS and the toaster for each host that's going to submit email, as opposed to (simply) configuring each server to authenticate. The later seems simpler to me. -- Cecil Yother, Jr. cj cj's 2318 Clement Ave Alameda, CA 94501 tel 1.510.865.2787 | fax 1.510.864.7300 http://yother.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: Server Mail
Don't know if this is what you are looking for, but I have a server with an private ip of 192.168.5.15 (pluto) running sendmail. I have a qmt server with private ip address 192.168.5.2 (mercury). I want to send all email (both local and remote) from pluto through mercury. I do the following: on pluto (running sendmail). I edit the /etc/mail/sendmail.cf file. I locate these lines # "Smart" relay host (may be null) DS and replace with # "Smart" relay host (may be null) DSmercury restart sendmail /etc/init.d/sendmail restart on mercury (running qmt) I add this to my tcp.smtp file 192.168.5.15:allow,SENDER_NOCHECK="1",RELAYCLIENT="",NOP0FCHECK="1",DKVERIFY="" reload the cdb qmailctl cdb I can now send email from pluto to any email address through mercury. If this helps great. If I am doing something dangerous, please let me know. Thanks, Dave Maxwell Smart wrote: OK, here's my setup, slightly different, but seems to be same issue. I have a production mail server it's working perfectly fine. I have a test server on the LAN 192.168.0.195 I want it to be able to send the logwatch e mails to my address on my production server, but I get this error. Connected to 64.168.70.133 but sender was rejected. Remote host said: 511 sorry, can't find a valid MX for sender domain (#5.1.1 - chkuser) My understanding is that I can make these changes change my current tcp.smtp 127.:allow,RELAYCLIENT="",DKSIGN="/var/qmail/control/domainkeys/%/private",RBLSMTPD="",NOP0FCHECK="1" :allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",QMAILQUEUE="/var/qmail/bin/simscan",DKSIGN="/var/qmail/control/domainkeys/%/private",NOP0FCHECK="1" to this 127.:allow,RELAYCLIENT="",DKSIGN="/var/qmail/control/domainkeys/%/private",RBLSMTPD="",NOP0FCHECK="1" 192.168.0.195:allow,RELAYCLIENT="",DKSIGN="/var/qmail/control/domainkeys/%/private",RBLSMTPD="",NOP0FCHECK="1" :allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",QMAILQUEUE="/var/qmail/bin/simscan",DKSIGN="/var/qmail/control/domainkeys/%/private",NOP0FCHECK="1" run service qmail cdb And I should be able to send mail to the production. Is this the recommended way of doing this? I have tried and it doesn't work for me, but I will try again if this is the correct method. This is not critical nor necessary. This server will only be on the LAN for a few day. I really just want to know how it's correctly done. Eric Shubert wrote: Aleksander Podsiadly wrote: W dniu 30.10.2009 18:32, Eric Shubert pisze: While I agree with your position and hypothetical scenario, I don't believe that adding an MX record for each host is the correct nor best solution. I don't see any purpose in adding an MX record for each host that sends email. [...] That's right, have to be in DNS the MX record or A record for literal after ,,@''. I'm not (necessarily) disputing that. I believe that the sending server should probably not have the host name included in the address after the @. IE @host.domain.com should simply be @domain.com, and this is configured on the sending server. One other point I'd like to make. If you create an MX record for host.domain.com, shouldn't host.domain.com also be defined in your toaster as local or alias domain? I would think it should. So now you're talking about a configuration change in DNS and the toaster for each host that's going to submit email, as opposed to (simply) configuring each server to authenticate. The later seems simpler to me. - 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: Server Mail
Here I thought I was finally starting to understand this. :( At least the DNS part was right. Eric Shubert wrote: I'd like to know if this works, but I don't expect it will. I believe that chkuser is not finding an MX record for the backup.mydomain.com domain, and this cannot be specified in the hosts file. An MX record for backup.mydomain.dom would need to be added to the authoritative DNS for the mydomain.com domain. While this would fix the problem, I don't think it's the best solution. Fixing the problem at its source is preferable. (more on that elsewhere) Like the tcp.smtp file? Did you see the other comment by Andreas? Is that a valid fix? Maxwell Smart wrote: Mike, I am not 100% sure, but I think you can put the MX address in the host file of the server that is rejecting the mail because of an invalid sender MX domain. I am pretty sure it's because it can't resolve the address. Host file entry snip 77.60.23.95 backup.mydmain.com /snip or you may be able to add an entry in the local domain file. I believe either solution will work. Hopefully someone else can chime in to confirm. I don't think the rcpt host file allows ip addresses. CJ Mike Canty wrote: To All, I now have in place three Qmail Toaster Servers in three different locations. These servers are part of individual networks, or whish there are other CentOS and RedHat servers. I am having issues with mail from the other servers as these are running Sendmail by default. The problem lies in the fact that I can send messages from the Sendmail servers to the Toasters Servers, as long as they are within the same network and they are not an alias/forward account. The real issue is CHKUSER does its job too well and it rejects messages from the Sendmail servers, if it's to be sent to another account or network. This is the type of error I get... @40004ae9186406b54edc CHKUSER rejected sender: from r...@backup.mydomain.com:: remote backup.mydomain.com:unknown:77.60.23.95 rcpt : invalid sender MX domain I understand that there are issues with servers that are not really configured as a full Mail server, but what can I do to rectify this error. Can someone please let me know what I need to do to the sendmail.cf file to get around this. Or what needs to be done to the Qmail Toaster settings to allow the incorrect MX issue. Cheers Mike Canty -- Cecil Yother, Jr. cj cj's 2318 Clement Ave Alameda, CA 94501 tel 510.865.2787 | fax 510.864.7300 http://yother.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: Server Mail
Like this? ip.of.server.dotted:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/private,RBLSMTPD=,NOP0FCHECK=1 ip.of.server.dotted:allow Eric Shubert wrote: No. Use a separate line for that. Maxwell Smart wrote: Can multiple addresses be used in this setting? ip.of.server.dotted:allow,ip.of.server.dotted:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/private,RBLSMTPD=,NOP0FCHECK=1 Andreas Galatis wrote: Hi Mike, for my webservers, sending mail via toaster as relayserver I have the following rule in /etc/tcprules.d/tcp.smtp: ip.of.server.dotted:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/private,RBLSMTPD=,NOP0FCHECK=1 The server may relay, no authentication required. If you use spamdyke you should add the ip's in the whitelist-ip file too. Andreas Am Thursday 29 October 2009 05:31:47 schrieb Mike Canty: To All, I now have in place three Qmail Toaster Servers in three different locations. These servers are part of individual networks, or whish there are other CentOS and RedHat servers. I am having issues with mail from the other servers as these are running Sendmail by default. The problem lies in the fact that I can send messages from the Sendmail servers to the Toasters Servers, as long as they are within the same network and they are not an alias/forward account. The real issue is CHKUSER does its job too well and it rejects messages from the Sendmail servers, if it's to be sent to another account or network. This is the type of error I get... @40004ae9186406b54edc CHKUSER rejected sender: from r...@backup.mydomain.com:: remote backup.mydomain.com:unknown:77.60.23.95 rcpt : invalid sender MX domain I understand that there are issues with servers that are not really configured as a full Mail server, but what can I do to rectify this error. Can someone please let me know what I need to do to the sendmail.cf file to get around this. Or what needs to be done to the Qmail Toaster settings to allow the incorrect MX issue. Cheers Mike Canty --- -- 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 -- Cecil Yother, Jr. cj cj's 2318 Clement Ave Alameda, CA 94501 tel 510.865.2787 | fax 510.864.7300 http://yother.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: Server Mail
Eric, You are correct in the fact that the host file did not fix the issue. Neither did adding the IP to the tcp.smtp file change. Like you suggested, fixing the problem at the source is preferable. Can you suggest what needs to be changed in the sendmail.cf file, or should I be changing to postfix, as suggested by some others? Please let me know, and keep those suggestions coming. Cheers -Original Message- From: news [mailto:n...@ger.gmane.org] On Behalf Of Eric Shubert Sent: Friday, 30 October 2009 2:56 AM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Re: Server Mail I'd like to know if this works, but I don't expect it will. I believe that chkuser is not finding an MX record for the backup.mydomain.com domain, and this cannot be specified in the hosts file. An MX record for backup.mydomain.dom would need to be added to the authoritative DNS for the mydomain.com domain. While this would fix the problem, I don't think it's the best solution. Fixing the problem at its source is preferable. (more on that elsewhere) Maxwell Smart wrote: Mike, I am not 100% sure, but I think you can put the MX address in the host file of the server that is rejecting the mail because of an invalid sender MX domain. I am pretty sure it's because it can't resolve the address. Host file entry snip 77.60.23.95 backup.mydmain.com /snip or you may be able to add an entry in the local domain file. I believe either solution will work. Hopefully someone else can chime in to confirm. I don't think the rcpt host file allows ip addresses. CJ Mike Canty wrote: To All, I now have in place three Qmail Toaster Servers in three different locations. These servers are part of individual networks, or whish there are other CentOS and RedHat servers. I am having issues with mail from the other servers as these are running Sendmail by default. The problem lies in the fact that I can send messages from the Sendmail servers to the Toasters Servers, as long as they are within the same network and they are not an alias/forward account. The real issue is CHKUSER does its job too well and it rejects messages from the Sendmail servers, if it's to be sent to another account or network. This is the type of error I get... @40004ae9186406b54edc CHKUSER rejected sender: from r...@backup.mydomain.com:: remote backup.mydomain.com:unknown:77.60.23.95 rcpt : invalid sender MX domain I understand that there are issues with servers that are not really configured as a full Mail server, but what can I do to rectify this error. Can someone please let me know what I need to do to the sendmail.cf file to get around this. Or what needs to be done to the Qmail Toaster settings to allow the incorrect MX issue. Cheers Mike Canty -- -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 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
