Message Tracking meeting notes

Message Tracking Working Group, IETF 49, Tuesday, 11 December, 2000

Steve opened WG meeting and suggested that it was the last or at most
one before the last meeting

[1]. Administration:

Steve: Some MTAs kill DSN (on Firewalls)
Steve: No comments on model document in the mailing list, except for one
private comment to Steve about previous SNMP work.

[2]. Message Tracking Query Protocol:

Open Issues:
How to locate MTQP for a mail system:
  a). Initial Query
Tony : use MX, if no MX ==> use A
Steve: We use mail, so we are fine with MX (otherwise we should use SRV)

Eric: If somebody wants MTQP on a different machine she can use
referrals.
Ned: What if (MTA?) server is down?
Lyndon: Plus MX changing from time to time (load balancing)
Steve/Ned: We can use submission record (or query MUA agent)

Question arisen whether any MUAs uses MX directly. Answer: Spammers :-).

Each hop will return the IP address/host name of the next hop.

Consensus: don't document bootstrap process: either local configuration
(submission record or static option) or MX will be used. This is up to
implementation and thus outside of the scope of the docuement.


 b). Initial referrals (term different from model document)

Some confusion about terminology. Two types of referrals: sidestep
("I do not maintain the tracking information for this host
on this host. Query this other host for my tracking information."), 
next hop ("I delivered message to the following hop").

Ned: Can we use SRV records for sidestep referrals to eliminate
referrals from the protocol?
Steve: How good is SRV deployment.
Ned: Last BIND contains SRV for several years. We are designing new
protocol, so we can force the use of SRV.

Consensus after some discussions: Initial referrals are not required,
because they are not tied to any particular message.

c). Following the path

Group proposal after discussing "Initial referrals": Use SRV, if fails,
fallback to A records (in the latter case you have to co-locate MTQP and
SMTP)

Randy: what about pool of servers that don't share tracking database?
Larry: Use SRV for SMTP host used by previous hop (previous hop knows
exactly to which server it sent message)

Consensus: Agreement with Larry

***For how long should a message tracking information be kept?

RFC1123 mandates 4-5 days retry period for SMTP.
Tony: suggests to keep information for the period that is twice as long
as SMTP period configured in particular MTA.
Marshal: Having the period twice as long as specified in RFC1123 seems
like a good idea.
Ned: this is really a resource allocation issue on a server that keeps
log.

Consensus: Must define a minimum: SHOULD be 10 days, MUST be at least 1
day.

***What TCP port to use?

Just ask IANA. IANA probably will not give us port we want anyway
(submission protocol case was given as an example).
We want to use a reserved port (i.e. <1024)

***Is the error code specification okay?

Chris: send -BAD when client request STARTTLS when TLS in progress
Alexey: Correct ABNF, missing response codes
Alexey: Chris published the draft about response code theory, can it be
used?

***Is security section sufficient?
No feedback now, but there were a consensus that a lot of people must
review the document.


***Interop event?
Tony: If working group shuts down, we should have something.
Mailconnect in March - maybe too early.

Consensus: Too early to talk about.

===================
Questions from the group:

***Chris: IDN consideration.
Reject 8BIT? use UTF-8?
Ned: Too early to address, must wait for IDN group.
Steve: Side comment: DSN spec must be updated to use UTF-8?



***Chris: Text in error responses: can enumerate all cases, so we don't
have to localize human readable text.
Randy: "text in error response is not intended to be presented to the
end user"

***Chris: Imagine a server that hosts multiple virtual domains using the
same IP.
Now if we use TLS we have to specify a certificate the server should
use.

Possible solutions:
a). STARTTLS <domain>
  or
b). Add DOMAIN <domain> command

Another example when client should specify domain:
unqualified usernames in [initial submission] SMTP (probably doesn't
apply to our case anyway)

Consensus: Not required for this protocol, because certificate for
STARTTLS should match SRV record for the MTQP host.

[3]. Message Tracking SMTP Extension:

Overloading ENVID with MTRK extension: MUST be unique, MUST have the
form unique@fqdn
B=H(A), A - one time random number

Chris: Concern about security ("A" used to be hash in the model
document).
Ned: Reference RFC for generating random numbers.
Randy: lifetime for message tracking is short enough, so randomness of
"A" is not that important.

[4]. Message Tracking Status Notification (MTSN) Syntax:
Syntax based on DSN/MDN

Per-message fields:

Original-Envelope-Id (required)
Reporting-MTA (required)
ArrivalDate (changed to required?)

Per-recipient fields:

Original-Recipient - optional as in DSN
Final-Recipient - required
Action - required
Status - required (add "X.1.9 Message relayed to non-complaint mailer")

  Steve: Can we extend list of enchanced status codes in our documents?
  Ned: Why not.
  Eric: What about status codes collision?
  Greg: Other groups (VPIM) want to add other status codes, thus next
revision can incorporate all changes

Remote-MTA - optional (use for referrals using SRV records)
 Required if message has been passed on

Steve: make Original-Recipient required. It is probably the most
important piece of information.
Greg: We can do that, because we have all required information from the
SMTP extension.

Last-Attempt-Date (optional)
Will-Retry-Until (optional)

***7 bit versa 8 bit? -
Dave Crocker: It is good that we steal from DSN, so deficiencies or
solutions for the same problem will be at least consistent.

***Why we invent new MIME type and can't use multipart/report?
Answer: don't have the part that contains message/headers and can't
construct human readable part (because we already sent message to the
next hop and don't have it anymore).

***Steve: How to do aggregation (for example chaining at firewalls),
i.e. when the server returns multiple tracking reports?

Lyndon: multipart/related with multiple reports inside
Steve: I wish we can use XML :-)
Eric: Can mandate every response to be multipart/report with 1 or more
parts? Lazy programmers probably will not generate multipart/related in
case of single part.

Consensus: Agreement with Lyndon and Eric.

***Ned: If you implement MT..., do you have to implement DSN?
Consensus: server MUST implement DSN

[5]. Steve closed the meeting:
Model document: will be informational RFC.
Other docs: One revision in January, last call by the end of February
2001, before Minneapolis IETF.