From: L. D. James on
Can someone advise me what information I will need to look up to
identify or fix this problem.

Server A (mail server) is my main site. Service B (backup or
secondary mail server) is set as the overflow server with the MX
records set as:

MX 0 server.A
MX 10 server.B

It seems that server B is accepting and buffering messages to all type
of bogus names(a)serverA. When they are unknown users to server A, the
messages are sent back to the address of the sender. Some of the
messages are sent to root of server B.

This appears to be a flaw. It seems that a person could create a
“from” address to someone they want to have email sent (returned to)
and send something to a bogus user and have my server return something
unsolicited to an innocent person.

My server B is buffering hundreds of pieces of mail with bogus
addresses. My server B is a secondary name server for server A, so
idealistically there would be a feature for server B to lookup the
userID without having to wait for server A to report no such user, and
refuse to accept the email in the first place, rather than accepting
and buffering it.

The logs show the following is an example of the entries. “hepfer” is
one of hundreds of names and variations of names that doesn’t exist on
my system:

-----
Apr 20 00:59:42 ares sendmail[14299]: m3K4xFhV014279:
to=<hepfer(a)apollo3.com>, delay=00:00:09, xdelay=00:00:08,
mailer=esmtp, pri=
121932, relay=mail.apollo3.com. [216.153.132.70], dsn=5.1.1, stat=User
unknown
---------


Maybe there is a sendmail.mc (or access) entry that addresses this
issue.

I would be glad to provide any other information needed for
identifying the problem.

Thanks in advance for any suggestion on this matter.

-- L. James

--
L. D. James
ljames(a)apollo3.com
www.apollo3.com/~ljames
From: D. Stussy on
"L. D. James" <ljames(a)apollo3.com> wrote in message
news:3e88ae23-ed30-4442-a18e-29bd20a7502c(a)l42g2000hsc.googlegroups.com...
Can someone advise me what information I will need to look up to
identify or fix this problem....



LDAP on server B - with a list of server A's users.


From: Victor Sudakov on
L. D. James wrote:
> Can someone advise me what information I will need to look up to
> identify or fix this problem.

> Server A (mail server) is my main site. Service B (backup or
> secondary mail server) is set as the overflow server with the MX
> records set as:

> MX 0 server.A
> MX 10 server.B

> It seems that server B is accepting and buffering messages to all type
> of bogus names(a)serverA. When they are unknown users to server A, the
> messages are sent back to the address of the sender.

On server B you should use an MTA which can do recipient verification
(AKA recipient callout AKA call ahead). Exim can do this out of the box.
There is also a commercial milter for sendmail:
https://www.milter.org/milter/17

--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49(a)fidonet http://vas.tomsk.ru/
From: L. D. James on
Res wrote:
> On Mon, 21 Apr 2008, Victor Sudakov wrote:
>
> > There is also a commercial milter for sendmail:
> > https://www.milter.org/milter/17
>
> or you can use a free milter, smf-sav, which works exceptionally well in
> large installations, see http://smfs.sourceforge.net
>

All the methods, at an over view, seems to suggest the key is to check
for a list of users. I guest there isn’t a method that could just
check against the users that can actually log into system B, since
it’s connected via NIS (it also serves as a secondary NIS server)… it
provides authentication for other servers in the network. So it
already has all the names. In fact it successfully serves as the smtp
server.

With this in mind, it might just be a matter of activating an already
standard sendmail.mc option.

I should have included this information in my original post.

-- L. James

--
L. D. James
ljames(a)apollo3.com
www.apollo3.com/~ljames
From: Victor Sudakov on
Res wrote:

> > There is also a commercial milter for sendmail:
> > https://www.milter.org/milter/17

> or you can use a free milter, smf-sav, which works exceptionally well in
> large installations, see http://smfs.sourceforge.net

Thanks, I did not know about it.
And it's already in the FreeBSD ports collection.

--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49(a)fidonet http://vas.tomsk.ru/