[SC-Help] Re: Help me guys, whats going on?

[Mike Easter]

Kristoffer Lein wrote:
>  "Mike Easter"

>> That is, I don't want any usernames or addressses;  I'm just trying
>> to understand the 'concept' - your original From domainname, which
>> mailserver you used to send it, and the To domainname.  Apparently
>> you got it the bounce in your SC mailbox.
>
> My SpamCop email (cqmail.net) -> trough my ISP (mail.c2i.net) -> too
> attglobal.net user -> "spam bounce" back to me again.

OK.  I'm beginning to get it.

This next is completely wrong;  don't even read it ;-)

Mike Easter wrote:
> So, I'm assuming you emailed someone at swip.net from the tele2.no IP
> which got bounced and the bounce was received at the spamcop addy --
> but the bounce was based on the .no IP, not a SC IP.  I can't make
> any sense or relationship between what the DSN body is saying^1 and
> what I'm seeing in the headers^2.  The .no IP is listed in njabl and
> sorbs because it is a dynamic.  Your mail shouldn't be going out a
> dynamic IP. If it was belatedly bounced and bounced to a different
> From rather than rejected that might explain how it got into the SC
> mailbox.

Instead of what I said there...

Swip is yours, as you explained.  The bounce is your own provider
telling you that you/it tried to send a/your mail and it wasn't
accepted/ was rejected/ by the recipient server which was working for
attglobal.  That is a true 'proper' rejected transaction and is *not* a
'belated' bounce [which gets accepted and then a newmail is initiated to
the From].

Kai's domainname is attglobal.net and the prserv mx is what is doing the
rejecting for it.

So, the wouldbe path would be your dynamic .no IP to the swip smtp
toward the attglobal via its prserv MX -- but the prserv MX refused to
take the mail from the swip server, so your own swip server told you
that your/its mail's transaction failed.  The bottommost headers I
described earlier is your server taking the item from your IP.

We are still left to guess at why the prserv mx refused swip's
transaction, but/and we have one swip outgoing IP to look at, namely the
one which sent your mail to the spamcop mailbox.  That may not be the IP
which tried to transact with the prserv/attglobal MX.  That IP is
212.247.154.225  rDNS  mailfe08.swip.net and it is currently listed on
the blocklists blars and dnsbl [rmst] and jammd and spamcannibal.  That
is not an insignificant group.  The only one showing evidence for that
IP is spamcannibal at http://www.spamcannibal.org/cannibal.cgi

It is very frustrating when a rejected transaction takes place and the
actual output IP which is being rejected isn't named in the DSN.  It
would also be nice if the DSN which rejects something based on a
blocklist would name a blocklist, unless it is a 'private' one -- which
this may be.  The attglobal/prserv MX may have its own non-public
blocklist named 'mx.rbl'.  When the output IP isn't stated, we are left
to guess, because the incoming MXes are listed, not the output server
IPs.

The mail admin who is the most responsible for figuring out what is
going on is the swip admin.  Swip needs to be finding out why
attglobal's MX should be rejecting its mail, namely yours.



-- 
Mike Easter
kibitzer, not SC admin