How can I set up sendmail to accept mail from ANY domain, yet relay only to one domain?

[Rory O'Rourke]

Have an environment, where a mail-relay system, ( HPUX 11.11, sendmail 8.9.3 ), could receive mail from customers at any domain. This system would also then ony relay mail that was addressed to a specific domain.

Tried using mailertable, with the additional "wildcard", i.e.

'. error:553 deny-text'

This worked absolutely great, unfortunately too great - this would also deny mail coming *in* from other than the specified domains in mailertable, as well as denying relaying to domains other than what was specified. (in mailertable)
How can I set up relaying to one domain, while also accepting mail from any domains ( I know that this sorta defeats the purpose of the security tools in sendmail - cannot get around this unfortunately )

Thanks,
Rory.

[Steven E. Protter]

in the file /etc/mail/access

Set your internal domain name and ip addressed in this database with RELAY in the second field. Tabs delimited.

Be careful, any outside addresses in there and you'll be picked up by the spammers and used to relay mail.

Then generate a sendmail.cf file using gen_cf or this scrpt:

http://www.hpux.ws/buildmail.hpux.text

Sendmail outside of the box will accept mail from any domain, this is the default behavior.

SEP

[Rory O'Rourke]

Steven - thanks.
OK, understand the "out of the box" behaviour. But I have already tried using the access file, and did not get the results I needed. Not sure whether this was related to the test environment - perhaps you could answer this? I set up the the access file as described on the relay system. To test this, I telnet'd to port 25 on the relay system, from another system in the *same* domain as the relay system. I am concerned that this detail is skewing this test? i.e. when I specified "rcpt to: joe@otherdomain.com", instead of denying it, it accepted and queued the mail. I was thinking it only did this because I had telnet'd from another system in the same domain. Is this true, or am I on he wrong track?
Also, during a discussion with a co-worker, he asked why I did not just use "Smart Relay", i.e. DS? I guess I must be getting confused, because I could not provide an answer why setting Smart Relay would not work? Is this also true - could Smart Relay do what I want to do, i.e. send all mail destined for one specific domain, to another mailserver?

Sorry - realize I double-dipping, but my bain is fried right now trying to sort this out!
Rory.

[Steven E. Protter]

Don't worry about double dipping. The priority of itrc is providing help. Points are merely an incentive.

Let me give you better testing methodology:

sendmail -v -d8.99 -d38.99 someone@someaddress.com

type some text

.


This will give you full diagnostics about what the heck is going on with your mail right now.

It could point out a DNS resolution problem which might cause routing problems.

make sure /etc/nsswitch.conf is set to use DNS, its awfully hard to resolve outside mail addresses without it.

check that /etc/resolv.conf servers are valid and actually provide answers.

nslookup or dig command for that.

Accepting mail from any domain isn't a big deal.

You will find domains like china.com or hongkong.com (these are examples, there are many) are filled with nasty spammers and the admins don't respond to complaints. To reject their mail, just do a

badspammer.com REJECT 550 Bad Spammer

line in the access file.

Other useful tools

mailq is mail actually getting off your system.

sendmail -v -q

Try to clear the mailqueue in verbose mode, provides diagnostics.

Eventually, to really help, I'm going to need to actually see some error output. What happened and what you really want to happen.

Glad to help, please provide me with a little more tools please.

There is a good resource at http://www.sendmail.org as well for questions and an overview that might get you through this without my help.

If you decide to do m4 macro programming, use my script, the stock stuff posted at sendmail.org will not work.

SEP

[Steven E. Protter]

Lighbulb just went off.

Relay to,

not relay from like my brain misfired.

You want all mail from this server relayed to another domain? Another server?

Easy.

DS directive.

in sendmail.cf

DS
[ip address or hostname of relay server]

save the file.

/sbin/init.d/sendmail stop
/sbin/init.d/sendmail start

Done.

Or do I still not totally understand the question.

SEP

[Berlene Herren]

The access.db is used for antispam rules, where you can allow a machine to relay through you, block email (going and coming) and explicitly deny others.

If sendmail is configured correctly, then you will be able to accept mail from any domain, unless it is filtered at the smart host.

Steven is right, setting the DS in /etc/mail/sendmail.cf will point your system to that mail server that will then send your mail to the internet.

Example
DSmail.exchange.com

Be sure to recycle sendmail after making any changes to the .cf.

If you cd to /usr/newconfig/etc/mail/cf/cf and then issue #./gen_cf and return, you will see the different options you have available, generating a new sendmail.cf file with one or more of those options. To see what each does and how it is configured, type H .

In sendmail 8.11.1, you have 24 options, versus the 13 available in 8.9.3.

If I type H 21 in sendmail 8.11.1, this is what I get for mailertable;

Include a "mailer table" which can be used to override
routing for particular domains (which are not in class {w},
i.e. local host names). The argument of the FEATURE may be
the key definition. If none is specified, the definition
used is:

hash /etc/mail/mailertable

Keys in this database are fully qualified domain names
or partial domains preceded by a dot -- for example,
"vangogh.CS.Berkeley.EDU" or "CS.Berkeley.EDU" As a
special case of the latter, "." matches any domain not
covered by other keys. Values must be of the form:
mailer:domain
where "mailer" is the internal mailer name, and "domain"
is where to send the message. These maps are not
reflected into the message header. As a special case,
the forms:
local:user
will forward to the indicated user using the local mailer,
local:
will forward to the original user in the e-mail address
using the local mailer, and
error:code message
error:D.S.N:code message
will give an error message with the indicated SMTP reply
code and message, where D.S.N is an RFC 1893 compliant
error code.

Rambling on, sorry :-)

Berlene

[Rory O'Rourke]

Howdy Berlene - thanks for your response.

I did try the access DB, but it would accept a "rcpt to:" that was destined to a domain other than the company domain.? As I mentioned in my last response to Steven, I was wondering whether this was caused by the fact that I was telnet'ing to the relay system's port 25 to do this test, from another UNIX system that was in the same domain as the relay system. Is this a factor?

In your description for using access DB, you mentioned "coming and going". That is exactly the issue I am afraid. i.e. access DB controlled "mail from:" and "rcpt to:".
Any way we can just get it to handle the "rcpt to:" part? :)

Does the "relay-domains" file also control "coming and going" mail?

This is an internal system at a DR site, that needs to relay ALL mail to a mailserver at the Production site, if the mail is destined for a specific domain. This relay system, and the mail system, are both in that same specific domain mentioned above.

The "type" of mail it will receive is the following:
1. "Normal" mail generated by employees at the DR site, destined for other employees within the company
2. DB/application created mail (customers), that could have "from" email addresses with ANY domain, that is destined to employees or Helpdesk, again, only to the "specific domain" I referred to above.

It is the mail traffic from (2) above, that is what I am trying to sort out. If I create a mailertable, with the error "wildcard", it will ONLY allow traffic, coming AND going, for the company domain, and deny incoming mail from the customer's domains.

I thought that if I remove the "wildcard" line from the mailertable, and created a relay-domains file, that this would then allow me to route mail as required, but I did not get the results I needed - it would still accept a "rcpt to:" that was destined to a domain other than the company domain.

Talk about rambling!! Sorry, just trying to paint the picture.

Thanks,
Rory.

[Berlene Herren]

Take a look at the release notes for 8.9.3, page 17 for some of the header checks that are available in this version:

http://docs.hp.com/hpux/onlinedocs/5969-4321/5969-4321.pdf

Support for New Mailer Delivery Agent and Map

Perhaps one of these can be configured to do what you want it to do.

Also in the 8.11.1 release notes:

Finer spam control by using tags for the LHS of the access map

You can now tag entries in the access map based on their type. Three tags are available. They are:
Connect: connection information (${client_addr}, ${client_name})

From: sender

To: recipient

If the required item is looked up in a map, it will be tried with the corresponding tag in front, then without any tag (as fallback to enable backward compatibility). For example,

From:spammer@some.dom REJECT

To:friend.domain RELAY

Connect:friend.domain OK

Connect.from.domain RELAY

From:good@another.dom OK

From:another.dom REJECT

http://docs.hp.com/hpux/onlinedocs/5990-6693/5990-6693.html

Berlene

[Rory O'Rourke]

Howdy again Berlene,

Thanks for your latest response.
Yes, it does look like upgrading off of 8.9.3 will provide the functionality, - through the access DB -, that I am looking for.
With the newer versions, the extra granularity of access DB should allow specifiying accepting "mail from:" anyone, but only if the "rcpt to:" is addressed to the specific domain.

Still need to do this and test.

Thanks again,
Rory.