Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm running into problems with sending mail on our webserver. Some mails are sent and delivered without any problems (eg Gmail), while others are deferred with "Sender address rejected: Domain not found"

I understand that this is a spam protection measure whereby a lookup is done on the sending domain but our domain has MX records:

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
premiumconnect.co.za    mail exchanger = 10 za-smtp-2.mimecast.co.za.
premiumconnect.co.za    mail exchanger = 10 za-smtp-1.mimecast.co.za.

Authoritative answers can be found from:    

(As an aside, why don't we have a authoritative answers? Could that be the problem?)

As well as an A record:

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   premiumconnect.co.za
Address: 196.28.97.202

Here is the logs for a specific mail that was trying to be sent:

Feb  5 12:07:52 premiumconnect sm-mta[2411]: s15C7qYp002411: from=<bookings@premiumconnect.co.za>, size=3522, class=0, nrcpts=1, msgid=<52f22998c2680@premiumconnect.co.za>, proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
Feb  5 12:07:52 premiumconnect sendmail[2410]: s15C7q0o002410: to=*****@tott.co.za, delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=33324, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (s15C7qYp002411 Message accepted for delivery)
Feb  5 12:07:52 premiumconnect sm-mta[2413]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=123522, relay=antispam-vdc-01.gam.co.za. [41.0.5.44], dsn=4.1.8, stat=Deferred: 450 4.1.8 <bookings@debian70.vm>: Sender address rejected: Domain not found
Feb  5 12:07:53 premiumconnect sm-mta[2413]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=123522, relay=mx-filter-01.gam.co.za. [41.0.5.131], dsn=4.1.8, stat=Deferred: 450 4.1.8 <bookings@debian70.vm>: Sender address rejected: Domain not found
Feb  5 12:12:46 premiumconnect sm-mta[2479]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:04:54, xdelay=00:00:00, mailer=esmtp, pri=213522, relay=mx-filter-01.gam.co.za. [41.0.5.131], dsn=4.1.8, stat=Deferred: 450 4.1.8 <bookings@debian70.vm>: Sender address rejected: Domain not found
Feb  5 12:12:46 premiumconnect sm-mta[2479]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:04:54, xdelay=00:00:00, mailer=esmtp, pri=213522, relay=antispam-vdc-01.gam.co.za. [41.0.5.44], dsn=4.1.8, stat=Deferred: 450 4.1.8 <bookings@debian70.vm>: Sender address rejected: Domain not found

I have little experience with Sendmail (or MTAs in general), not sure what other information could be useful.

share|improve this question
    
If you're not giving out Authoritative replies, you need to make sure that your domain registrar has your NS servers listed.. –  NickW Feb 5 at 14:00
    
Our domain registrar forces us to use their name servers, couldn't change if I wanted to unfortunately... –  JonoCoetzee Feb 5 at 14:31
    
Well, if you are forced to use theirs, you need to ensure that their NS servers are returning the records YOU want, and that includes a proper MX record. Also ensure that either your ISP or your hosting company publishes a proper RDNS record for your mailserver. –  NickW Feb 5 at 14:39
    
Okay, the records returned above are correct for our domain and what is set in the authoritative NS (at the registrar), including the MX record which point to an external mailserver. Also the mailserver (defined in the MX record) resolves with a reverse DNS lookup. The domain/webserver don't though, not sure if this would affect things? –  JonoCoetzee Feb 5 at 15:11
    
So, are your webservers relaying through your mailserver? That would be the simplest way to ensure that the mail they are sending will go through.. –  NickW Feb 5 at 15:16

3 Answers 3

How is it supposed to resolve the domain debian70.vm? looks to me you're using bookings@debian70.vm as the sender address. The spam check is done over debian70.vm, which can't get resolved.

share|improve this answer
    
@slm Nope. That's actually the answer imho. To me he's trying to sending mail as bookings@debian70.vm, whose domain can't get resolved by the remote server. Sorry if it's not clear, I'll modify my answer. –  stoned Feb 5 at 15:56
    
stoned is right, that is the primary issue.. a secondary one might be why his relay server is accepting addresses like that :) –  NickW Feb 5 at 16:16
    
@stoned - the edit makes it better, I've removed the comment, thanks. –  slm Feb 5 at 16:48
    
@NickW it actually seems to me he's using the local machine (127.0.0.1) to send the mail, so it works. I guess he didn't relay mail to anywhere, or else he'd probably get a failure mail rather than an error log. If that's true he'll have problems with spam checkers like SpamAssassin, but he usually won't receive any feedback for it - the message will just get discarded by the recipient's mailserver. –  stoned Feb 5 at 17:26
    
I agree, which is the reason behind my last comment under his question :) –  NickW Feb 5 at 17:28

This error is specifically regarding the 'from' address, not the sending mail server. As such, MX records are not relevant, and your MTA settings are probably not relevant.

The issue is that you're sending an e-mail from "bookings@debian70.vm", which the recipient correctly determines cannot possibly be a valid e-mail address, since the debian70.vm domain does not exist.

The solution will depend on how exactly you're generating these e-mails. One option is to specify the desired 'from' address in whatever software is generating these mails.

On the other hand it looks like you're not actively specifying a 'from' address, but letting the system generate one. In that case, the part after the @ is set based on what the system thinks is its mail name. Debian checks '/etc/mailname' to determine this, and if it doesn't find anything then it uses its fully qualified domain name, which in your case is 'debian70.vm' - a name that's only valid for your internal network since it's in the .vm top-level domain.

If you edit /etc/mailname (creating it if necessary) to say 'premiumconnect.co.za' (without the quotes), it will probably solve your problem.

If not, then that could indicate that an MTA is generating the address based on some other configuration, so we would need to know more about your MTA setup.

share|improve this answer
    
I get that, if you look at the first line in the log you'll see that that the from address is set: from=<bookings@premiumconnect.co.za>. I have have already tried setting /etc/mailname. What would cause this not to work? –  JonoCoetzee Feb 6 at 7:44
    
I tested again with Gmail and the emails are still coming through as bookings@debian70.vm? I have restarted the sendmail service but no change. –  JonoCoetzee Feb 6 at 7:46
    
I have Authentication-Warning: premiumconnect.co.za: www-data set sender to bookings@premiumconnect.co.za using -f in the mail.log, could this be related? –  JonoCoetzee Feb 6 at 7:48
up vote 0 down vote accepted

I found the problem, once I was pointed in the right direction by the other answers. The (autogenerated) sendmail.mc had a line MASQUERADE_AS(`debian70.vm')dnl, I changed this to MASQUERADE_AS(`premiumconnect.co.za')dnl and the emails are being set correctly now. Thanks for the insight.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.