----- Original Message -----
From: "Eric S. Raymond" <esr(_at_)thyrsus(_dot_)com>
To: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
Here is my evaluation of the state of play:
1. Pull systems as a replacement for SMTP are a non-starter, if for no
other
reason that the deployment problem is impossible. Besides, the sponsors
of
CAN-SPAM won't accept "scrap the email network and start over" as a
response
from us -- it's not politically viable, we'd just blow our credibility.
Hear, hear! Lets keep in mind also that the premise we must work with is
adherence with the current standard which means backward compatibilty.
2. We MUST develop a labeling standard. Technical arguments that some
other approach (such as MTA labeling) would be better are beside the
point. We've been presented a political test -- having been asked for
input in the CAN-SPAM draft, can we come back with something that assists
the FTC and the legislators? If we don't, (a) the labeling standard will
be written -- probably badly -- by somebody else, and (b) we'll blow
our credibility.
From the developer perspective of the SMTP server, I don't view this as a
technical issue to be dealt with at the SMTP level. I view it as a
sysop/admin Option to be provided as part of the configuration that might
interface with with a POST-PROCESSING concept. In other words, once the
DATA is received, the transaction is technically complete.
In our case, a HOOK at the DATA state is offered to run a 3rd party
mail-filtering process with rules defined by the sysop/admin. The RFC
already gives us the ability to provide a rejection DATA response code (4xx,
5xx). It discusses some examples dealing with header comformity but I
recall when we added the HOOK, there was many questions as to what responses
were applicable. For example, in our case, our design concluded with the
possible responses:
250 Message accepted for delivery.
250 Message accepted, delivery pending
4xx Message rejected by mail filter. You may try again.
5xx Message rejected by mail filter
as 3rd party developers began to implement the hook, it needed more
flexibility, so now the SMTP Data Hook offers a way to provided hook-defined
responses.
The RFC does indicate that SMTP servers make response code flexible. So
this change complied with this recommendation.
How does it apply to LABELING?
In lieu of a protocol change, i.e, a new command: SUBJECT: xxxxxxxx, to be
provided before the DATA stage, we are left with DATA analysis to perform
this function.
So a SMTP product can provide the sysop a configuration option:
[CAN-SPAM TAGS]
ADV:PORN=REJECT
ADV:DRUGS=ACCEPT
etc. But this will only with vendors modifying their SMTP software.
To make it work with legacy systems, the DATA is accepted and handled by
NON-SMTP post mail processing methods.
So because of this, it is not really a SMTP protocol issue in my view.
3. Hector Santos has a point about strict construction of the RFCs being.
That
point should not get lost in arguments about VRFY vs. LMAP.
From a technical aspect, I strongly belive it is required. But more
importantly, I envision legal issues if SMTP is enhanced in such a way that
systems DO begin to filter/block systems from delivering mail that
"mistakes" can occur (or NOT), but nonetheless, done so effectively that a
commercial spammer sues for tortious interference. I know if I as was the
commercial spamming business sending in my view, legitimate spam, and your
software was blocking it, I will be looking to sue someone. With
CAN-SPAM, it makes this possibility even stronger.
So the SMTP specification must make it VERY clear every possible functional
flow operation based on comformity of the specs. I believe when it is all
said and done, it boils down to trusted clients with valid return addresses
with strict and specific guidelines on what is considered valid and when it
is considered valid.
4. LMAP seems neglected recently. This is bad. We're being distracted
by stuff that (I think) is less important than putting an IETF stamp on
*some* LMAP design.
LMAP can help address it. Anything that does more "checking" per se, will
work. But it requires additional DNS administration which does not fit the
current SMTP frame work, hence it will not be immediately adopted. Oh, I
can surely add support for it, but it doesn't help if others do not or are
slow to do so.
One improvement to LMAP can be to use the subdomain concept to provided LMAP
information. That way SMTP DNS operations do not need to change and keeps it
at 1 lookup, for example:
current: mx1.whoever.com
LMAP: mx1.lmap.whoever.com
This way, all it will take at the SOFTWARE level is small change to check
for the lmap sub-domain.
I have no problem with this, but nothing is going to work unless the specs
are changed to allow for strict SMTP checking.
---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg