Re: Submission identifiers


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), eachone 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 levelmechanism for rejecting abuses should not live in an well designedextension, nor in a clever but optional retrofit. Message levelmechanisms, such as DKIP and PGP, are apparently well promising.Transport level mechanisms, by their nature, are implemented in theenvelope rather than in the content. Because they are not necessarilyvisible to end users, their optionality makes transport fuzzy.Authentication has to be at the core of the specs, for relays as wellas for submitters.

We all have been applying various filtering expedients in these years;someone may have been more successful than someone else, but many haveto continuously adjust their filters, because expedients are notglobal rules. Whatever rule I can think of today, I'll have tocontrovert it tomorrow, because I need to come to terms with the worldout there. If you allow me to paraphrase your words, I don't want thestandard to reflect my ideas of how things would work in a betterworld: I want it to reflect _yours_. However, I don't want you to missany 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 verysimilar, in spirit, with the notion of Internet domain that I'm morefamiliar with. I guess the (partial?) failure of X.400 mail model isrooted in those details about levels and ADMD vs. PRMD distinctionsthat are difficult to understand. For the Internet, a greatsimplification has been brought about by MX records. That notion ofdomain, 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 comestraightaway:

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

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