Re: Submission identifiers

[Alessandro Vesely <[e-mail]>]

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?