My Secondary Mail Server is downloading and resending Bogus Emails?

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@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
=93from=94 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. =93hepfer=94 is
one of hundreds of names and variations of names that doesn=92t exist on
my system:

-----
Apr 20 00:59:42 ares sendmail[14299]: m3K4xFhV014279:
to=3D, delay=3D00:00:09, xdelay=3D00:00:08,
mailer=3Desmtp, pri=3D
121932, relay=3Dmail.apollo3.com. [216.153.132.70], dsn=3D5.1.1, stat=3DUser=

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@apollo3.com
www.apollo3.com/~ljames

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

"L. D. James" wrote in message
news:3e88ae23-ed30-4442-a18e-29bd20a7502c@l42g2000hsc.google groups.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.

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

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@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@fidonet http://vas.tomsk.ru/

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

Post removed (X-No-Archive: yes)

Re: My Secondary Mail Server is downloading and resending Bogus

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=92t a method that could just
check against the users that can actually log into system B, since
it=92s connected via NIS (it also serves as a secondary NIS server)=85 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@apollo3.com
www.apollo3.com/~ljames

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

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@fidonet http://vas.tomsk.ru/

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

Post removed (X-No-Archive: yes)

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

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.

> no worries, but be careful if you elect to use its 'sender' verification,
> that tends to annoy some of the people who have nothing better to do then
> sit there watching their logs :)

I suppose you mean SMTP callback by "sender verification". I still
doubt if SMTP callback is a good idea at all. Can't it be used for
example to DoS innocent third parties? Or make an innocent SMTP server
connect to a spamtrap?

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

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

Post removed (X-No-Archive: yes)

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

On 04/22/08 03:09, Victor Sudakov wrote:
> I suppose you mean SMTP callback by "sender verification". I still
> doubt if SMTP callback is a good idea at all. Can't it be used for
> example to DoS innocent third parties? Or make an innocent SMTP
> server connect to a spamtrap?

I've been running "sender verification" (SMTP callback) on our main
servers for a few years now. Other than a few problem systems (I'll get
to in a moment) I've had very little problem with "sender verification".

If someone spoofs a sending email address (Joe Job) when sending spam,
inbound sender verification is not going to be their top concern. If
the spoofed victim is publishing SPF and the recipients are running SPF
filters this will not be a problem at all. With that said, will the
"sender verifications" increase the traffic on a spoofed victim, yes.

I don't think "sender verification" should cause a server to trigger a
spam trap. A) I don't think it very likely that you will be receiving
an email "From" a spam trap email address. If you do receive an email
from a spam trap email address it is a spoof. B) Spam traps *SHOULD*
be aware of sender verification and only trigger when you actually send
a message in to them. Seeing as how sender verification does not do
this, you should be fine.

That being said I believe there is at least one list that is just
systems that do sender verification. If someone chooses to use such a
list and decides not to accept SMTP connections (or 550s them) from
people on these list, they quite simply will not send email to any one
on the list either. That is their choice to shoot them selves in the foot.

Personally I think "sender verification" and "gray listing" are WONDERFUL!



Grant. . . .

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

In article
net>,
Grant Taylor wrote:

> On 04/22/08 03:09, Victor Sudakov wrote:
> > I suppose you mean SMTP callback by "sender verification". I still
> > doubt if SMTP callback is a good idea at all. Can't it be used for
> > example to DoS innocent third parties? Or make an innocent SMTP
> > server connect to a spamtrap?
>
> I've been running "sender verification" (SMTP callback) on our main
> servers for a few years now. Other than a few problem systems (I'll get
> to in a moment) I've had very little problem with "sender verification".
>
> If someone spoofs a sending email address (Joe Job) when sending spam,
> inbound sender verification is not going to be their top concern. If
> the spoofed victim is publishing SPF and the recipients are running SPF
> filters this will not be a problem at all. With that said, will the
> "sender verifications" increase the traffic on a spoofed victim, yes.
>
> I don't think "sender verification" should cause a server to trigger a
> spam trap.

You don't get a vote. :)

People owning trap addresses deal with traffic to them in a wide variety
of ways that suit them. There are trap addresses that should only get
hit by a RCPT under very narrow circumstances, such as a dictionary
attack or indistinguishably abusive behavior like SAV.

> A) I don't think it very likely that you will be receiving
> an email "From" a spam trap email address. If you do receive an email
> from a spam trap email address it is a spoof.

You mean, like 90%+ of all mail?

> B) Spam traps *SHOULD*
> be aware of sender verification and only trigger when you actually send
> a message in to them.

That's arguable.

> Seeing as how sender verification does not do
> this, you should be fine.

Until someone hits your mail server with spam from a long list of
different addresses in one domain and you perform a dictionary attack on
that domain's mail server in response.

