[Top] [All Lists]

Re: Submission identifiers

2009-01-26 10:20:45

John C Klensin wrote:
And it is not at all clear to me that an SMTP server that supports
a handful of closely-related people/accounts or a small enterprise
should be equated with an ESP for all purposes.

I meant ESP generically. Anyone who runs one or more SMTP servers, Hotmail, Intel, ACM, JCK, or the Wandering Laptop. Big or small, public or private, they all run globally visible SMTP server(s), each one for its own purposes, with its own style and policy.

As soon as one goes down the path of wanting to change,
restrict, or reinterpret what the specs say about particular
fields, you are restricting the applicability of your method to
a select group of friends at best or falling into one of the
more obvious "Anti-spam Kook" traps of requiring universal
deployment of your "improvement".  You have the perfect right to
reject any mail that doesn't conform to your ideas of what an
envelope should look like (with or without support from the
specs), just as you have the perfect right to reject any message
with Chinese content on the grounds that you don't read Chinese
so it couldn't possibly be for you and is therefore probably
either malware or just unwanted.  But either path is going to
reject legitimate messages from folks who, through no fault of
their own, don't conform to your expectations.   Personally, I
don't think that is a good idea.  On that subject, YMMD.  But
making significant changes in the standards, changes that would
invalidate many or most existing conforming implementations, to
reflect your ideas of how things would work in a better world...
well, probably isn't going to happen.

Those are exactly the reasons why I insist that a transport level mechanism for rejecting abuses should not live in an well designed extension, nor in a clever but optional retrofit. Message level mechanisms, such as DKIP and PGP, are apparently well promising. Transport level mechanisms, by their nature, are implemented in the envelope rather than in the content. Because they are not necessarily visible to end users, their optionality makes transport fuzzy. Authentication has to be at the core of the specs, for relays as well as for submitters.

We all have been applying various filtering expedients in these years; someone may have been more successful than someone else, but many have to continuously adjust their filters, because expedients are not global rules. Whatever rule I can think of today, I'll have to controvert it tomorrow, because I need to come to terms with the world out there. If you allow me to paraphrase your words, I don't want the standard to reflect my ideas of how things would work in a better world: I want it to reflect _yours_. However, I don't want you to miss any possible chance to heal the mail transport system. It's dying.

As I said, big change in semantics (we differ about "slightly"),
especially since, while it is convenient to talk about ADMDs for
some purposes, SMTP has no such concept (and, if you don't
understand the policy implications of the X.400 definition of
ADMD, you probably should, because it is very much tied up with
my comments about types of ESPs above).

Why? I'm not much into X.400 specs. That concept of domain looks very similar, in spirit, with the notion of Internet domain that I'm more familiar with. I guess the (partial?) failure of X.400 mail model is rooted in those details about levels and ADMD vs. PRMD distinctions that are difficult to understand. For the Internet, a great simplification has been brought about by MX records. That notion of domain, the part to the right of the strudel, characterizes SMTP.

But the big problem is, again, transition, since a server would
have no way to tell whether a client was legitimately and
appropriately providing a name under the old rules or under your
new ones.   And that takes me back to my earlier suggestion: if
you want this information, define a new extension or keyword for
doing it, one whose argument semantics you really can control
and one whose use would explicitly invoke your rules and
interpretations.  Although I'd predict that you'd have trouble
getting it off the ground, another possibility would be to
propose to replace EHLO with a validated-hello command, VHLO,
which would be just like EHLO except for support for a different
argument architecture.  It would take me about ten minutes to
write an I-D specifying that.  Of course, it would take me even
less time to shoot the idea down on the basis of deployment
costs, etc., but, again, your mileage, and assumptions, may

Hey, thinking about it, VHLO looks a very clever idea! Two pros come straightaway:

1) It would follow the steps of the successful transition from HELO to EHLO, reinforcing the concept that there are two possible salutations until all hosts have upgraded.

2) I'd imagine that matching an A record won't suffice: At least an MX with the same address would be required for VHLO. (To MX or not to MX has been discussed at length.) Would it be safe to conjecture that a server could rule out zombies that way?

<Prev in Thread] Current Thread [Next in Thread>