----- Original Message -----
From: <willemien(_at_)amidatrust(_dot_)com>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Friday, July 01, 2005 8:39 AM
Subject: Problems with CBV an discussion document
Problems with CBV
Two days ago I wrote that I liked the idea of CBV, but re-thinking it i am
not
so fond of it anymore. This is a public open discussion document and if
you want to disagree with me please do so.
Ok. :-)
Definitions used in this document:
SenderA -> Mail from:<senderA(_at_)domain1(_dot_)tld>
MTA1 -> <MTA that receives emails send to senderA.
the MX records of domain1.tld points to this MTA.
In other words, the Return Path Host?
MTA2 MTA that sends the email to be checked to MTA3
MTA3 MTA that does the Call back testing
You lost me with this.
First remark
MTA1 doesn't have to be the same MTA as MTA2.
As matter of In fact it mostly isn't.
Think about what you are saying. Forget CBV. Wipe it out of your mind.
We have typical incoming transaction, per RFC x821 definition:
MAIL FROM:<reserve-path>
RCPT TO:<forward-path>
If what you say is true, then the reserve-path is completely unreliable for
returning bounce notifications per RFC x821 specifications.
But if you fundamentally believe what the RFC says for the return-path, its
purpose and it must be a reliable address for bounce purposes, then it
doesn't matter what backend arrangment exist, a MTA performing a BOUNCE
process is going to go the some mail reception host defined by the email
domain, and this MTA is going to expect that this address is valid.
If its not valid, then some orignal sender was a PROBLEM. It was not
compliant with RFC x2821 expected behavior.
Second remark
SFP classic tries to answer if MTA2 can be used to send emails from
domain1.tld
First, SPF is a domain authorization concept, not an complete email
authorization concept. So even if you have these two addresses:
bad.user @ microsoft.com
bill.gates @ microsoft.com
both will be accepted by SPF, but only address is truly valid.
Second, we use SPF before CBV, so even then, we put more trust in the SPF
result at the time being. We don't want to call the CBV if we don't have
too. However,
Third, if the SPF domain has a relaxed policy (Neutral or Soffware) then
this is consider a no-decision and the CBV is called. The SPF relaxed
provision is one of the loop holes of SPF and I said so since day one. We
catch a bunch of spammers piggy backing on relaxed SPF domain policies, like
AOL.COM, MICROSOFT.COM, HOTMAIL.COM, JUNO.COM, MSN.COM etc, who the spammers
are still using for spoofing. The CBV works excellent when its augmented
with the SPF relaxed provisions.
Have you implemented proposed technologies? Like SPF? Let me check
amidatrust.com.... No. No SPF record. You should add one :-)
The first problem is: what questions does CBV really answer?
Is the Return Path Valid.
CBV only answers The questions:
Does MTA1 accepts email for SenderA?
It answers the same question whether you were sending mail to any users.
If you don't believe in a CBV concept, then you are basically suggesting
the RETURN PATH is not a valid and reliable entity in the current email
infrastructure based on RFC x821 technology.
That is all the CBV answers.
Now, what are the potential implementation issues?
Well, the same implementation answer that a regular MTA will have to send
mail to a final destination host, plus 2:
- Time Out issues
- Call back Overhead.
You can reduce the CBV overrhead to when its absolutely necessary usin other
methods.
But for timeouts, the question is this enough to throw the baby out with the
bath water.
I say no. It has not proven to be an issue and for many good reasons in
todays market place especially one - scalability.
And with the latest add-on (try to send an email to a fake emailaddress)
Is MTA1 some kind of open relay?
Our CBV implementation test for an open relay. I think it is good idea.
What CBV doesn't awnser
- Did this email come from SenderA?
- Is SenderA a spammer?
- Is MTA2 an open relay? (except if MTA2 ==MTA1)
- And other questions (please add)
No need. The only question is:
Do you believe that he Return Path is a valid address to test?
If you don't think so, then the game is over :-) Nothing I can say any
futher but just point out, the bounce system is completely broken thing if
you don't believe in the return path.
If you don't believe it is valid because it is often SPOOFED or BAD, then
what is what the CBV is out to test.
This has the consequence that CBV is easely fooled.
Nothing. The CBV is faked out. You don't throw your hands, accept the
message and move on. No harm. You can cached the results if you like. But
if you need to do that, you might as well white list the sender.
It is as easy as to forge the "mail from" to a real
emailaddress: any "Postmaster(_at_)any-company(_dot_)com" or
"postmaster(_at_)any-organisation(_dot_)org" will do.
Again, if the Return Path is a presume to be valid, then the remote host
need to accept it or reject it.
However, in our CBV implementation, for backward compatibility reasons, we
skip the CBV for the postmaster address. Why? Because per RFC x821, the
MDA must accept a POSTMASTER fowarding path, so it would be a waste of time
to perform a CBV on the postmaster address.
This will also results in many false negatives.
(emails that are spam but not recognised as such)
How so?
As I said, RFC x821 clearly starts you must accept:
RCPT TO: <postmaster>
so it will be a waste of time to call CBV.
It could be SPAM, but thats not the point of the CBV.
hmmmm, I guess, we can still call it to do the open relay test! I am going
to try that!
Crashing SMTP
Anti spam rules are build on the implicit assumption that the whole
email can be forged "do not rely on anything that somebody else
has tested". This implies that you can not trust headers like
The CBV is a SMTP process and 2822 analysis is out of scope. It has nothign
to do with the headers. Just the return path.
In IP load
a typical CBV test will need about 30 IP datagrams. (Ps this is
only an informed guess, i will accept better guesses)
Well, I have to confirm your number, but it doesn't matter. TCP is an
overhead and doing an CBV in an open-ended basis is a bad idea.
You can not do a CBV without implementing other ideas to reduce the need to
the absolute minimum.
So CBV will work on a small scale but as soon as its is
used in a grand scale it will resullt in a denail of service.
I don't agree with the DOS, but I agree that an open end wide adoption
across the board will have new bandwidth issues. How much. One can make a
good guess. But as I said, you need to do intelligently to validate the
return path.
Keep in mind that does far, SPF and SENDERID/PRA are moving along and even
though believe there are new bandwidth requirements, the concerns seem to
be put to the side.
Where does this leads us:
CVB is not able to answer the importand question:
Is this email SPAM?
It was never MEANT to answer that question.
If CBV is used by many it will result in a DoS attack on MTA1
I don't agree with this concern.
CBV is easely fooled.
With a trackable zombie cite which is alittle better than having nothing at
all.
The fact is over 60-80% of all transactions are bad. And it usually begins
with a bad or spoofed. RETURN-PATH.
So for a while it will stop some spam, but in the long run it will
not work and it will ruin the email structure.
It stops quite of bit of the bad addresss. Where it was good or bad mail.
Who cares?
No one have ever said that it should be as an ultimate solution.
I see it as a "Return Path Validator" and for now, a black box concept. The
CBV is the current black box, and I am waiting for you to invent the better
black box so I can plug and play the Return Path Validator. :-)
Thanks for you comment, I have you understand the basic question. Either you
believe in the Return Path as a verifable entity or not.
Whatever implementation you use will be a overhead issue, regardless what
you might have. So you engineer the solution to minimize the overhead.
Is this optimization enough for wide adoption? I don't know. I won't say
yes. But I won't take a blatant "no" from people who have not truly explored
it completely by augmenting other ideas as well. I will say, they ought
the be a better way. Go find it. :-)
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com