From: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>
On Tue, 28 Jun 2005 11:21:02 EDT, Hector Santos said:
(Please feel free to re-cite material that is *directly*
relevant to the *specific* point under discussion, namely the
concept of skipping a postmaster@ on a CVB...)
I thought I made sufficient comments about it to make it clear
was not a standard, but rather an implementation detail pretty
much like most things that fit within the "standard." already
in place. (Don't quote/comment this. There is more below).
In addition, it should go without saying your personal opinion on
this long time debate of CBV. From my perspective, you seek not
to consider the proof of concept regardless if it was perform via
CBV or not.
So before any agreement can be reached, there more be atleast a
common agreement the Return Path is a an veriable item. If you
don't believe that, there isn't going to be more agreement on
anything else.
On the other hands, if you do believe the proof of concept
and question just the CBV method, then I can understand fully
what your concerns here 100%.
Yet I disagree on the reasons why it should be considered or
to use completed throw it out without exploration.
We do have it implemented Iso can relate to what is the
experiences. Not just on my personal support site, but among
thousands of customers using it who will be the last set of
people I would introduce a questional concept.
This is not a "tool" for just my box. You need to take into
account that there has been a tremendous amount of field testing
prior to the official release nearly 2 years ago.
With that said, I will more than happy to answer your questions.
On Mon, 27 Jun 2005 21:10:38 EDT, Hector Santos said:
In regards to a CBV, a postmaster(_at_)domain is skipped.
a) This is codified in a standard, where, exactly?
A perfectly valid question regarding a CBV - is there any
standard that says a postmaster is skipped? If not, you're
arguing from "one/several implementations happen to do it that
way", and will need to justify why this behavior is done.
You are correct. A good question. But try to see it as I read it.
You and I know perfectly well, there is no standard because there
is no RFC or draft specification for a CBV. So I have a problem
with this statement. You can say the same for many non-standard
work that fits into the SMTP protocol.
So we are talking about specific implementation details and our
specific engineering principle is to do it with the goal of
making it fit into the SMTP framework with maximum compatibility
considerations.
Ok, all I can do is spell out out implementation and the
justifications for its logic. Is that sufficient enough?
First, the basic premise of the CBV is based on the idea that the
Return Path is a verfiable item. It is important item because its
role as a bounce address for non-delivery mail.
Second, it was not for the first that over 60-80% of the
transactions use a bad return path, we would not bother. If it
was 10% to maybe 30%, we would probably not bother. But the fact
is, it is by far the majority of transactions. This is not use
our stats, but industry stats.
The HELO spoofing is about 12-15% by our estimates. However, in
general, since there is history of good reason for having a
incorrect client machine name, for example MUAs using netbios
computer names, in my view, there is no current good reliable way
to do a helo validator. The payoff is not high at the moment
because there is no requirement to have this valid for mail
operation unlike the return path where there is a mail operation
requirement for it to be valid.
So the payoff is high to explore a return path validator. The
tradeoffs, if any, are significant.
b) This provides spammers a easy way out by sending with MAIL
FROM:<postmaster...'
Particularly in light of the fact that the scheme has a big
"SPAMMERS, DO THIS TO EVADE" hanging all over it...
Independent of spam considerations, POSTMASTER(_at_)DOMAIN is used at
MAIL FROM. Thats a given.
How much by spammers? I would have to do a report generation
of my 2 years of daily recorded stats.
The issue is should it be used for RETURN PATH VALIDATION?
The main reason we skip it was because, if I remember, there was
an Exim CBV implementation (Exim calls it CallOut or something to
that effect) that was using POSTMASTER for the call out Mail
From: address.
So as you would correctly suspect, since we were not original
skipping the postmaster address for verification, we had 2-3
level CBV loopback if I remember.
So I remember talking with the administrator and we both agreed
that a NULL return path was better.
Nonetheless, I still went ahead and added the CBV option in our
implementation to avoid future postmaster loopbacks:
SkipPostMaster True ; If mail from postmaster, skip CBV
In my view, this is safer and make it more compliant with
standard SMTP BOUNCE operations after the transaction is
accepted. However, this is not possible because we do use a SMTP
level RCPT validation so that bounces are not possible at this
level.
So it is only optionally skipped for CBV purposes.
Also, the admin had the option to define the CBV MAIL FROM:
address to use:
SapMailFrom <> ; address used for MAIL FROM
This came into play during early R&D to explore how remote systems
reacted to NULL return paths RCPT checks.
This was related to the issue I think Verizon came across whether
they use an alternate mail from after a NULL attempt.
I don't particular agree with this method because of what we learned
is that you don't use the NULL, then you do run the risk of a loopback.
So althought the option is still there, it is not recommended to change
it.
Finally, remember this. For my design consideration, I am firmly
aware it would be there is high CBV no trust issue with PASS results.
So the goal is to mustly address the Bad Host and false result and
the small open relay test. If that doesn't give a result, than you
throw up your hands, accept the transaction and move on. The CBV
did the best it can do.
Fortunately, the payoff has proved to be high because again, the
majority of the transactions are indeed bad.
c) Wander over to www.rfc-ignorant.org and see all the
sites that *don't* properly support 'postmaster', so the
assumption that "We won't check it because we "know" it's
operational" is severely b0rked.
Combined with the fact that enough sites in fact manage to *not*
support "postmaster" in violation of the RFCs that automatically
white-listing it is a bad idea.
Ok, did we misunderstand, did the above answer this?
POSTMASTER is indeed annoyed. It is skipped for CBV purposes only.
So we have a non-standard practice, combined with an obvious
exploit, and of dubious actual usefulness in a real world that
has difficulty following the *current* standards. If you have a
concrete technical explanation of why it's *still* a good idea in
face of all that, let us know....
Like I said, to me, this is more of the status quo statements
that existed in past CBV debates. It is more on the insulting
side and more on 'stubborness side'
It seems that no matter what I say, it doesn't matter. There is
no benefit of the doubt, there is no consideration whatsoever for
the technical experiences we do have. Like we don't matter.
Thats offensive to me, but I am not a hobbiest. This is a
commercial system and I have thousands of customers using our
mail system, which is just about 20-25% of our business (and
growing). But we over hundreds of thousands of customers using
our main product where the mail system is fundamental part of it.
It just may not be the part the customer is using.
That is absolutely NOT to say your comments and experiences is not
heeded. I do learn from everyone here. Trust me. We are
constantly updating and improviing the system based on the BCP
extracted from the comments and discussions, etc. In fact, you
helped tremendously with our DNS client implementation MX
expansion logic for the SPF processor. Remember?
But to throw out accusations, that we are non-standard,
introducing exploits, using stupid and dubious considerations
with no practical insight with real world operations, well, my
friend, that is insulting to me.
It leaves me three choices:
- Ignore you
- Defend myself
- Try again to explain
I try to take the high road and do the latter, but it typically
does not matter with people, I am sorry to say, like yourself.
You made your might up.
But you see, I am optimist, and I have been at this cyberspace
communication game for over 30 years and I can see the different
in who is who. Its not hard to see.
Anyway, I hope the details I provided above is sufficient.
I can summarize what we do with maximum compability
considerations:
- Return Path is a verifiable item per RFC 2821.
- Applies only for anonymous final destination transactions.
- A suite of Sender Authentication protocols called WCSAP is
used check the transaction parameters. CBV is the final
check.
- WCSAP is called after the RCPT TO is determined to be a valid
local user for an non-authorized session only.
- WCSAP is skipped when MAILFROM is <> or POSTMASTER(_at_)DOMAIN
The postmaster skip is optional.
- A fast White/Black rule based filter table is applied,
- RBL is applied
- LMAP is applied (DMP, SPF, CALLERID)
- CBV is used as a final check
- CBV performs a 100% SMTP Client callback with the
exception of having smaller timeouts.
- NXDOMAIN, BAD connects are rejects.
- STATE machine problems are rejects.
- CBV uses NULL mail from (default), to test sender return path.
- CBV uses an open relay test for random address acceptance.
Other stuff:
- CBV has VRFY option to use instead of RCPT. If enabled,
a non-supported VRFY fallback to RCPT checking.
- CBV uses NOOP to provide a identification "idea".
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com