Before you say that a SAV flood it is not a dictionary attack, think
carefully.

> That being said I believe there is at least one list that is just
> systems that do sender verification. If someone chooses to use such a
> list and decides not to accept SMTP connections (or 550s them) from
> people on these list, they quite simply will not send email to any one
> on the list either. That is their choice to shoot them selves in the foot.
>
> Personally I think "sender verification" and "gray listing" are WONDERFUL!

Graylisting has some bad failure modes due to careless senders
(including some transactional senders like Southwest Airlines who never
retry...) but it at does work reasonably well if your users are willing
to wait a while for some messages.

SAV exports some of your spam detection load to innocent third parties
whose only involvement with your mail is having their addresses forged.
It is abusive behavior.

--
Now where did I hide that website...

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

Bill Cole wrote:
[dd]

> >
> > Personally I think "sender verification" and "gray listing" are WONDERFUL!

> Graylisting has some bad failure modes due to careless senders
> (including some transactional senders like Southwest Airlines who never
> retry...) but it at does work reasonably well if your users are willing
> to wait a while for some messages.

> SAV exports some of your spam detection load to innocent third parties
> whose only involvement with your mail is having their addresses forged.
> It is abusive behavior.

IMHO gray listing is also abusive because it exports some of your spam
detection load to the innocent sender, who has to queue the message
instead of delivering it at once.

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

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

Post removed (X-No-Archive: yes)

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

Hi Res

Res wrote:
> On Thu, 24 Apr 2008, Victor Sudakov wrote:..
>
> (waits for the "if it's that critical they should use facimile" brigade
> *shakes head*)

Don't wait any longer :-)

Mail servers may queue for any old reason, including being swamped with
spam, so anyone trying to use mail for mission critical purposes (like
10^8 $ contracts) should be thinking twice about their business model.
If you need real time then use some instant messaging protocol.

2 * 10^-2 $

Erich

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

Res wrote:

> >
> > IMHO gray listing is also abusive because it exports some of your spam
> > detection load to the innocent sender, who has to queue the message
> > instead of delivering it at once.

> Agreed, but those using it never see it that way do they, and they clearly
> don't have mission critical clients, who get upset if the mail doesn't
> arrive in 1 minute let alone 10mins to an hour or more, because it could
> mean the difference between getting that 100mil dollar contract and not
> getting it, it could differ the outcome of a legal hearing, and so on.

I don't care a groat about their clients, it is my mail server's load
that concerns me.


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

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

Post removed (X-No-Archive: yes)

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

On 04/24/08 06:39, Res wrote:
> My point exactly, and like you, I'll do whatever it takes to minimise
> the impact on my servers, besides, many modern day spam engines honour
> the 4xx, I mean did whoever thought up lame-listing ever think it would be
> the answer, did they not think it would not take long at all before the
> low lifes woke up to how it works and cater for that in modern day
> engines, sure, a great many are still the brain dead old engine, but
> many, especially from asia, are the newer modern greylist intelligent
> defeating ones.

What technique is timeless? Just about any spam defense technique out
there will be overcome eventually. Is it time for gray listing to be
retired, I don't know, nor do I think so (yet). However the day will
come when gray listing does very little good while annoying others more so.

Now for the flip side of the coin, some gray listing implementations out
there only gray list the first time a set is seen, that set being
sending IP, sending email address, and recipient email address. Once
the set has been seen and cached any future messages matching that set
are allowed through immediately with out gray listing. Also, you can
alter what is defined as the set, the IP can be expanded with a netmask,
and the sending and recipient address can be expanded to the domain.
Thus john@doe.com sends from a.b.c.d to bob@tom.com @doe.com from
a.b.c.d/x to @tom.com is now considered good.



Grant. . . .

Re: My Secondary Mail Server is downloading and resending Bogus Emails?

In article ,
Victor Sudakov wrote:

> Bill Cole wrote:
> [dd]
>
> > >
> > > Personally I think "sender verification" and "gray listing" are WONDERFUL!
>
> > Graylisting has some bad failure modes due to careless senders
> > (including some transactional senders like Southwest Airlines who never
> > retry...) but it at does work reasonably well if your users are willing
> > to wait a while for some messages.
>
> > SAV exports some of your spam detection load to innocent third parties
> > whose only involvement with your mail is having their addresses forged.
> > It is abusive behavior.
>
> IMHO gray listing is also abusive because it exports some of your spam
> detection load to the innocent sender, who has to queue the message
> instead of delivering it at once.

I have a very hard time calling that abusive, since the sender is asking
for a service (delivery) that he has no inherent right to receive at
all, much less on some particular timetable. There are a lot of
perfectly normal reasons for a MTA to tempfail a message other than
graylisting, and a sending server that has problems with graylisting
probably needs rethinking.

--
Now where did I hide that website...