https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6430
--- Comment #7 from Mark Martinec <[email protected]> 2011-04-04 10:50:12 EDT --- > Mark, your patch is fine to me. > But what if one is not using amavisd? Tough luck then! :) Now seriously: I'm ok with your patch, it does solve one additional topology variation. Not sure how commonly such a setup would be useful, perhaps when an external SOHO mailer is forwarding mail through a company's MTA, or similarly for an internal (like departmental) MTA doing the same, assuming it is using explicit authentication and not relying on its internal network address (implicitly authenticating by an internal IP address is way more common in such a scenario). If others would find it useful, I'll give it my approval too. My concern is that this whole business of internal / trusted / msa / msa_on_auth is getting quite complicated and hard to understand, people even now commonly just don't care to even configure internal/trusted properly, and even with all these config options one still cannot cover some mail flow topologies. For example a setup where an internal (e.g. a departmental) small MTA is forwarding/re-sending mail for its users to their external delivery address passing them again through a central MTA running SpamAssassin on their way out (I'll not go into argument about usefulness of outbound spam filtering here). Currently there is no way (other than using an MSA) to avoid DUL and similar blacklists on such messages, even though these have been already spam-screened once on their way in to the site. I guess I'll wait and see what others have to say on the matter. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
