On Thu May 26 2005 06:55, Tony Finch wrote:
None of the LMAP proposals are applicable for MUA-MSA communication.
I didn't claim otherwise. However some of those proposals refer to
indiscriminate use by all SMTP receivers (which obviously includes
MUA-MSA SMTP) and/or attempt to limit the scope to a subset, such as
MTA-MTA, where in fact neither client nor server has any reliable
means of determining whether its peer is an MUA, MSA, MTA, MDA,
telnet session, etc.
As I
said before, you can't expect direct MUA-MX communication to work very
well because of MUAs' simplistic SMTP implementations and because of MX's
anti-spam strictness, and no common MUAs support direct-to-MX
communication.
I'm not going to debate whether a particular piece of software is a
pure MUA, or incorporates elements of MSA or MTA. Such distinctions
have a place, but they can also get in the way. Clearly, in SMTP,
some SMTP client needs to connect to an MX server to deliver SMTP mail.
And as noted in a real-world example in another message today, that
sometimes needs to happen from an end-user's host. Should be no
problem; SMTP requires no prior arrangement, and as noted above, there
is no reliable way for either party to a session's transaction to
determine the other's status as MSA, MTA, etc.
So your objections are mistargeted, and what is more your
explanation has nothing to do with conflating sending and receiving.
When a piece of software -- categorize it as you will -- connects to
an SMTP server and presents a domain name derived from a receiving
mailbox domain in EHLO/HELO, there is such conflation. We might
tentatively agree that such software isn't operating according to
assumptions behind the rules of a twenty-year-old protocol, but the
present-day facts of life are such that in many cases there simply is
no other option available to such software.
If such a sender wants to use CSV
The problem is where the *sender* *doesn't* want to do so, but some
other party has decided to do so.
* I would add that the CSV draft fails to state *which* SRV record(s)
(service, protocol, etc.) to consult,
Incorrect. Section 5 of the CSA spec includes the SRV record specification
template.
I was referring to draft-ietf-marid-csv-intro-02, which says "Query DNS
for a SRV record" with insufficient detail. [and don't bother pointing
to the references -- that provides only a vague reference to an unspecified
draft dated June 2004, which would have expired months ago]
Maybe. But contrary to RFC 2821 it says "A sending SMTP client MUST
supply a published domain name as the parameter to an SMTP HELO or EHLO.
[sic]". 2821 (and 821 before it) explicitly permits an address literal.
There is an (incorrect) assumption throughout the draft that EHLO/HELO
always entails a domain name.
You are making the fallacy of arguing from the general to the specific.
No, I'm commenting on the proposal as described by the draft as written.
That draft does not say "A sending SMTP client using TCP and supporting CSA"
or anything similar, nor is there an explicit scope-limiting section in
the draft. Now it may very well be the case that that and other issues
mentioned above can be addressed -- but that would be some future version
of a draft, not the one under discussion.