Re: [Jmap] Submission

[Ned Freed <[e-mail]>]

> Won't the nexthop generally be the thing that the port-587 server forwards
> to?

That's highly unlikely. There's quite a lot of activity associated with
message submission: Access control, auditing, spam/virus checks, content
filtering, etc. JMAP doesn't make any of that magically vanish.

Of course this doesn't mean that messages are going to be submitted using
the SUBMIT protocol. But there has to be some kind of agent that performs
these functions, irrespective of how you talk to it.

> After all, JMAP already handles authentication, and it's not clear to
> me that a typical JMAP server is easily able to authenticate on behalf of
> the end user in a way that a port-587 server accepts.

Proxy authentication is widely if not universally supported using any
number of techniques. And again, you don't get rid of the need to
perform any number of actions based on the submitters identity just because
the user already authenticated to JMAP.

> Assuming that JMAP forwards to the filter or smarthost, then requiring that
> JMAP servers be able to forward SMTP extensions looks really odd.

I have no idea what this "filter or smarthost" thing is that you're talking
about, but I can assure you that if it isn't directly integrated into the
SUBMIT server so it has direct access to credentials and can return immediate
failures rather than delayed DSNs, you have a serious implementation problem.

> A submission server on port 587 cannot forward SMTP extensions from its
> nexthop, why should one on port 443 have to?

Of course it can. Ours does this routinely.

> The usual answer is "so as to not need a corresponding JMAP RFC whenever
> there's a new SMTP RFC". That strikes me as poor. A new extension requires
> an RFC and three kinds of implementations (SMTP client, submission server,
> filter server). The RFC publication bit isn't usually the bottleneck among
> those four.

I guess you missed the recent discussion about the incredibly high cost of
RFCs. (Not that I agree, but one of the reasons I disagree is that we've worked
hard to eliminate the need to generate gratuitous material from the process.)

				Ned