>So - how will we debug this?
Well, if the suggestions I made don't apply, then we'll move on to debuggin.
> >> The "WHITELIST" line only works in \IMail\Declude\global.cfg. <<
>
>That's where it is - the ONLY place.
OK; just checking. When you said that the whitelisting was done both
globally and individually, I thought that I should point out that Declude
only does whitelisting on a global basis.
> >> Also note that failures will appear in the log, but any actions should
>not be taken on the E-mail <<
>
>I only noticed it, because the Q* and D* file appeared in my HOLD folder.
In that case, the whitelist did not work.
> >> with the "IPBYPASS 63.107.174.32", it would be the server that connected
>to 63.106.174.32. <<
>
>Doesn't apply. The .32 is our backup SMTP server. As you were able to
>determine from the SMTP header that I had included - the .32 machine was NOT
>even involved!?
True, but if you had a line "IPBYPASS 63.107.174.1", it would have caused
the behavior you described.
>So - I ask again, why was it "HELD" when the originating mail server was
>White-Listed?
The easiest way to debug this would be to send an E-mail from the IP
address in question, with the Declude debugging turned on. To do this, you
can change the "LOGLEVEL LOW" line in \IMail\Declude\global.cfg to
"LOGLEVEL DEBUG". After sending an E-mail from that IP address, you can
switch back to "LOGLEVEL LOW", and send me the resulting log file.
-Scott
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". You can E-mail
[EMAIL PROTECTED] for assistance. You can visit our web
site at http://www.declude.com .
