Jo Rhett wrote:
On May 3, 2008, at 7:59 PM, Matt Kettler wrote:
Have you tried running one of the forged messages, and an actual
legitimate message through SA manually with the -D flag to see what
the trusted and untrusted hosts are, as SA sees it?
Yes. Many times. That's not the point of this thread.
I still think it is.
Matt, how can I possibly get you to move past this unfounded
assumption that my trust path is broken and focus on the real
problem? The trust path is not broken, it's just fine.
Ok, then the AWL code is *SEVERELY* bugged. The question then becomes
why isn't the source address part of the AWL working properly.
If your AWL is applying the same history data to forged email as
unforged email, either there's a *major* bug in the AWL code, or your
trust path is broken. Period.
The AWL is designed to be able to distinguish forged mail from
nonforged mail. If that's not working, that's a major problem.
I've read the code and I see nothing designed to determine forgeries.
There is code to save data with an IP range, but that's not relevant
to this issue.
That's entirely relevant. That IP range is what would detect the
forgeries, or at least give the forgeries a different AWL entry than
email you really sent yourself.
The source IPs are different, so your real self-to-self should be
handled independently, with a completely separate AWL entry, from the
spammer forged self-to-self.
The point of this thread is the obvious ease of forging e-mail from
recipient to (same) recipient. It's one situation where the AWL
wouldn't work very well.
Actually, it's very difficult to forge in a way that will confuse the
AWL, if your trust path and the AWL code is working properly. After
all, it looks at the combination of email address and first untrusted
IP. Forged email will not be from the same IP as legitimate email,
unless your trust path is broken and SA always sees all mail as
entering your network from the same IP.
Or that you receive e-mail from the very same public wireless and/or
phone providers as everyone else does. My trust path doesn't have to
be broken if the networks used to send the e-mail are public networks.
(if you can laugh == "welcome to the 21st century and the
Crackberry/Treo/iPhone") Not trying to be snide.
If you're using any kind of forwarder, including crackberry, their
servers should be trusted by you so that SA's checks get applied to the
mailserver that dropped mail off at them. That's the purpose of the
trust path, to allow you to trust the headers of those systems receiving
mail on your behalf and forwarding it to you.
It would be fairly easy to forge, and worthwhile enough for botnets
to just do this (which they are, in force, for the last month)
I personally see no value in applying AWL to messages from self to
self.
I agree, but I see no value in applying the exception. I'd rather try
to fix the more general problem of your AWL not distinguishing
message sources properly.
I see no evidence of this. My trust path is just fine (ie
"nonexistent" == all mail not from localhost isn't trusted)
Agreed that's probably reasonable in many networks.
I may be wrong, and I'm open to arguements against this, but I am
suggesting that the AWL module should skip over self->self
messages. It seems too easy to forge, and no gain in doing so.
You're overlooking how the AWL works. It's actually really hard to
forge.
However, I will agree with you there's limited value in self-to-self
AWL records.. but there's also no harm in them if the AWL is working
properly.
Instead of making statements like this, please explain how the AWL
deals the forgery. Because I have the code right in front of me and I
see absolutely nothing in the AWL code that tries to identify
forgeries. Instead of making unfounded statements, can you be
specific about the issues?