Re: to not read spam emails on debian MLs
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
Reply to: