Hector Santos wrote:
Some accumulated thoughts
And some collected responses
o No Spams this week! <pondering: something is wrong? checking logs...
nope, all spammers!>
Congratulations. Does this mean 0 false positives that you've distinguished
purely by how they were recorded in your MTA logs?
o LMAP works best to protect your own domains. Low trust in remote domain
checking.
On the contrary, you can trust that if a domain publishes LMAP records, and
an incoming connection claiming association with that domain that is not
born out by the LMAP data, you can pretty well trust that it is a forged
connection.
o LMAP has a high DNS overhead for remote domain checking.
Should be no worse than doing an A lookup on the HELO name or the PTR lookup
on the IP. I'm not so familiar with the inner workings of DNS, but couldn't
the LMAP and HELO/A lookups be done in a single query?
o LMAP compliant spammers is a reality! Can't trust remote checks!
Sure you can: you can trust that they control the domain they're sending as,
and not forging someone else's.
o LMAP only tries to link the DOMAIN and not the USER PART of the email
address.
Ummm..... yes.
o CBV continues to prove the return path address is more important than just
the return path domain.
Could you elaborate on this point?
o Anonymous Access Management system *can* work without a fundamental change
to SMTP.
And this, too?
o SMTP functional specifications (the RFCs) must change in order for
technical specification enforcement to take place.
You can enforce any technical specification you'd like. RFC [2]821
explicitly allow the rejection of any connection for any local policy reason.
o SMTP functional specifications must change in order for CAN-SPAM can even
begin to work.
CAN-SPAM is irrelevant to the work of this group, because the Internet
encompasses more than the jurisdiction of US law.
o Why is it that I get a constant ~2500 connections? with a constant
spam/rejection 90% rate?
Since you obviously see some significance to those numbers, you tell us.
o 80% of all transactions is spoofed.
By what criteria?
o Local Domain (HELO) Spoofing is 10%. 80% is RBL rejected, 10% rejected by
CBV
You mean 10% of rejections are based on the results of your algorithm for
detection of HELO spoofing. You're algortihm can't determine if it's legitimate.
o Many systems don't support extended multi-line response.
Interesting data point.
o Too many systems rely on "dumb scripting" systems, hence lack of support
for SMTP features.
Of course, it goes faster that way. If we start enforcing strict SMTP
compliance, they'll start complying.
o SPF needs to get rid of softfail and neutral policies. If system is not
ready for it, then use it!
I can't really answer that, as I'm not too deeply familiar with SPF.
However, I suspect that softfail modes are probably there for the same
reason that the Postfix MTA has a softbounce option (45x rather than 55x on
failures): to prevent configuration errors leading to catastrophies.
Suggestions:
o CAN-SPAM provides two mandates; return path validation and topic
identication; Use this model!!
As stated above, CAN-SPAM is irrelevant.
o Add Multiple line greeting to eliminate many of your spammers! 60% on our
system.
Perhaps I'll try it.
o LMAP may provide incentive for the building of "Network Relationships" or
"LMAP-Nets"
If you've been following ASRG's SMTP-Verify subgroup, you'll see a great
deal of ongoing discussion of the 'web of trust' concept.
o Need SMTP Message-Id Verification (Exist) Feedback System.
May be the next step, but there's nothing to stop a spammer from setting up
a system to provide that verification. Just makes them incrementally more
traceable.
o SMTP needs a protocol topic identication command, i.e., "SUBJ"
Why would any spammers comply with it? Only the 'legitimate' (as in above
the table) marketers would, and they're already easy to filter.
o BCP: RCPT validation stops SORBIG generation email virus distribution
dependency on bounce mail attacks.
I'm not quite sure what you're saying with this. All of the LMAP-like
proposals on the table would prevent the initial spoofing of domains that
worms & viruses do.
That's it for now.
Then I'll stop replying for now ;-)
Philip Miller