RE: I5 smtp and spamcop

["Chris Bipes" <chris.bipes@xxxxxxxxxxxxxxx>]

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."