Re: Submission identifiers2009-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 differ.
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?