Hector thanks for your comments.
I hope you appreciate mine as well.
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?
Yes, in a later version I will rename it to RP-MTA
MTA2 MTA that sends the email to be checked to MTA3
MTA3 MTA that does the Call back testing
You lost me with this.
There is no reason that MTA1 and MTA2 are the same host
See Keith Moore's MON (Mail Originator Network) and MRN (Mail Reception
Network).
the MX points to the MRN. the MON can be a MSA
MTA1 is part of the MRN, MTA2 is part of the MON
I myself sends email by SMTP relay to my ISP and receive bounces back via my
account at my webhoster. This is all good old proper SMTP.
And SMTP still allows multi hop transactions... so MTA2 can be between MTA-RP
and MTA3. The options with SMTP are almost endless.
Remark
If you do not want to allow multi hop SMTP anymore you are really ruining SMTP.
Maybe I should have cut MTA3 in two
the MTA that does the call back doesn't have to be
the same MTA that receives the email,
But I thought that was complicating the document unnecessary.
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.
No it can be reliable, I receive bounce notifications all right, I receive
them, they come to me but do not go to MTA2
they go to MTA1 the RP-MTA
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.
As long as i receive the bounce notification so the address is valid and mine.
What is wrong with it?
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.
Only one??? ;-) (joke)
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 :-)
I do not think that SPF works ...
And my situation is a bit to complex for SPF (I guess, i have not looked in it
deeply and i do not test on it either)
The first problem is: what questions does CBV really answer?
Is the Return Path Valid.
Valid only in the sense that you can send email to this address, it does not
imply that this address has any relation to the sender of the email.
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.
I think we can agree to disagree on that.
You do not want me to believe that return path's can not be spoofed ???
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.
The overhead is the BIG problem, especially if CBV solves almost nothing
But for timeouts, the question is this enough to throw the baby out with the
bath water.
I think the time-out issue is solvable.
Like the reverse CBV issue, these are no real problems at all.
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.
In principle all right, but it tests the wrong MTA you should test MTA2 not the
RP-MTA, (remember the email is coming from MTA2, not from the RP-MTA)
Wonder some time why Rbl testing uses the IP address of MTA2 and not the return
path domain that links to the RP-MTA?
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.
The problem is it can be valid (in the sense that you can send emails to it)
and Spoofed (in the sense that it has nothing to do with the sender of the
email) at the same time
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.
That's not the question, the question is
Is the cure worse than the decease, (if done on a really big scale)
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.
What do you mean by backward compatibility?
Are you not in a real nice way saying: sometimes CBV won't work , especially
with clever spammers that know that Postmaster addresses always should be
accepted by MRN.s
So please spammer do NOT use Postmaster(_at_)any-company(_dot_)com as return
address.
This will also results in many false negatives.
(emails that are spam but not recognised as such)
How so?
You will not recognise it as spam, if you cannot do the test, that is a false
negative if it is spam.
Simple as that. Or do you have an other definition of a false negative?
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!
But please test it at the right MTA (MTA2)
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.
This was just an introduction to this point, my point is that other MTA's
cannot rely on information that other MTA's put in header lines or other parts
of the email.
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.
Sorry I meant IP packets instead of IP Datagrams and really
.......>>>> THIS IS WHAT MATTERS <<<<<.......
This is what causes the BIG PROBLEM
This is why the cure that is worse than the disease
And more of this kind of sayings.
You can not do a CBV without implementing other ideas to reduce the need to
the absolute minimum.
Yes about all other possible spam tests DNS - RDNS almost "everything" even
including bayes filtering should be done before this... and even then
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.
And the internet load of those UDP - DNS based methods are very small compared
with CBV...
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.
Not if it means that somebody else cannot send email anymore
The fact is over 60-80% of all transactions are bad. And it usually begins
with a bad or spoofed. RETURN-PATH.
That maybe is only now (2005) with CBV it will become proper Spam , with a real
valid return-path. Is that a real gain???
Not for the people that are the unlucky users from that 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. :-)
CSV, BATV???
Thanks for you comment, I have you understand the basic question. Either you
believe in the Return Path as a verifable entity or not.
The first thing then is to believe it can be spoofed.
Whatever implementation you use will be a overhead issue, regardless what
you might have. So you engineer the solution to minimize the overhead.
But shooting with canons to kill ants isn't the way...
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. :-)
By the way, you can use this test web page to try the CBV and SPF.
http://www.winserver.com/testwcsap
Go ahead and try way with different combinations of parameters.
I will be interested to see if you find some false positives.
I played with it for a some time and did not get any positives out of the CBV
test.
Only when I used fake domains but that is not really an CBV test. that just
pointed out that an MX record test didn't exsist
So let alone false positives
Interesting were the timings, the CBV takes about 5 times as long as all other
tests together.
Can you make it count IP packets??
Do you see what I mean with that CBV has a larger load on the internet then all
the other tests together?
And I missed DNS A record, RDNS ptr and CSV testing.
and some other RBL tests.
They also help against spam and they really take less bandwidth than CBV.
TIP: Select High Verbosity Logging to see everything.
I did that why i missed it...
Even example.net as domain and example.com as EHLO worked
Even from private IP's it worked
It needs some more testing.