[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working group last call on protocol document set
steve.hole> At this time I would like to issue a working group last call on
steve.hole> the collection of three protocol documents:
steve.hole> draft-ietf-msgtrk-mtqp-03.txt
We need a new revision of the -mtqp- document from Tony first as there are
issues from Philip Hazel and myself which haven't been taken into account
in the -03 version. I've attached them below.
--- Begin Message ---
2. Basic Operation
The second paragraph describes how to determine tracking host to contact.
How about a host like this:
gshapiro.net IN SRV mtqp tracking.gshapiro.net
IN MX 10 smtp.gshapiro.net
IN MX 20 smtp.sendmail.com
In other words, a dedicated tracking server for gshapiro.net and two MX
records. When an SMTP message is sent, smtp.gshapiro.net happens to be
unavailable so the message goes to smtp.sendmail.com. If an MTQP client
then tries to track the message, it will use tracking.gshapiro.net (due to
the SRV record). However, tracking.gshapiro.net doesn't know about the
message yet (still in smtp.sendmail.com's queue). The lookup fails.
Also, it's not clear from the paragraph that if SRV records do not exist,
do you only use the first MX returned or all of them in MX preference
order?
If I may suggest the following change:
When an MTQP client wishes to make use of the message tracking
service, it establishes a TCP connection with the server host. To
find the server host, the MTQP client first does an MX lookup for the
server host using DNS MX records, as specified in [RFC-DNS] and
revised by [RFC-HOSTS]. If no MX records are found, the MTQP client
then does an A record lookup for the server host. If MX records are
found, for each MX record (in MX preference order -- lowest to
highest), an SRV lookup on the MX host name using DNS SRV records,
with a service name of "mtqp". (See the "Usage rules" section in
[RFC-SRV] for details.) If a SRV host is found, the MTQP client uses
that host for tracking. Otherwise, it uses the MX host name for
tracking. Finally, the host either the SRV host (if found) or the MX
host is contacted using MTQP. This process is repeated for each of
the MX records until an MTQP lookup succeeds (i.e., tracking status is
returned).
With this new text, the DNS records might look something like:
gshapiro.net IN MX 10 smtp.gshapiro.net
IN MX 20 smtp.sendmail.com
smtp.gshapiro.net IN A 10.254.153.10
smtp.sendmail.com IN A 192.168.10.43
IN SRV mtqp tracking.sendmail.com
tracking.sendmail.com IN A 192.168.10.45
In which case, a message sent to gshapiro@xxxxxxxxxxxx would be tracked by
first contacting smtp.gshapiro.net with MTQP and if no tracking information
is available at that host (or it can not be contacted), then continue by
contacting tracking.sendmail.com with MTQP.
An example, such as the one I have given should be added to the draft.
---
3. Initialization and Option Response
Example 5 should probably use "VND." as Option2 and Option3 are not valid
(only STARTTLS is). A suggested replacement:
Example #5 (options available):
S: +OK+/MTQP MTQP server ready
S: starttls
S: Vnd.vendor.Option2 with parameters
S: Vnd.vendor.Option3 with a very long
S: list of parameters
S: .
---
10. IANA Considerations
Vendor-specific options MUST be registered with IANA? I thought the whole
point of vendor options was like that of 'X' ESMTP extensions:
RFC 2821 Simple Mail Transfer Protocol April 2001
2.2.2 Definition and Registration of Extensions
In addition, any EHLO keyword value starting with an upper or lower
case "X" refers to a local SMTP service extension used exclusively
through bilateral agreement. Keywords beginning with "X" MUST NOT be
used in a registered service extension. Conversely, keyword values
presented in the EHLO response that do not begin with "X" MUST
correspond to a standard, standards-track, or IESG-approved
experimental SMTP service extension registered with IANA. A
conforming server MUST NOT offer non-"X"-prefixed keyword values that
are not described in a registered extension.
If that is the case, then they should not be registered with IANA. Perhaps
we want to steal some of the above text for this document.
---
12. Protocol Syntax
Move opt-text up as it is used by comment-command first (before
temp-response).
The response-info ABNF is incorrect. The parens are not balanced.
---
Spelling fixes:
@@ -197 +197 @@
-parseable, case-insensitive response information giving more data about
+parsable, case-insensitive response information giving more data about
@@ -249 +249 @@
-Which option is picked is an adminstrative decision and is not further
+Which option is picked is an administrative decision and is not further
@@ -667 +667 @@
- System port number XXXX - TBA by IANA
+ System port number XXXX - TBD by IANA
@@ -693 +693 @@
-begin with "vnd." MUST be registered with IANA on a Firt Come First
+begin with "vnd." MUST be registered with IANA on a First Come First
@@ -721 +721 @@
- Both the STMP client and server must check the result of the TLS
+ Both the SMTP client and server must check the result of the TLS
@@ -725 +725 @@
-was achieved is made locally, is implementation-dependant, and is beyond
+was achieved is made locally, is implementation-dependent, and is beyond
@@ -825 +825 @@
-13. Acknowledgements
+13. Acknowledgments
@@ -925 +925 @@
-assist in its implmentation may be prepared, copied, published and dis-
+assist in its implementation may be prepared, copied, published and dis-
@@ -930 +930 @@
-references to the Internet Society or other Internet organisations,
+references to the Internet Society or other Internet organizations,
--- End Message ---
--- Begin Message ---
See comments below.
Tony
Gregory Neil Shapiro wrote:
>
> 2. Basic Operation
>
> The second paragraph describes how to determine tracking host to contact.
> How about a host like this:
>
> gshapiro.net IN SRV mtqp tracking.gshapiro.net
> IN MX 10 smtp.gshapiro.net
> IN MX 20 smtp.sendmail.com
>
> In other words, a dedicated tracking server for gshapiro.net and two MX
> records. When an SMTP message is sent, smtp.gshapiro.net happens to be
> unavailable so the message goes to smtp.sendmail.com. If an MTQP client
> then tries to track the message, it will use tracking.gshapiro.net (due to
> the SRV record). However, tracking.gshapiro.net doesn't know about the
> message yet (still in smtp.sendmail.com's queue). The lookup fails.
>
> Also, it's not clear from the paragraph that if SRV records do not exist,
> do you only use the first MX returned or all of them in MX preference
> order?
>
> If I may suggest the following change:
>
> When an MTQP client wishes to make use of the message tracking
> service, it establishes a TCP connection with the server host. To
> find the server host, the MTQP client first does an MX lookup for the
> server host using DNS MX records, as specified in [RFC-DNS] and
> revised by [RFC-HOSTS]. If no MX records are found, the MTQP client
> then does an A record lookup for the server host. If MX records are
> found, for each MX record (in MX preference order -- lowest to
> highest), an SRV lookup on the MX host name using DNS SRV records,
> with a service name of "mtqp". (See the "Usage rules" section in
> [RFC-SRV] for details.) If a SRV host is found, the MTQP client uses
> that host for tracking. Otherwise, it uses the MX host name for
> tracking. Finally, the host either the SRV host (if found) or the MX
> host is contacted using MTQP. This process is repeated for each of
> the MX records until an MTQP lookup succeeds (i.e., tracking status is
> returned).
>
> With this new text, the DNS records might look something like:
>
> gshapiro.net IN MX 10 smtp.gshapiro.net
> IN MX 20 smtp.sendmail.com
>
> smtp.gshapiro.net IN A 10.254.153.10
>
> smtp.sendmail.com IN A 192.168.10.43
> IN SRV mtqp tracking.sendmail.com
>
> tracking.sendmail.com IN A 192.168.10.45
>
> In which case, a message sent to gshapiro@xxxxxxxxxxxx would be tracked by
> first contacting smtp.gshapiro.net with MTQP and if no tracking information
> is available at that host (or it can not be contacted), then continue by
> contacting tracking.sendmail.com with MTQP.
>
> An example, such as the one I have given should be added to the draft.
I don't know how common this usage of MX records is, but it is valid.
I'm okay with this change. Anyone else?
> ---
>
> 3. Initialization and Option Response
>
> Example 5 should probably use "VND." as Option2 and Option3 are not valid
> (only STARTTLS is). A suggested replacement:
>
> Example #5 (options available):
> S: +OK+/MTQP MTQP server ready
> S: starttls
> S: Vnd.vendor.Option2 with parameters
> S: Vnd.vendor.Option3 with a very long
> S: list of parameters
> S: .
sure
> ---
>
> 10. IANA Considerations
>
> Vendor-specific options MUST be registered with IANA? I thought the whole
> point of vendor options was like that of 'X' ESMTP extensions:
>
> RFC 2821 Simple Mail Transfer Protocol April 2001
> 2.2.2 Definition and Registration of Extensions
>
> In addition, any EHLO keyword value starting with an upper or lower
> case "X" refers to a local SMTP service extension used exclusively
> through bilateral agreement. Keywords beginning with "X" MUST NOT be
> used in a registered service extension. Conversely, keyword values
> presented in the EHLO response that do not begin with "X" MUST
> correspond to a standard, standards-track, or IESG-approved
> experimental SMTP service extension registered with IANA. A
> conforming server MUST NOT offer non-"X"-prefixed keyword values that
> are not described in a registered extension.
>
> If that is the case, then they should not be registered with IANA. Perhaps
> we want to steal some of the above text for this document.
I meant to say that the vendor name must be registered, as is done with
MIME content types.
Another option is to go the java route and use a reversed domain name:
vnd.com.example.option1
This avoids the IANA registration issue entirely, under the assumption
that only the owners of a domain would use their domain.
> ---
>
> 12. Protocol Syntax
>
> Move opt-text up as it is used by comment-command first (before
> temp-response).
>
> The response-info ABNF is incorrect. The parens are not balanced.
ok
> ---
>
> Spelling fixes:
>
> @@ -197 +197 @@
> -parseable, case-insensitive response information giving more data about
> +parsable, case-insensitive response information giving more data about
> @@ -249 +249 @@
> -Which option is picked is an adminstrative decision and is not further
> +Which option is picked is an administrative decision and is not further
> @@ -667 +667 @@
> - System port number XXXX - TBA by IANA
> + System port number XXXX - TBD by IANA
> @@ -693 +693 @@
> -begin with "vnd." MUST be registered with IANA on a Firt Come First
> +begin with "vnd." MUST be registered with IANA on a First Come First
> @@ -721 +721 @@
> - Both the STMP client and server must check the result of the TLS
> + Both the SMTP client and server must check the result of the TLS
> @@ -725 +725 @@
> -was achieved is made locally, is implementation-dependant, and is beyond
> +was achieved is made locally, is implementation-dependent, and is beyond
> @@ -825 +825 @@
> -13. Acknowledgements
> +13. Acknowledgments
> @@ -925 +925 @@
> -assist in its implmentation may be prepared, copied, published and dis-
> +assist in its implementation may be prepared, copied, published and dis-
> @@ -930 +930 @@
> -references to the Internet Society or other Internet organisations,
> +references to the Internet Society or other Internet organizations,
ok
--- End Message ---
--- Begin Message ---
Folks,
I am coming very late to this working group, and I know how annoying it
can be when someone piles in late with a zillion comments, so please
ignore me if you feel I am out of line.
I should also point out that I'm on record as not being very
enthusiastic about any of the message tracking mechanisms, so these
comments come from the point of view of a sceptic. (And as the author of
Exim, I can see that at least one feature of the msgtrk system is close
to "impossible" to implement.)
Below are comments on draft-ietf-msgtrk-smtpext-03 [SMTPEXT],
draft-ietf-msgtrk-trkstat-03 [TRKSTAT], and draft-ietf-msgtrk-mtqp-03
[MTQP].
Regards,
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@xxxxxxxxxxxxx Cambridge, England. Phone: +44 1223 334714.
---------------------------------------------------------------------
Comments on [SMTPEXT]
Section 3, paragraph labelled (4):
(a) This paragraph talks about the "MAIL FROM command". In fact, all
other RFCs about SMTP call it the "MAIL command". This change is
needed throughout the document.
(b) The second sentence reads "In addition, the ENVID and ORCPT
parameters (as defined in RFC 1891 sections 5.4 and 5.2
respectively) MUST be supported, with extensions as described
below." This implies that both these parameters are for the MAIL
command, but ORCPT is actually a parameter of the RCPT command.
Also, I can't see any extensions for the ORCPT command in the rest
of the document. Suggested rewording:
In addition, the ENVID parameter of the MAIL command (as defined
in RFC 1891 section 5.4) MUST be supported, with extensions as
described below. The ORCPT parameter of the RCPT command (as
defined in RFC 1891 section 5.2) MUST also be supported.
Section 3, paragraph labelled (5):
This paragraph is talking about the length of the MAIL command, and
says "Note that a further extension of 614 characters for the OCRPT
and ENVID parameters is required..." This can't be right, because
ORCPT is not a parameter of MAIL.
Section 4.1:
The first sentence reads "Any sender wishing to track a message
must...". I think it would be clearer to say "Any sender wishing to
request the retention of data for subsequent tracking of a message
must...".
A few paragraphs down there is "B is stored in tracking databases of
compliant MTAs..." I suggest a change to "compliant receiver MTAs" to
contrast with the start of the paragraph, which covers the sender.
Section 4.2:
The last paragraph reads:
Any resubmissions of this message into the message trans-
mission system MUST assign a new ENVID. In this context,
"resubmission" includes forwarding or resending a message from a
user agent, but does not include MTA-level aliasing or forward-
ing where the message does not leave and re-enter the message
transmission system.
What does this mean in the context of an MTA aliasing that turns one
incoming address into two outgoing addresses, causing two different
copies of the message to be sent to two different MTAs? Does each copy
retain the ENVID? (This is probably answered by the following section,
but perhaps some words here might help the reader the first time
through, and emphasize the point about one-to-one redirection.)
Section 4.3:
The second and third paragraphs had me somewhat confused. I *think* I
now know what is meant, but I may be wrong.
If aliasing, forwarding, or other redirection of messages
to a single recipient occurs, then the MTA SHOULD treat this as
an ordinary hop-to-hop transfer and forward the MTRK=, ENVID=,
and ORCPT= values; these values MUST NOT be modified.
"redirection of messages to a single recipient" can be read in one of
two ways:
(a) A single envelope recipient (possibly one among many) is
redirected to a new single recipient, and that copy of the message
is what we are talking about.
OR
(b) A message contains only a single (incoming) envelope
recipient, and this paragraph covers just that case.
I think it must be (a) that is intended. Is this wording better?
If aliasing, forwarding, or other redirection of a recipient
occurs, and the result of the redirection is exactly one new
recipient, the MTA SHOULD treat this as...
[This begs the question of the very common case where somebody who is
temporarily somewhere else sets up a .forward file that saves messages
in their local mailbox, and also forwards them to a single forwarding
address. Does this count as "one-to-one" redirection, or not? I
suppose it has to be not.]
The next paragraph reads thus:
MTAs MUST NOT copy MTRK certifiers when relaying a message
to multiple recipients. An MTA MAY designate one recipient in a
multi-recipient alias as the "primary" recipient to which track-
ing requests shall be forwarded; other addresses SHALL NOT
receive tracking certifiers. MTAs MUST NOT forward MTRK certi-
fiers when doing mailing list expansion.
Does "relaying a message to multiple recipients" mean that the message
envelope contains more than one recipient, and the MTA is passing it
on, or does it mean that a single envelope recipient is expanded to
more than one address, and these are passed on? I think the latter is
intended, in which case perhaps some wording that mirrors the previous
paragraph might be clearer:
MTAs MUST NOT copy MTRK certifiers when a recipient is aliased,
forwarded, or otherwise redirected and the redirection results
in more than one new recipient. However, an MTA MAY designate
one of the new recipients as the "primary" recipient...
[My case of "save in mailbox and forward" mentioned above is probably
an example of where the forward address should be "primary", I
suppose.]
Section 5.2:
(Minor comment.) I felt it might be helpful to add a final paragraph
along these lines:
Therefore, implementors are encouraged to provide mechanisms by
which site administrators can choose between these alternatives.
Section 6:
[RFC_SMTP] should refer to 2821, not 821
---------------------------------------------------------------------
Comments on [TRKSTAT]
References to RFC 822 should refer to 2822 instead.
Section 3.3.2 REQUIRES the final-recipient field. I know that many
administrators do not want to expose the results of redirection or other
address rewriting. I suspect, therefore, that this field will be of very
little use in practice.
Section 3.3.5 (Remote-MTA field):
What if several MTAs have been tried, and the message is delayed because
all are unreachable? Should this field be omitted, or should one MTA be
chosen at random?
Section 3.3.7 (Will-Retry-Until field) is hard for at least one MTA
(Exim) to implement (because of the way its retrying is designed). By
making this field REQUIRED, this specification assumes a certain kind of
retry implementation.
---------------------------------------------------------------------
Comments on [MTQP]
I think we fixed this at the mini-BOF, but all references to "A records"
should be to "address records" so as to include AAAA (or A6 if that
refuses to die).
Section 2.4
The last sentence reads "An MTQP server MAY limit the number of
commands or total connection time to prevent denial of service
attacks." It may be worth pointing out that severely limiting the
number of *unrecognized* commands defends against attacks that
are implemented by subverting unsuspecting programs to send data to
arbitrary ports. In such cases, the input usually contains a number
of unrecognized commands. There's a specific new attack of this form
which can be used against SMTP - it's not yet published, I think,
which is why I'm being a bit vague here. The potential for damage is
much greater with SMTP than with MTRK, of course.
Section 7 (QUIT command):
This says "The client may close the session from its end immediately
after issuing this command." This was the subject of some heated
debate somewhere (can't remember exactly where) in the case of SMTP.
The conclusion was, if I recall correctly, that this was a safe thing
to do on a Unix system, because of the way that TCP/IP stacks work in
Unix. On some other systems, it was alleged, doing this would crash
the system, because closing the session wipes out all knowledge of the
call, and the incoming response to QUIT on a now-non-existent
connection, causes trouble. (Unix, of course, keeps the session
hanging around for a bit, in CLOSE_WAIT state.) I have never used
Windows or MacOS (believe it or not), let alone programmed for either
of them, so I don't know the details of this. However, it seems to me
that it might be sensible to put some kind of a warning after that
sentence, such as "on operating systems where this does not cause
problems". The alternative is to remove the sentence altogether.
Section 9:
The word "cookie" appears without any previous definition.
Section 11:
Typo in 4th paragraph: for "dependant" read "dependent".
Section 14:
References to RFCs 821 and 822 should now be to 2821 and 2822.
---------------------------------------------------------------------
--- End Message ---