Limiting outbound sendmail users

[Steven E. Protter]

One of the most annoying sendmail features is that it does not check senders.

genericstable can be used to help form senders, but its always been possible to do this:

telnet 25
helo domain.com

mail from:billybob@hpux.ws

rcpt to:spamlist@aol.com

data

lots of html spam

.


Off goes themail even though billybob is not a valid user at hpux.ws or a valid local user on the system.

This in fact is how lots of spam is relayed.

I seem to have stumbled onto a solution. I want to know if its been tried or if I'm crazy. I may be.

I add entries to the access database

myusername@hpux.ws OK
from:hpux.ws REJECT 550 Invalid sender or domain


I compile hash databases for sendmail.

Now spammer connects to sendmail and tries to send from:billybob@hpux.ws

Gets this response:
550 Invalid sender or domain.

I know this is a problem if someone outside the domain tries to send an envelope with from myuser@hpux.ws. I have no problem with this being rejected.

This configuration limits outbound senders very nicely.

Questions:
1) Have I invented something? Unlikely.
2) Anyone else doing it?
3) Have I missed anything. I can easily generate the access file with a simple script that reads genericstables, which I always felt SHOULD limit outbound senders.

I'm a generous point giver.

SEP

[Steve Lewis]

super idea.

But does it also require this line:

from :public_IP_address REJECT 550 Invalid sendor or domain

In other words can people still relay if they mail from billybob@your_IP ?

[Steven E. Protter]

Thanks.

Someone must have done this before right?

SEP

[Christopher Caldwell]

1) Have I invented something?

Check
http://www.sendmail.org/m4/anti_spam.html

It seems to point out your example. For S&G test the local user who uses your MTA as a RELAY (e.g. try to relay an e-mail from valid@hpux.ws to someone@hotmail.com).

2) Yes. Especially when you separate inbound and outbound MXes, you can make the strong argument that a valid internal user should never directly connect to the inbound MX; you can prevent that connection w/ the access db.

3) Just to make sure the logic is right, test the relay as suggested in 1), but you're on the right track.
check
local to local
local to remote (relay)
remote to local

If you haven't, you might use the virtusertable or similar to make sure mail is receivable by addressees; if not, you can reject the e-mail outright before SMTP delivers the mail payload.

[Christopher Caldwell]

I thought of one more test you need to consider:

With your access configuration, make sure an external SMTP connection (meaning mx.spammer.com) can't relay using a valid from address.

Some spammers sift through the web for valid e-mail addresses, and you don't want them to be able to use your MX to relay spam.

It might be necessary to separate inbound and outbound MXs for this technique to be valid in your environment.

[Steven E. Protter]

Thanks again.

Normal relay is shut down by normal access file.

port 25 scripting is how spammers get around the open relay. That and sendmail form abuse.

I have a port 25 scripting problem on a server with outbound mail. Its not relay because its from localhost.

SEP

[Bill Thorsteinson]

Restrict relaying by originating ip address.
This should be accomplished by relay-domains.

The telnet session orginiates off the server
and this is what should be verified in
relay domains. Using the domian on the
helo message is a serious open-relay problem.

I use Exim in preference to sendmail as
it is much simpler to implement.

Don't relay for any connections where the
helo domain does not pass reverse lookup
tests. For now you will have to accept
mail which doesn't as some major mailers
do not pass.

Consider implementing inbound SPF and reject
mail where SPF is implemented on the sending
domain and the sender doesn't pass.

[Steven E. Protter]

Yes, my current configuration does not talk to sessions with no reverse lookup.

It also ends sessions if there is a discrepency between the sending server and the MX.

Wondering how this is done:
The telnet session orginiates off the server
and this is what should be verified in
relay domains. Using the domian on the
helo message is a serious open-relay problem.
sendmail.mc ?? Bunny op!

SEP

[Bill Thorsteinson]

1) you haven't invented something.

2) Many systems implemente sender
authentication. Usually, it involves a password.

3) Standard authentication is as follows:

- Outside servers can send to any addresses
for which the server is an MX (as configured
in the server. (Relay-to addresses.) May
also restrict the originating addess to
external addresses only.
If verify is enabled, only accept for
known addresses. (Users in /etc/passwd,
aliases in /etc/aliases, other lists.)
Some users in /etc/passwd such as root may
be restricted from receiving mail.

- Inside servers can send to any address.
May restrict sending addresses based on
/etc/passwd or other user list. May
require authorization form some or all
inside addresses.

- Authorized users. Can send to inside or
outside addresses. May be allowed to send
from outside addresses. Sender address
may be restriced to authorized user if
only workstations require authorization.

[Steven E. Protter]

It seems to work very well.

I've got it working on a cluster based formation.

Only authorized users can send outbound. No impact as yet noticed on authorized users.

Didn't cost me a dime. Just some time.

Points inbound....

SEP