----- Original Message -----
From: "Philip Miller" <millenix(_at_)zemos(_dot_)net>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: "IETF-MXCOMP" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Saturday, March 20, 2004 7:57 PM
Subject: Re: Top Concerns, Issues, Comments
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?
Hi Philip,
I check for both false negatives (incorrect rejections) and false postivies
(incorrect acceptance).
Yes, I look at everything. Trust me. Engineering is in my bones. <g>
Here is an example of a false negative:
Date: 20040217
02:14:31 -------------------------------------
02:14:31 version : 1.54 / 1.52
02:14:31 calltype : SMTP
02:14:31 state : rcpt
02:14:31 cip : 208.184.76.39
02:14:31 helo : above.proper.com
02:14:31 from : <phoffman(_dot_)org(_at_)above(_dot_)proper(_dot_)com>
02:14:31 rcpt : <winserver(_dot_)support(_at_)winserver(_dot_)com>
02:14:31 ruid : 228761
02:14:31 srvip : 208.247.131.9
02:14:32 sapfilter : pass
02:14:32 sapspf : none
No SPF record for above.proper.com.
02:14:32 saprbl : testing 39.76.184.208.sbl.spamhaus.org
02:14:34 saprbl : testing 39.76.184.208.list.dsbl.org
02:14:35 saprbl : testing 39.76.184.208.bl.spamcop.net
02:14:37 saprbl : pass
RBL lookup passed. Now the final CBV test is done since nothing else passed
it.
internal filter rules passed. (Btw, in current setup, RBL is before SPF
test)
02:14:39 sapcbv : total mx records: 0
02:14:40 try domain : above.proper.com ip: 208.184.76.39
02:14:40 # connecting to 208.184.76.39
02:14:41 S: 220 above.proper.com ESMTP Sendmail 8.12.11/8.12.8; Mon, 16 Feb
2004 23:12:58 -0800 (PST) NO UBE
02:14:41 C: NOOP WCSAP v1.54 Wildcat! Sender Authentication Protocol
http://www.santronics.com
02:14:41 S: 250 2.0.0 OK
02:14:41 C: HELO mail.winserver.com
02:14:41 S: 250 above.proper.com Hello mail.santronics.com [208.247.131.9],
pleased to meet you
02:14:41 C: MAIL FROM: <>
02:14:41 S: 250 2.1.0 <>... Sender ok
02:14:41 C: RCPT TO: <phoffman(_dot_)org(_at_)above(_dot_)proper(_dot_)com>
02:14:41 S: 550 5.1.1 <phoffman(_dot_)org(_at_)above(_dot_)proper(_dot_)com>...
User unknown
02:14:41 C: QUIT
02:14:41 sapcbv : 550
02:14:41 smtp code : 552
02:14:41 reason : Rejected by WCSAP CBV
02:14:41 wcsap finish (9953 msecs)
This is a example where the testing fell through to the final CBV test and
it failed because the return path was not acceptable at this domain. This
was back in Feb 17. So I can't say today, but without the CBV you won't see
this. I can't throw out the baby with the bath water because of situations
like this. It do find it ironic one of the top people in IETF does not have
a valid return path in his setup. This is not in no way a knock on Paul,
and I surely hope he doesn't see it that way, but this is an example of the
realities of the new world. Compliancy is a very big of the picture for
any of this new work can even have a chance. If the above is deemed
"acceptable" then we might as well give up now.
Incidently, with SPF implemented, in the past few weeks, we are
experiencing an increase in false positives which are eventually filtered by
the CBV or by mail-content filters at the DATA stage. This indicates the
expected increase of SPF compliant spammers. Spammers will either comply
or they don't. Spoofing will probably no longer work for those who apply
LMAP concepts.
With that experience, it was obvious we needed to a SPF options to our
product to offer some control over the remote non-fail situation:
; SPF can return low trust results. A pass means the sender has
; a valid SPF record and is accepted. Softfail and Neutral means
; no match is found but rejection is not automatic. Setting a
; true accept can provide a loophole for potential spoofers who have
; SPF records and think they will be allowed access. The options
; below allow you to control this.
Accept-SPF-Pass True ; if false, continue testing
Accept-SPF-SoftFail False ; if false, continue testing
Accept-SPF-Neutral False ; if false, continue testing
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.
Clarification:
- LMAP offers 100% trust in local domain spoof protection
- LMAP offers less than or equal 100% trust in remote domain reject results.
- LMAP offers little to no trust in remote non-fail results.
A positive result can not be trusted 100%, where a negative has a 100%
trust value:
0 < trust positive < trust negative = 100%
More specifically, the trust inquality is:
0 < Remote Domain Pass < Remote Domain Reject < Local Domain = 100%
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?
I don't claim to be a DNS expect (but I'm getting there <g>), but based on
my analysis, I think it all depends on whether the domain exist or not.
I posted this for Meng last month when he wanted to see a comparision of DMP
vs SPF (we had DMP first before adding SPF).
"
Good News:
When the DOMAIN is valid in DNS, SPF is on average 3-4 times faster than
DMP with ranges in the milliseconds (i.e, 30 ms to 120 ms)
Bad News:
When the DOMAIN is invalid in DNS (NXDOMAIN), SPF is on average 4-6 times
SLOWER than DMP with ranges in seconds (i.e, 6-4 secs to 1- 0.5 secs).
"
Now, I believe DNS behaves the same for A records lookups. It depends on
whether it exist or not. This is why I consistently and continue to say
that LMAP operates best for Local Domain Spoof protection. Once you (and
everyone else for that matter) go to remote, well, not only do you increase
DNS overhead when the majority of the domains are spoofed or don't exist,
but the result can not be trusted unless it is reject.
The question than becomes of a trade off. This is why you need to
understand my LMAP Validation tables posted at:
http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm
In Table 1.0, Group D shows 3 states where LMAP can be used when RCPT
validation is not a factor. Table 2.0 shows how Group D is expanded to 6
states when RCPT is considered but LMAP is only necessary for 3 of the 6
states; when the RCPT user is local (final destination). For remote RCPT,
that requires an entirely different relay authentication standard practice.
So it doesn't apply.
In other words, this tells you that if you postpone the LMAP lookup until
the RCTP state is known, you can drastically improve your LMAP operations.
In fact, but our estimates when LMAP (or WCSAP) was done before RCPT is
none, the average session time was 60+ seconds. When wcSAP was postpone
until the RCPT was known, the average session time shot down to 21+ seconds.
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.
See trust statement above. :-)
o CBV continues to prove the return path address is more important than
just
the return path domain.
Could you elaborate on this point?
address #1: baduser(_at_)spfdomain(_dot_)com
address #2: gooduser(_at_)spfdomain(_dot_)com
Both addresses may pass the domain spf policy test when in actuality, only
user #2 is valid. The CBV will pick up on this and usually does. Of
course, that doesn't mean it the remote can't easily bypass it. Nothing you
can about that. But again, the focus in our testing is to look for
"rejects" as they are the only thing you can trust.
From a RFC 2821 standpoint, CBV or LMAP, what needs to be clarify is the
ambiguity surrounding the "time" when the return path is considered
legitimate. I've seen interesting comments that even though the RFC
presumes the return path to be valid, it only needs to be valid come bounce
time. Well, that is what the spammers exploits, this exact mode of
operation.
PS: I understand all the technical issues surrounding a CBV. That is why we
are even dealing with other methods as a means to bypass the CBV.
o Anonymous Access Management system *can* work without a fundamental
change
to SMTP.
And this, too?
<g> answer below
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.
This is a false philosophy that has played the rounds for so many years,
which does have legal precedence, but it is NOT as clear cut as you make is
sound. Actually the law does have something to say about this.. I've
designed mail transport, gateway, frontend software for many networks as
well. The law covers all systems. The implications is if you accept, you
are responsible for it. Delivery or Bounce. The RFC covers this, but it is
the law with precedence behind it. The most important point here is that
the ADMIN has full control of the system on the initial acceptance of the
message. What is also very important is you better not tamper with it.
[Side track note] Another email myth is the private mail system. If I write
you a private message, legal precedence has provided the recipient the
right to make the message public. However, if the author clearly states in
the message the "intent of privacy is to be maintained", then the recipient
risk tort liability by making it public. The exception to this ECPA law is
company employer mail systems. Employees had no privacy rights.
Implications with LMAP? False Rejections being sent to SPAM database sites
making private mail public.
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.
May be irrevalent to you or this group but it isn't to the product vendor.
We already have customers (whether they understand the concepts or not)
asking if we are "CAM-SPAM ready."
I have a deep and long time ethical and software engineering philosophy that
can not be shaken. We write products for other people. Not just for us. We
are not ignorant of liability issues, we follow the standard to the fullest
possible extent and there is simply no compromise. If a US Federal Law has
provide two mandates in CAN-SPAM that says:
- Return Address must be valid
- Topic Identification must be provided
then we are not going to be oblivous to this new federal requirement for
spammers and for mail systems to help make it happen. The FEDs have given
the IETF 18 months (now 15 months) to define the IETF standards that the
spammers must comply with.
LMAP has given SMTP developer industry the ability to statisfy mandate #1.
So Anonymous Access Management is possible with current SMTP standards if we
use LMAP as a way to provide the enforcement policies lacking in SMTP alone.
What is missing now is #2, and this is where there is a conflict with
current SMTP standard operations. We need an ESMTP extension for this at
the protocol level otherwise systems will be force to operate in a "always
accept" mail mode for post SMTP validation or DATA stage validation.
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.
I need to do some IP analytics. What is surprising me is that the numbers
are constant. Its like these guys are organized with a scheduler that
repeats itself over and over again. :-) Look at the statistics yourself:
http://www.winserver.com/public/antispam
In isolated analysis, it does seem there is a "change" in behavior or some
go away, some come back. :-) But the statistics are just too consistent.
There has to be an explanation. I can only think these guys have me on auto
pilot and could care less if you reject them or not. That isn't going to
stop them from trying anyway.
This has me thinking of late that not only there is a potential for a
localized network relationship of your mail transactions, i.e, "web of
trust," but also a "web of mis-trust." I think there is a pattern here and
I would like to one day analyze this, if possible. In other words, it isn't
as random as one might think.
o 80% of all transactions is spoofed.
By what criteria?
By emperical data and by industry research data. When we first only had
CBV, the rate we were seeing between 80-94% of all transactions were
rejected with spoofed or non-existence domains. It has matched all
industry research published on the subject.
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.
We are not in the business of determining legitimany of mail. We are 100%
focus on protocol level compliancy. Take a moment to see our stats. I will
summerize it here (Using March stats upto this point)
Average Calls/Connects: 2449
Immediate Drops at the greeting (no HELO/EHLO issued): 5.3%
Drops after issueing HELO/EHLO: 75.2%
This means 575 reach MAIL FROM. Now, we delay the wcSAP validation in MAIL
FROM until RCPT is known. This is per the RFC 2821 recommendation.
Rejects at RCPT: 31.5%
This means that wcSAP will only be called for 69.5% or 400 transactions for
local domain users issued. Before a RCPT response is issued, wcSAP is then
called to perform a suite of test based on the IP, HELO, and MAIL FROM.
What we see is is 53% of the 400 or 212 is rejected by wcSAP for one reason
or another. The break is:
FLT (Internal Filter Accept/Reject rules), 8.6% or 18
RBL, 78.1% or 166
SPF, 0%
CBV, 12% or 25
The remaining 188 reaching the DATA stage, 10.8% is rejected with our
in-house rule based mail filters, leaving, about 168 messages that were
accepted.
Now if you are looking at the stats, the %accept shows ~90 transactions were
accepted. This is the true amount as it is based on the final "250 message
accepted for delivered" for the DATA stage. So the missing amounts not
shown are drops after HELO and/or the duplicate RCPT rejected which
increases the percentage.
In any case, this has been pretty consistent. What I am going to add soon
is a column should the number of domains with SPF records. I'm am
differently seeing more spammers than legitimate systems, which I guess make
sense, given the fact I have such a high rate of spoofing spammers.
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.
ditto. :-)
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.
First, I missed a word above.
"If the system is not ready for it, then *don't* use it!"
Actually, it (softfail, neutral) is there for migration reasons based on the
SPF specification. I already suggested to Meng that there should be a
time limit for this specified in the specification. It can not be permanent.
The "relaxed" specifications opens the doors to loopholes which is what we
are trying to get away from in the first place with the relaxed SMTP specs.
Those items need to go IMO They are totally useless (except for reject
results).
Suggestions:
o CAN-SPAM provides two mandates; return path validation and topic
identication; Use this model!!
As stated above, CAN-SPAM is irrelevant.
Not in my view and IMO, I strongly believe it would be a mistake by anyone
seriously addressing the email issue to ignore it like its doesn't exist.
CAN-SPAM is already being used a model for other nations laws.
In any case, we will differ strongly on this point, so its not worth any
more discussion about it.
o Add Multiple line greeting to eliminate many of your spammers! 60% on
our
system.
Perhaps I'll try it.
Ironically, one of our last minute changes to our new version pending
release, was to address a PHP "mail()" command bug where this multi-line
greeting was found to cause a problem for a customer with the new version he
was gamma testing.
The new logic is to only show the multiline policy file at the greeting if
and only if the IP is remote, not local. He was running PHP script from a
local web server on the same network. So the new logic fixes this. Of
course, it is also optional by default.
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.
"The more things change, the more they remain the same." :-)
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.
As a side note. What I find interesting in all these efforts is a focus to
design a system that fit the current "spam model based on current SMTP
model" Well, the solution is to change it, i.e, force the SPAMMERS to
change. Lack of compliance can only be blamed on lack of enforcement
policies. We can always use a time framework concept.
o SMTP needs a protocol topic identication command, i.e., "SUBJ"
Why would any spammers comply with it?
CAN-SPAM? Oh, its irrevalent :-)
Only the 'legitimate' (as in above the table) marketers would, and they're
already easy to filter.
Good point, which is another thought I had:
- LMAP efforts is a high cost narrow focused incomplete solution for a short
term problem
What is funny about all this is that what is technically a simple
authentication issue, we have add a new level of fuzzy logic to the
equation that may required a neural network to make it all work. :-)
Of course, the way to look at this is what if it does work? at what expense?
What will be a overhead issue, now becames an redundancy issue.
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 depends on your perspective, which is another issue I find in the many
forums:
- Philosophical differences can be traced to the mode of operation one is
used to operating in; dynamic vs post SMTP RCPT validation.
If you don't validate RCPT at the SMTP level, then you will be operating in
a mode which promotes bounces. Remember, once you accept a message, it is
a traditional engineering design as well as ethical and when push comes to
shove, even legal obligation to deliver it or bounce it. You simply can't
just "lose it." RFC 2821 spells that out, but that is inherent in all mail
network systems. As I said above, the local system policy does have a
strong say here, but you are open to liability issues. There is precedence
for this.
What is changing this long time traditional fundamental "natural law" in
mail transport design is the new era of malicious mail, thus the legal
question has become that you can now reject "SMTP accepted mail" without
further notification.
This is something that is totally brand new in the mail transport design -
the idea of rejecting and discarding "already accepted" mail based on post
transaction mail filters without notification. It can open a can of worms.
This is why I strongly believe a system lowers its liability by doing the
mail filter rejection at the DATA stage while the transaction is still
active.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com