domain.com requires valid sender domain

[Fred Martin_1]

My root mail keeps getting messages that are bouncing back from mail servers with the message:

domain.com requires valid sender domain

Most of the time it seems to be return receipts. For example someone at domain.com sends one of my users an email. My user's mail client tries to return a notification of receipt. But domain.com rejects it.

It appears that our outgoing email has a hostname attached:

corp.applicatorssales.com

The name corp can't be looked up via DNS and that's probably why the servers are rejecting it (if they are configured to require a valid domain).

Anyway, I can't figure out how to get 'corp' off of there.

In my sendmail config, both DS and DM are null.

Fred

p.s. this might be related to the fact that we have one mail server and three domains, public DNS resolves our three domain names to one address. In my sendmail.cw file, all three domains are listed so that the sendmail server accepts for all three domains.

[Steven E. Protter · Accepted solution]

My mail server as well, will reject any email from a server that does not have a domain name that can be verified as valid via a dns lookup.


Couple ways to fix this:

1) change the hostname in /etc/rc.config.d/netconf to a fully qualified valid domain name. This solution is elegant because you don't have to maintain a sendmail macro file, all outbound mail will have this domain name.

2) Because our internal policy would not allow it, we had to implement a smtp relay policy which forwards mail from our unix servers to the public internet. That server does not change the name which necessitates me to implment the Dj directive in sendmail.cf

Djyourhost.com

save sendmail.cf

restart sendmail.

You can achieve the same thing via sendmail macro with the

MASQUERADE_DOMAIN(some.net)dnl

and or the:

Cwsome.net

or the

MASQUERADE_AS('some.net')dnl

directive.

Which you use depends on whether you are hosting multiple domains on your server.

I'm linking a script that makes using sendmail macros easy on hp-ux.

http://www.hpuxconsulting.com/buildmail.hpux.text

Don't have any idea why hpux.ws is down but the above name is a mirror.

SEP

[Sanjay_6]

Hi Fred,

Try this link from ITRC,

to masquerade individual id's,

http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000068402500

the doc id is KBRC00010421.

to masquerade all emails,

http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000062907049

the doc id is IVKBRC00006781.

Hope this helps.

Regds


Also you can try,

[Fred Martin_1]

Sanjay,

That userdb thing in the first link is exactly how we masquerade the users now. We have three email domains on the one server. DNS and the sendmail.cw file is how we get incoming email for all three domains, into the one sendmail server. The userdb maildrop/mailname is used so that outgoing email appears to come from the appropriate domain, depending on who the user is.

That all works well from the user's point of view.

The trouble is, other servers - if they require a valid domain - are not fooled by that. In our mail header is the real name but it unfortunately includes the hostname too: corp.applicatorssales.com

That seems to be the trouble. If I could get 'corp' out of there I think I'd be OK as 'applicatorssales.com' is valid and a reverse lookup can be done.

I don't know why 'corp' is showing up. I was sure that DS and DM both being blank would solve it.

[Sanjay_6]

Hi Fred,

I've used the DM macro before and it masquerades everything. So if the DM macro is set as

DMtest.com

mail sent by say root of this server will appear as root@test.com

don't forget to comment the CE macro "CE root" since by default this will not masquerade emails from root if CE root is uncommented.

The problem with this was that it masqerades all the email that goes out of the server (global) and hence we need to dif deeper if we are receiving emails from the box and need to find which server has sent that mail. That was the reason my first choice would be to use userdb.

I'm also exploring the "-r" option at present for one of our users.

cat some_file |mailx -r sender_add -s "subject" receiver_add

Hope this helps.

Regds

[Steven E. Protter]

Fred,

scan the configuration files for the term corp. Unless corp is part of your domain name this should not be a problem.

cd /etc/sendmail ( can't remember where it is)

find . -exec grep -l -i 'corp' {} \;

You might want to do the same thing in /etc

If you find corp, thats the target. The MASQUERADE_AS directive should however override all the settings in the .mc file anyway.

SEP

[Fred Martin_1]

Mmm. Perhaps instead of being null, DM should be set to:

DMapplicatorssales.com

Would that force the 'corp' out of there? Or would that screw up my maildrop/mailname thing that I'm trying to do?

[Sanjay_6]

Hi Fred,

Only a trial would say what would happen. I've never tried both the DM macro and the userdb at the same time on the same server. My guess is that once you use the DM macro it is going to change the sender domain for all mails irrespective of what you have configured as mailname:maildrop in the userdb file.

But a test is the best answer. You can do this and revery the change if necessary since this can be done on the fly.

Hope this helps.

Regds

[Fred Martin_1]

Yeah if I put this in:

DMapplicatorssales.com

Then it overrides the other two domain names and so makes the userdb innefective.

So, still looking for a solution.

[Fred Martin_1]

Here's an example. This email was sent by one of my users, to a free web email account outside of our network. Because of the userdb, the return path is correctly shown as paradigmwindows.com ... but 'corp' is what is what can't be looked up by other servers.

----
Return path

Received: from corp.applicatorssales.com ([64.223.200.138]) by ...blahblah
----

I suppose I could add a record to the public DNS for 'corp' so that it resolves to us, but I'm trying to hide that name.

[Fred Martin_1]

Well I thought I'd be clever and do this:

DMmail

...because there is a public DNS record that resolves 'mail' to our public IP address.

Alas, then people get:

From: "Fred Martin"

And with this:

DMmail.applicatorssales.com

...the userdb is foiled.

[Sanjay_6]

Hi Fred,

Let us see if we can help you over here.

Do this,

sendmail -v some_email_add@some_domain.com

type your text here

.

This will generate some message. Copy and paste it and attach it for us to look at.
you can also use -d8.99 38.99 with the sendmail command "sendmail -v -d8.99 38.99 some_email_add@some_domain.com"

Also tell us what the final email look like and what you want it look like. If required we may want you to attch your sendmail.cf and the userdb file. Can you do that. What version of sendmail you are using. get this by "what /usr/sbin/sendmail".

Hope this helps.

Regds

[Fred Martin_1]

I've discovered a new twist. The problem only seems to be when our server tries to send back return receipts.

In other words, fred@comcast.net sends an email to one of my users. They read the email, and the return receipt is sent back to comcast.net (by Eudora or Outlook using our sendmail server for SMTP). comcast.net rejects the email, since they require a valid domain.

However, if my user replies to the email, it is delivered just fine, comcast.net accepts it OK.