https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6494
--- Comment #4 from Karsten Bräckelmann <[email protected]> 2010-09-21 18:13:57 UTC --- (In reply to comment #3) > However, it seems the debug still do not see my trusted and internal network > correctly. None seems to be internal. Could the 'unknown' IP in the header > caused this to break? Yes, that is exactly what I said. Or meant to say, anyway. ;) The last relay does not record the sender's IP, nor rDNS. It even fails to add it's own rDNS. I believe this is precisely, where things break. SA cannot include that hop in its trustpath, and thus earlier relays will not be added either. I believe this is not a bug and should be closed, but will keep it dangling just in case for a few days. (For the record, non-bug configuration issues should better be brought up on the mailing lists. This is a bug-tracker, not a support source.) > Sep 21 17:13:23.333 [26116] dbg: received-header: parsed as [ ip=unknown rdns= > helo=annwn23.rutgers.edu by=unknown ident= envfrom= intl=0 id= auth= msa=0 ] > Sep 21 17:13:23.335 [26116] dbg: received-header: relay unknown trusted? no > internal? no msa? no (In reply to comment #2) > I realized that this is the problem with the server putting bad Received > header. Unfortunately, I have no control over the SMTP server. Uhm, that's the second top-most Received header, right before qmail invocation. You do not have control over that server? And BTW, if you really do not have any control over that server and cannot have it fixed, you cannot really trust it to insert correct data, can you? -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
