Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
On Tue, 27 Jan 2004 06:15:11 PST, Carl Malamud said:
1. The fact that esmtp had no way for the receiver to indicate
that they don't want to be solicited.
2. The fact that our mail headers are being littered with
insertions by filtering software and, increasingly with obscure
markings like "ADV" required by policy makers.
I'm still puzzled by what problem we actually expect this to solve.
As am I. I strongly suspect that it won't solve the spam problem. I'm
pretty sure that restricting the scope to ESMTP (i.e. ignoring plain SMTP)
is a mistake. I share the doubts raised by others about whether an ESMTP
server or its operator can make blanket assertions about all of its
recipients. RFC 2821 has made EXPN and VRFY less than mandatory due to
abuse in harvesting email addresses; providing a back door for address
harvesting ("Alice, Bob, and Carol...") is a questionable move in light
of the changes to EXPN and VRFY. I fail to see how adding yet another
header field (i.e. in addition to Keywords) to convey originator-supplied
keywords is going to have any effect on reducing "litter" added by filtering
software -- indeed such a redundant header field could be considered
more litter. And ignorant policy makers will continue to attempt to
impose silly requirements which will be ignored in practice no matter
what we do.
No SMTP extension can by itself reduce spam. A spammer can always circumvent
such a mechanism by starting a session with HELO rather than EHLO, in
which case extensions simply are not involved. Case closed. At best, an
extension might serve to in some way tag legitimate mail. Given the fact
that for many email users the quantity of spam already significantly
exceeds that of legitimate mail, addressing the issue of tagging
legitimate mail seems like the path of least resistance and best
efficacy -- certainly relying on accurate sender-provided labels on
spam is a lost cause (it's not "solicitation" it's INFORMATION).
If there is a clear statement of a problem, I can't find it in the
draft. Searching the draft for "problem" yields:
1. some text about legislation in Australia indicating that a certain
activity is NOT a social "problem" there.
2. a statement that "This proposal is not meant to solve the UBE problem"
3. "solving the same problem
addressed by this service extension." We still have no idea what that
"problem" might be.
And that's all. If the author wishes to pursue this draft further, it
should be rewritten to provide a clear statement of the problem that it
is intended to solve, near the beginning of the document. It should be
clear from reading the document that any requirements imposed by the
text contribute to solving that problem. If it's not self-evident, there
should be some discussion illuminating the contribution to the solution
of the specified problem. All of the (frankly, tedious in a technical
document) anecdotes should be removed or at least relegated to an Appendix.
More comments on recent discussions:
Carl Malamud:
Yes. Relays MUST simply relay messages. Only when a message
has reached an MTA under the *direct control of the recipient*
can other actions be taken. Is everybody happy with that
phrase before I start sprinkling it throughout the draft? :)
I don't mind the phrase, but you need to define it somewhere. For
instance, does "direct control of the recipient" allow an ISP to make
assertions on behalf of its customers? Does it allow a business's SMTP
server to make assertions on behalf of its employees?
Oof. No way am I going to try and define that concept. :)
How about a reference to section 7.7 of 2821, "Scope of
Operation of SMTP Servers"? That seems to cover this
situation pretty carefully and I can quote the whole
section (it only has 2 paragraphs).
First you need to decide whether or not it's relevant to say anything at
all about relaying. If the proposal is about relaying (at least in part),
then you need to decide what it is you want to say about relaying. RFC 2821
section 7.7 certainly doesn't say "Relays MUST simply relay messages". In
fact it gives relay operators quite wide scope in deciding what to relay
and what not to relay.
This proposal is about the
conveying of keywords *not* the decision to accept or
reject messages. That is, potentially, the subject
of other standards or laws, but this proposal is a
mechanism for the message sender and others involved
in the delivery of the message to assert keywords,
and for the recipient to assert keywords. These
words are all drawn from a registered list.
Then why not simply register keywords (for use with the existing Keywords
header field) and leave it at that? Transport (SMTP/ESMTP) has no
business in poking about in the message content (and I don't want to give
Big Dumb Fascist Brother or his minions any excuse for doing so).
to say
"recipients Alice, Bob, and Carol also refuse to accept ADV messages"
That's the back door for purveyors of "20 million verified email addresses".
But there's a more fundamental problem. The draft states:
In the case of the
"PER-RECIPIENT" option, this information is not present in the
initial exchange and is instead presented as part of the "MAIL-FROM"
command.
RFC 2821 gives SMTP command sequence as first MAIL FROM, then RCPT TO.
How is an SMTP server supposed to give a per-recipient response at the
MAIL FROM stage, when recipients have not yet been specified?!? It
turns out that the draft later contradicts itself by giving an example
that shows the response after RCPT TO,not MAIL FROM (which contains
no hyphen, by the way).
Arnt Gulbrandsen:
If I'm wrong, NO-SOLICITING at least shouldn't hurt.
Any SMTP extension that doesn't solve a specific problem (or at least
contribute significantly to doing so) does hurt. It causes people to spend
time on fruitless endeavors that could more productively be spent on
effective solutions to real problems. It causes bloat in SMTP server
software. If it also provides a back-door entry to private information,
it is definitely harmful. If it turns a 1k spam message into a 1.1k
spam message it makes the spam problem bigger. If it appears to give a
naive user reason to complain to/about a joe-job victim, it's harmful.
If it contradicts established SMTP protocol requirements or causes
confusion about those requirements, it is harmful.
Frankly, I see nothing useful in the proposal as it is currently
presented, and a great deal of potential harm in a number of areas.
Parsing Received: and adding the information to SMTP-level arguments is bad,
because it adds complexity: If Received: can be parsed, the recipient
MTA/Sieve/MUA can do it and there's no need for RCPT TO arguments in the
first place.
That's a big "if"; there are already a number of widely-deployed MTAs that
generate unparseable Received fields. It's unclear if that can be fixed.
Received was, according to RFC 1123, primarily intended for human use in
manually tracing messages. As it stands, there is little information in
Received fields which is simultaneously machine-readable, useful, and reliable.
The machine-readable trace information includes the easily-forged (and therefore
unreliable and useless) HELO/EHLO name, whereas the reliable information
(client IP address) is relegated to a comment, if present at all. Perhaps
that can be fixed. Perhaps Received needs to be replaced. I'm not sure. But
I am certain that adding additional cruft to Received isn't going to improve
matters; it will simply provide greater scope for incompetent implementors to
generate unparseable fields.
RFC 1123 perhaps erred in failing to specify a machine-readable mechanism
for recording the client IP address in a Received header field. RFC 2821
attempts to impose structure on a comment in order to provide for recording
client IP address. However, a comment is just a comment, and is not a
machine-readable part of a structured header field; it has the semantics of
whitespace (RFC 822). This draft attempts to impose semantics on comments
also, and that is doomed to failure.
Moreover, the example given in the draft lacks the mandatory "from" component
which an SMTP MTA is obliged to include.
Summary: the author should reflect on exactly what problem he is attempting
to solve, and formulate a clear and concise statement of that problem. He
should then consider whether an SMTP extension is capable of solving that
problem, including the applicability of extensions to the problem domain
in the presence of widespread use of unextended SMTP. If he still feels
that an SMTP extension can solve the problem, he should provide a clear and
concise specification for such a mechanism and he should provide an
explanation of how the mechanism proposed in fact solves the specified
problem. He should pay particular attention to the specification of the
SMTP protocol and the text message format (RFCs 822 and 2822), ensuring
that his proposal does not conflict with those standards, and he should
examine possible security and privacy issues related to his proposal.