|
Re: Top Concerns, Issues, Comments
2004-03-21 16:14:56
Hector Santos wrote:
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?
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>
I ask then, when you're checking for incorrect results, how can you tell
before DATA whether a mail was spam or not. Obviously, if it was rejected,
it didn't comply with your implemented policy. For example, if someone on
these lists whose address you didn't recognize (perhaps using a private
address not used on the list) sent you a personal message that was blocked
by the spamcop RBL, you would not be able to distinguish it in your logs.
My assertion here is that you can't possibly 'look at everything' when you
haven't received everything, DATA and all. As a point of interest, SMTP
allows a fairly long wait (10 minutes, RFC 2821 4.5.3.2) between receiving
the end of DATA's payload and sending the final response code. Ideally,
transactions would never get to DATA because it wastes bandwidth and
processing time, but for development purposes, perhaps you should be going
to that point. This way you could still reject it on whatever criteria you'd
like, but you now have the DATA payload to confirm against. Statistical
information about the payload of the messages you're rejecting vs. accepting
could also be useful.
Here is an example of a false negative:
[snip log data]
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.
Again, if you didn't recognize that address as belonging to Paul Hoffman,
how would you know it's an incorrect result?
(Side note here: I think you're reversing the common usage of false positive
and false negative. False positives are messages incorrectly treated as
spam, and false negatives are messages incorrectly treated as non-spam/ham.)
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.
That's good. What we're trying to achieve in these first steps is preventing
spammers from taking advantage of someone else's good reputation and abusing
their resources with false CBV attempts and bounce messages.
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
No comment here, aside from noting that your product sounds very nice.
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%
OK, I see now. I just have one issue with equating LMAP with SPF. LMAP has
no official implementation as yet. SPF is an implementation of the ideas
LMAP entails plus somewhat more.
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?
Let me clarify this: in the case of a system that's not logging so much
connection-time data, I think you could replace the A and PTR lookups on the
hostname and IP and only do the LMAP lookup.
I don't claim to be a DNS expert (but I'm getting there <g>), but based
on my analysis, I think it all depends on whether the domain exist or
not.
OK.
[snip DNS timing issue for my lack of relevant knowledge]
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 goal is that eventually no lookup will result in an immediate reject,
because spammers will be compliant too. The upside of this is that they will
no longer be abusing the name and resources of an innocent third party.
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.
OK.
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, by our estimates when LMAP (or WCSAP) was done before RCPT is
known, 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.
Do you really get that many invalid RCPT TO addresses that get rejected that
moving wcSAP checks after RCPT checking makes a 40 second difference on average?
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. :-)
OK.
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.
Out of curiosity, could you test VRFY before RCPT when checking a given MAIL
FROM address? It'd be interesting to see how they compare. Using VRFY may
also speed things up a bit if it actually provides the necessary
information, as a client is allowed (RFC 2821, 4.1.4) to issue VRFY without
sending and getting responses to EHLO and MAIL first. The issue there is
that many sites disable the use of VRFY to prevent higher-speed dictionary &
harvesting attacks.
From a RFC 2821 standpoint, CBV or LMAP, what needs to be clarified 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.
I agree with you that the return path should always be valid at the time of
the transaction, at least in principle. However, the issue of checking it
via RCPT TO is sticky. Your goal of finding a strict justification to reject
is clearly hampered by this. I just don't see how we can reasonably solve it.
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.
On the other hand, I see rejecting messages if a RCPT TO the return path is
rejected as a perfectly legitimate local policy, which if implemented
Internet-wide would at least prevent many double-bounces and the like.
o Anonymous Access Management system *can* work without a fundamental change
to SMTP.
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.
OK, so I think we agree that the most important goals with respect to
reducing liability would be to:
1. Maximize the number of messages that can be rejected during the SMTP
session, rather than bounced
2. Guarantee the validity of the bounce address to the furthest possible extent
For #2, I think 'the furthest possible extent', when implemented on the
Internet scale is exactly what you're testing:
a. the domain is not spoofed
b. messages to the bounce address will be accepted
Once the domain is validated, it is the responsibility of that domain to
validate the mailbox part of the MAIL FROM address. This includes using
facilities such as SMTP and TLS client certificates to prevent outbound
transmissions with spoofed addresses, as well as ensuring that any message
sent can be correctly bounced.
[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.
This is something to note in a BCP: don't auto-submit messages determined by
local policy to be spam to public databases. On the other hand, if the
message is automatically submitted, rather than seen by a human being, is
the system administrator liable for that violation of privacy? That's a
question for a lawyer, but I would think that he is not liable.
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.
And you can legitimately tell your customers that they can send messages
that are compliant with the requirements placed on them by [random
{[inter]national,regional,state,local anti-spam law] using your software and
doing X, Y, and Z in addition. In other words, you can say "Yes, it is
possible to send CAN-SPAM compliant messages with my product" to your customers.
In the case of CAN-SPAM, they effectively must own the domain name they're
sending from, accept bounces, honor unsubscribe requests, and use accurate
subject lines, possibly including an 'ADV:' or similar tag. Hell, you could
offer CAN-SPAM consultation and training, to show them how to properly send
mail.
Also, as Yakov has pointed out, that is a mischaracterization of the law's
implications for IETF.
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.
This is not a mandate for receivers to enforce. This is a minimum hurdle for
senders to pass to avoid legal consequences absent other abusive and/or
illegal behaviour.
If a new law were passed requiring that marketing messages only be sent by
those with 18" long red hair, would you ask the IETF for a standard to aid
enforcement of that, too? Perhaps we need coiffure accreditation (CA)
companies to verify this for the rest of us?
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.
That's way out of this group's likely scope. May possibly be within scope of
ASRG SMTP-Verify, though I'm not sure.
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.
Take it to ASRG, there are interested parties there. When there's specific
data and information in that of interest in the development of a complement
to MX records, please point it out specifically.
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.
Internet-wide MXCOMP implementation should change that by making it useless
for spammers to spoof at all. Most likely, it doesn't mean that the number
of connections we see will drop by 80%.
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 algorithm can't determine if
it's legitimate.
We are not in the business of determining legitimacy of mail. We are 100%
focus on protocol level compliancy. Take a moment to see our stats. I will
summarize it here (Using March stats upto this point)
I'm not talking about legitimacy of mail, but legitimacy of HELO usage.
There is nothing in the protocol beyond being a FQDN or address literal that
defines protocol compliance of the HELO argument.
Average Calls/Connects: 2449
Immediate Drops at the greeting (no HELO/EHLO issued): 5.3%
Drops after issueing HELO/EHLO: 75.2%
Lack of HELO/EHLO is clearly non-compliant, so that's within reason to
reject. Presently, however, rejection based on EHLO-IP correlation is
explicitly prohibited (RFC 2821, 4.1.4, paragraph 6)
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.
Data on the specific breakdown of implementation of various MXCOMP designs
would be most useful here.
[snip]
o SPF needs to get rid of softfail and neutral policies. If system is
not ready for it, then don't 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.
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).
It should certainly be possible to put a 'flag day' in place, after which
email whose originating domains offer softfail and neutral policies could be
rejected. That is certainly something to keep in mind if SPF or something
substantially similar is settled upon by this group.
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.
OK, I agree that we should consider its provisions when shaping any
anti-spam spec or standard, but by irrelevant I mean that our requirements
for an MXCOMP solution should not be shaped by it without regard to the
actual technical problem that we are trying to address.
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.
Has this been reported to php.net as a bug? If not, I'll gladly do so.
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.
As a general policy, implementing such a work-around seems like a bad idea,
but if it's disabled by default, I see no reason not to provide better
service to your customers.
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.
We are in the process of changing the system to reject certain invalid
transactions, to force spammers to change along with it. That's the purpose
of this group.
I don't quite understand that last sentence. Perhaps you could rephrase it?
o SMTP needs a protocol topic identication command, i.e., "SUBJ"
Why would any spammers comply with it?
CAN-SPAM? Oh, it's irrevalent :-)
In terms of actually stopping spam from reaching user's mailboxes, I still
believe it is irrelevant.
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. :-)
I don't see where the fuzzy logic comes in here. Presently, we have a
variety of systems that check HELO and IP in myriad (fuzzy) ways. MXCOMP
will ideally collapse those to something much simpler and more deterministic.
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.
Not following you here...
o BCP: RCPT validation stops SOBIG 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.
Agreed on this point, and I addressed it above.
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.
Well, RFC 2821 explicitly allows up to 10 minutes to do this, and perhaps
IETF should be involved in creating standards for better communciation
between MTAs and filters. Again, something outside this group's narrow
predicted scope.
This is certainly worthwhile discussion, although I'm not sure it should be
happening here. Perhaps we should move this to ASRG? Please simply redirect
your response, or split this thread into scoped parts, if you agree.
Phil
|
|