http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4728
------- Additional Comments From [EMAIL PROTECTED] 2005-12-10 00:21 ------- I assume "firsttrusted" is a typo, and you mean "firstuntrusted". That said, "firstuntrusted" wouldn't work all that well either. Really none of the features built into SA 3.1.0 would work very well for this. "notfirsthop" (as currently done in 3.1.0) breaks for this (somewhat rare, but legitimate) case: public IP -> public (dyn) -> ISP -> Recipient MX -> SA. While it is weird, they shouldn't be penalized with DUL hits since they did relay through the ISP server. Admittedly this could be caused by dialup-joe running an open-relay MTA on his home machine, but that's an issue for the open-relay lists, not the DUL lists. "firstuntrusted" breaks for the case that a user decides to trust an outside ISPs MX to be non-forging. It seems perfectly plausible to trust such a relay to not forge headers. Why should "trust" imply "part of my network that should not get DUL mail"? The current docs actually outright tell SA users to declare their MXes which accept direct dul mail as trusted but not internal. Since this is really not so much a matter of trust vs untrust but internal vs external, it would be better to do something along the lines of "firstexternal". Consider this as the "worst case": public IP (external,untrusted) -> public (DUL, external, untrusted) -> sender's ISP smarthost (external, trusted or untrusted) -> Recipient's MX (internal, trusted) -> SA (internal, trusted) The only IP that should be checked against DULs is the sender's ISP smarthost, since that's the box that dropped the mail off at our recipient's MX. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
