ot a bit: sendmail and TO mx not found

[Rick Cooper]

rfc5321 does not say that, as I read it. It says:
 
The lookup first attempts to locate an MX record associated with the

   name.  If a CNAME record is found, the resulting name is processed as

   if it were the initial name.  If a non-existent domain error is

   returned, this situation MUST be reported as an error.
 
You cannot report as error and continue on with delivery, this doesn't mean
log an error it means
cease and report as error ( not even defer). Assuming this is what you are
speaking of the correct
thing to do would be to try the primary and (assuming it returned a cname)
stop the delivery attempt
when it cannot be resolved.

  _____  

From: mailscanner-bounces at lists.mailscanner.info
[mailto:mailscanner-bounces at lists.mailscanner.info] On Behalf Of Joolee
Sent: Tuesday, September 02, 2014 10:37 AM
To: MailScanner discussion
Subject: Re: ot a bit: sendmail and TO mx not found


rfc5321 section 5 indicates that Sendmail should try the server(s) to whom
the alternative MX records point. It shouldn't try all multihomed A records
pointed to by a single MX record (although, that's not exactly what the RFC
says) but that's not the case here. So the question still is, why doesn't
Sendmail try the alternative MX records?



On 2 September 2014 14:39, Peter Farrow <peter at farrows.org> wrote:


If the primary MX does not resolve , sendmail will not try a lesser MX
record, because the best option is unresolvable, so it will return the
message after checking and appending any search parameters given in
/etc/resolv.conf.

This behaviour is by design, and you are trying to fix a problem which is
inherently not yours to solve.

If the primary MX does not resolve : The domain is broken - so why try and
work around that? 






On 02/09/2014 13:19, ja at conviator.com wrote:


hi
 
its a bit OT but I hope its OK anyway. We are also using Mailscanner as
outbound scanner and see a problem that I cannot figure out - probably some
setting im missing. 
 
sometimes "we" send emails to a domain where the primary MX record does not
resolve. I would have expected that sendmail would just try the next but
instead it resolves to mxrecord.name.OURDOMAIN.COM (I think) - it seams it
appends our domain and then tries this server and this server says "no
thanks" so the delivery fails. 
 
I tried to lookup the MX myself using the same nameserver as the mailscanner
server is using - this fails so its not the DNS server that appends
something to make it resolveable or gives out a standard IP. 
 
I also checked the resolve file to check that there is not search setting
that would make it search our domain for a valid IP/lookup. 
 
how can I stop this behavior and make it try the next MX in line? 
 
best regards
Jan
 

-- 
This message has been scanned for viruses and 
dangerous content by the  <http://www.togethia.net/> Togethia MailScanner,
and is 
believed to be clean. 
Scanner:local 
 


-- 

horizontal ruler 	
Peter Farrow	
avatar 	
______________________	
Home:	 01249 654183	
Fax:	 01249 461 548	
Mobile:	 07799605617	
Skype:	 peter_farrow	
Web:	 www.peterfarrow.com	

	


--
MailScanner mailing list
mailscanner at lists.mailscanner.info
http://lists.mailscanner.info/mailman/listinfo/mailscanner

Before posting, read http://wiki.mailscanner.info/posting

Support MailScanner development - buy the book off the website!




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mailscanner.info/pipermail/mailscanner/attachments/20140902/37a49564/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 57 bytes
Desc: not available
Url : http://lists.mailscanner.info/pipermail/mailscanner/attachments/20140902/37a49564/attachment-0002.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 8198 bytes
Desc: not available
Url : http://lists.mailscanner.info/pipermail/mailscanner/attachments/20140902/37a49564/attachment-0003.gif