The bad news is that in the end, they will be legitimate (CAN-SPAM)
making a CBV system a redundancy issue and more of a auditing/tracking
system.
Unless CAN-SPAM (both laws and enforcement, which is much harder)
spreads to the whole planet, the spammers will just move offshore
(maybe not the same folks, but there will still be spammers), and
they'll continue to forge adddresses (legitimate ones). So CBV will be
worse than useless. (which is why I didn't encourage people to use it-
as in the long run it would only increase complexity and overhead and
it wouldn't benefit anyone.)
That depends on the implementation. Sender-machine validation is still
important which is what the ASRG is pretty much focused on.
I would like to STRESS I am not bent on any idea whatsoever. Our main goal
was to provide the compatibility, be ready for new "access control"
proposals. So we provided hooks into each state point. The CBV turned
out to be something of a "what if" to see how we can control access based on
the current SMTP protocol. The day there is "something" better, it is
easily switched.
Personally, if I had my crutters, I would prefer a strong two way
handshaking system between the server and client defining the level of
conformance, product code concepts, caller id (ip) restrictions, time
restrictions, direct vs hub restrictions, etc. similar to the old Fidonet
FTN (FTSC1/WAZOO) protocols. But this is not reality.
I am not so skeptical of the laws being advocated. I believe the US model
will be used globally. I also personally believe the act did its best to
basically say there is only a few things the industry ask for without
completely wiping out the "right to do business," and that is, "Please do
not lie about your return addresses and the topic." But this is my
opinion on it.
Yes, I agree the advantage is for the spammer. With that said, they don't
need to go off-shore. The Act strengthens there legal position in the
states. You are already started to see direct marketers highlight these
very points:
"We are CAN-SPAM Compliant......
The CAN-SPAM Act supercedes state laws....
If you have any question, contact our legal department..."
Use a NULL address.
That's fine if systems don't reject the address out-of-hand. I suspect
some still do. My verifier tries to use a NULL address but if MAIL FROM
is rejected, it switches to a non-NULL address. (if the mailer rejects
RCPT TO because FROM was NULL then the sender is out of luck) but I'm
only verifying list traffic and I'm assuming that the other end isn't
doing CBV at SMTP time because up to now it's been a fairly rare
practice.
I still have to measure the NULL address rejection. See my response to Rolf
where I did some stats on this. It was higher than I thought, but still
small.
Of course, systems that do such checking are broken. Nothing says that a
NULL address signals a DSN.
Yes, I agree. But what does a NULL address signal? Yet another
clarification? Can a BOUNCE be sent based on the RFC822 header information
even though the ENVELOPE indicated a NULL return path?
Why not?
Because there are *lots* of cases where you want reports to go to some
other address than that of the person who sent the message.
I hope we are not confusing "the author" of the message. I am certainly not
trying to imply the author is involved here.
First, the MAIL FROM: return path must remain consistent thoughout an
entire route and only at the final destination, does the SMTP-receiver
prepend the Return-Path: header to the stored message. Is this not
correct?
Second, regardless of what is used in the MAIL FROM:, it still needs to be
valid. Is this not correct?
So what if a mailing list is using some other return path for its error
reporting. It still needs to be valid.
I've seen systems use a NULL in this case to avoid bounces from
mailer-daemons or use an alias to consolidate or redirect bounces for
further processing (i.e, auto removals, if possible).
But if its a NON-NULL return path, the RFC presumes it must be an existing
and valid address. That's all I am saying.
Well, sure the address is supposed to exist (or be null), because we
don't want to waste the resources of the mail system delivering reports
to nonexistent addresses. But that doesn't mean that it's the identity
of the sender.
I believe the goal of a "CBV" is to validate the return path regardless of
who it belongs too. In a way, the CBV is more of a SMTP compliancy tester.
But this does not a reason to throw out the baby with the bath water.
The CBV system works to eliminate a majority of the spoofing
spammers.
Not in the long term. At best it's a stopgap measure. I give it six
months to a year.
Hehehehe. Hard to argue. If one is to believe there will be a positive
effect with the advent of "CAN-SPAM Ready" spammers (the marketing has
already started), then the best a CBV can offer is auditing and tracking.
I see it as more of a configuration issue. The protocol doesn't have
to change to make this work.
Ok. Be nice to see some clarification of your thought :-)
It sounds like you're defining CBV performance in terms of CBV. The
relevant questions are different. How many of those messages were
actually valid messages that should have gone to the recipient even
if the return-path was screwed up?
Again, the complexity of the problem was reduce to SMTP compliancy. This is
really the only way to look at it. Once we begin to introduce
"interpretation of the mail content", IMO, we will be beating a dead horse.
In this case, you might as well just let the data to be received and perform
delay validation.
In my view, spam is just a symptom of the real problem - anonymous access
exploitation of the SMTP functional specification which begins with the
ambiguity of various parts of the spec, hence making the technical
implementations weak in enforcing compliance.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com