https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5185
Kevin A. McGrail <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #21 from Kevin A. McGrail <[email protected]> 2012-02-13 15:36:14 UTC --- (In reply to comment #20) > I'm sorry to come to this after it's committed, but removing the received > header from msgid is a very bad idea. > > There needs to be some part of msgid that isn't under the control of spammers, > otherwise it's trivial for them to prevent their spam ever being learned. They > can generate as many spams with the same msgid as they like, and they can > prime > the database with an initial dummy high-scoring spam that has no usable tokens > in common with the rest. > > IMO the best way to handle this is to add some kind of UID to one of the > headers (preferably with some control over where it goes). Other than that IMO > it's better to put it back as it was. The received header is not available in the mail stream at the time many people are running SA. Therefore, the synthesized header and the final header don't match which generates two disparate msg_id's which is the problem we are trying to solve. And since SA is both an API and a filtering software, we can't guarantee how it is used so adding headers is not a solution. I'm very open to other ideas but just adding the received header back isn't feasible as it will cause issues. However, the msgid is still generated including a substantial portion of the body of the email. How can they generate a message ID for an email with differing content as you propose? Regards, KAM -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
