Re: I-D Action:draft-newman-email-subaddr-01.txt

[Keith Moore <[e-mail]>]

Dave Cridland wrote:
>
>> > Subaddressing isn't described anywhere,That's the whole point, I
>> believe. Subaddressing has always been a
>> matter of local conventions (like the [e-mail]
>> convention in many environments), not needing to be "described".
>>
>>
> Yes, it's a convention local to a specific ADMD.
I don't know what an ADMD is in the context of Internet email.  AFAIK
it's never been clearly defined in this context and I think it's
probably misleading to use the term.

> This memo does indeed describe one very common, and useful,
> convention. John Klensin (and, I think, Keith Moore) both suggested
> that I add text to make it exceptionally clear that externally to the
> ADMD, there is no way to tell if a particular address is (in the
> phrasing of the SIEVE subaddressing extension) a detailed address or
> not - these are indeed perfectly legal addresses.
the statement needs to be stronger than that.  for the most part, nobody
except the authoritative MTAs for the recipient's domain should be
interpreting the local part of a recipient address.  similarly, nobody
except the MSAs for a sender's domain should be interpreting the local
part of a return address.

having said that, if lists do fuzzy matching on addresses (recognizing
that in general there are often several equivalent ways of spelling an
email address) they're just using heuristics to decide what traffic to
forward to subscribers.   this is no different than any other
content-based heuristics (e.g. spam or virus filters) that they might
employ to decide what traffic to forward to subscribers.  nothing
(including this document) should require a list to accept mail from an
address that is similar to, but not quite the same as, a subscriber
address.  it would be silly to say to a list "you can filter based on
message content but you can't filter based on the local-part of a from
or return address".  but if a list can tune its filtering heuristics to
work better, the list might provide better service to its subscribers. 
>> If I understand you well, you suggest to create (not describe) a new
>> concept, "global subaddressing", with a standard delimiter and
>> subaddressing-aware software, allowing new tricks (like the MLM you
>> mention, which accepts mail only from subscribers and who can
>> recognize them even when they use subaddressing).
>>
>> That's may be a good idea but it is something new, not a description
>> of a current practice.
>>
>>
> Well, somewhat to my surprise, Keith said this has been going on for
> some time, and John said it was not especially different to the use of
> "post only" addresses. Arguably, this *is* current practise, albeit
> not widespread, and is unblessed primarily due to the absence of this
> document. I freely admit that there's cases of interpreting
> subaddressing where I'm unsure that the actor is doing the Right
> Thing, and hence there's also some tightening up to do.
fwiw, I was about to write my own version of this document, and I would
certainly have mentioned the case of a mailing list doing fuzzy matching
on a sender address vs. its list of subscriber addresses.

(what I tend to do for most lists is to subscribe twice - once at my
normal email address, and again at the subaddress.  then I set "nomail"
or the equivalent for the normal address.  that way I can send mail from
my normal address and have the list subscription go to the subaddress)
> But, this is not a "global" thing, it's specific to an ADMD. The only
> case where I suggest (or rather, Chris Newman suggested and I watered
> down but essentially agree with) that actors external to the ADMD
> should consider the convention is MLMs, essentially because they're
> acting per-pro the user in a sense.
>
> Using a standard -- or at least heavily promoted -- delimiter doesn't
> preclude people from choosing another (or another method entirely),
> but it does mean that when deploying an MTA and a Store, for example,
> if both claim to be "Subaddress-aware", according to RFC-9999, then
> they'll both work together nicely.
fwiw, bulk_mailer recognizes  - = / . # % + because at the time I wrote
the code, I found cases where all of these had been used to delimit
subaddresses.  compared with just - and +, this adds 6 whole bytes of
code and a few dozen cpu cycles per comparison.  I really don't think
that having one or two widely advertised conventions for subaddress
delmiting is a good idea, precisely because I don't want to encourage
MSAs and MTAs and MUAs to be too smart about addresses.  what I really
want to encourage is mostly these two things:

1. giving users an extensible space for their email messages is really
useful
2. yes, it's legitimate for these printable characters to appear in the
local-part of an email address
>> > No, every component needs to know about it.
>> > > 1) The final MTA.
>> > 2) The MDA.
>> > 3) The MUA.
>> > 4) The Submission server.
>>
>> Can you explain why the MUA and the MSA need to know it?
>>  
>>
> Some MSAs restrict usage of a reverse-path to specific authenticated
> users, for example, I might only be allowed to use
> <[e-mail]>, and not <[e-mail]>. Such MSAs need to
> be aware that <[e-mail]> is also valid for me, because it
> is the same "primary address", even if they've never seen it before.
yes, MSAs that verify the return address need to be aware of which
return addresses are (a) valid and (b) usable by the authenticated
submitter.
> An MUA wishing to provide a user-friendly UI to subaddressing also
> needs to know the convention, in order to be capable of forming
> local-parts for use in both message header fields and envelope
> reverse-paths. If it's additionally performing some specific actions
> on message which are to be considered directly addressed to the user,
> then it needs to know for this, too.
so far, I'm unconvinced of this .


Keith