On Sun, Jul 17, 2005 at 03:34:26PM -0500, Ron Johnson wrote: } On Sun, 2005-07-17 at 08:48 -0400, Gregory Seidman wrote: } > On Sat, Jul 16, 2005 at 08:41:35PM -0500, Ron Johnson wrote: } > } On Sat, 2005-07-16 at 20:15 -0400, kamaraju kusumanchi wrote: } > [...] } > } But then you'll be replying from a different address than the } > } email was sent to. } > } } > } Most ISPs don't like that anymore, and SpamAssassin (and probably } > } Baysians also) score it as possible spam. } > } > I don't think you know what you're talking about. First of all, I don't } > know of a single spam filter (with the possible but unlikely exception of } > GMail) that is sufficiently stateful that it will notice that the message } > with the ID in the In-Reply-To field was originally sent to an email } > address other than the one in the From field. Second, if it could, it would } > break every single mailing list reply since the From field *never* matches } > the list email address to which the original was sent. And third, in actual } > practice, I have never had trouble sending messages which claim to be from } > a wide variety of email addresses often having nothing to do with the } > machine from which I was sending. (A series of reflectors and } > forwards would get messages sent to those addresses back to the machine in } > question, but that isn't something that a spam filter can test.) } > } > In short, I think you're speaking from a position of no knowledge on the } > subject whatsoever. } } But I've seen twice, in *valid* emails I've received from mailing } lists, where people send emails from their own MTAs, but force } the return address to be <blah>@yahoo.com and <blah>@hotmail.com. } } Here's an example of how SA scores them: } CONFIRMED_FORGED } FORGED_YAHOO_RCVD
Take a look at http://spamassassin.apache.org/tests_3_0_x.html and http://systems.cs.uoregon.edu/Solaris/spamassassin.php for explanations of the tests that spamassassin uses. Note that the second URL is unofficial, and may be for an outdated version of spamassasin, but it mentions CONFIRMED_FORGED and the official one does not. CONFIRMED_FORGED means the received headers are forged, which usually means that it is trying to appear to be coming from a machine other than the one it's coming from. Sending from a properly configured local MTA should not flag this, since there is no forgery going on. I don't claim to know how the Received headers are tested for forgery or not (I didn't dig that deep), but I hope they are clever enough to distinguish between a local MTA using a smarthost rather than a spam forgery (or, at least, keep it to one-sided errors). FORGED_YAHOO_RCVD means that the message claims to be from a yahoo.com address but did not originated from a yahoo.com mail server. This is a special case (which is why it's its own rule), and there is a similar one for msn.com, excite.com, lycos.com, etc. This will, indeed, come into play if a user sends an email purporting to be from a yahoo.com address from a smarthost MTA, but that's specific to yahoo.com (and msn.com, etc.) addresses, not a general rule. On a side note, it has been pointed out that my comments were uncalled for, and it's true. I do think you were uninformed, but there was no need to be rude about it and I apologize for that. I hope that this message has been informative, rather than rude. } Ron Johnson, Jr. --Greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
