[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: working group last call on ISP draft



...

Tom Killalea> Randall's recommendations for separating the submission and
Tom Killalea> relaying functions of SMTP by having them listen on different
Tom Killalea> ports are valid independent of SMTP AUTH.  SMTP AUTH is Tom
Tom Killalea> Killalea>_desirable on both ports, or on port 25 if that's the
Tom Killalea> only port to which a site listens.  I'm not clear on how far
Tom Killalea> you think he should go in 'incorporating' the AUTH SMTP Tom
Tom Killalea> Killalea>_extension, as I see them as very different works Tom
Tom Killalea> Killalea>_addressing different issues.

...

Randall Gellens> Without the submission port, all SMTP traffic goes through
Randall Gellens> port 25. That can make it difficult to deploy Randall
Randall Gellens> Gellens>_authentication, since you would need cooperation
Randall Gellens> (and authentication entries) for each server, or you would
Randall Gellens> need software which only required authentication if the
Randall Gellens> message appeared to be a submission.

...

Hmmm, another way of looking at the SMTP AUTH extension is that it can also
be used as a mechanism of determining which messages are submissions and not
relays. If the SMTP session uses authentication, it can be assumed to be a
submission. However, I hadn't considered server-to-server authentication
much; that may be the fly in the ointment for my previous comments.

Nonetheless, I'd like to see AUTH SMTP recommended for all submissions,
irrespective of whether the SUBMIT port is being used, or whether port 25 is
being used.

On a related note, I reread Randall's draft on the SUBMIT port and disagree
with section 5.3.1, which says that the MSA must look at what is in the
header found in the DATA, and then make certain corrections. I think this
would be sufficient grounds for many vendors to refuse to switch to the
SUBMIT port. Which could be a problem with getting the GRIP recommendation
to fly.

					Tony Hansen
			      tony@att.com, tony@attmail.com