RE: I5 smtp and spamcop

It is not a relay, but a cleverly crafted email to no
one@xxxxxxxxxxxxxx, with the sender ID of the real destination. That
way if your gateway accepts all incoming email and then forwards to your
internal server, your internal server sends the email back to the phony
sender as a NDR. Your gateway needs to validate all incoming email
recipients and reject if the recipient is an invalid email address.

Christopher Bipes
Information Services Director
CrossCheck, Inc.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rich Loeber
Subject: Re: I5 smtp and spamcop

JK,

Check your SMTP attributes (CHGSMTPA and F4 prompt it) and see what
your
relay setting is set to. If it is set to *ALL, then your SMTP server
is
an open relay and they have a legitimate complaint. If it is set to
*NONE
or *LIST, then they are all wet.

Rich Loeber
Kisco Information Systems
http://www.kisco.com


------------------------------------------------------------------------
--

johnking@xxxxxxx wrote:

All,

I've wasted the better part of a day fighting with spamcop.net.
They
claim our
i5 smtp/pop3 server is a spam source because of "Misdirected
bounces".
See below
for their FAQ entry. I am relatively certain that the i5 only
accepts
inbound
smtp if an entry has been made in the SDD via WRKDIRE and that
there is
no such
thing as a "delayed bounce" in i5-land. Would someone be kind
enough to
confirm
this or help me understand what I'm missing?

Many thanks, JK

"Problem: Misdirected bounces
Description: When a mail server accepts a message and later
decides
that it
can't deliver the message, it is required to send back a bounce
email to
the
sender of the original message. These bounce emails are often
misdirected.

Solution: Upgrade and/or configure your mail server software so
that
this
situation is never encountered. Configure your software to either
reject
messages
during delivery or accept them permanently. Do not let your
software
make choices
about delivery after it has accepted a message. If you must accept
delivery
before you know the status of a message, then file it internally -
do
not send,
forward or bounce it outside your organization. The errant message
can
be placed
in a special folder or routed to your postmaster."