On Tue June 21 2005 17:00, Frank Ellermann wrote: > > Bruce Lilly wrote: > [1.5 MB PDF] > > Heavens to Betsy, a whole floppy disk's worth of space :-). > > Won't impress my nice USR Courier and AcroReader 3.0 - I can't help that. The document comments indicate that it was generated from MS PowerPoint by Windows Acrobat Distiller in 1.3 (Acrobat 4.x) PDF format. > > It is unclear what you're referring to; specific > > sections of RFC 1958 were referenced. > > This "incompatible with the Internet architecture", > your death sentence. You could as well quote KISS > (3.5), the principle of constant change (1), build > on the work of others (3.2), running code (3.14), > or don't wait for perfect solutions (3.7). In some > way or another all relevant for hutzler-spamops-04. Perhaps. You're welcome to comment on issues that you think are important. I picked the end-to-end issue (as reaffirmed by RFCs 3426 and 3439), security issues, and consistency and clarity of terminology. There may well be other issues; due to the ambiguity and vagueness (in part due to lack of clear and consistent terminology) it's not currently possible to tell from the draft as written. > > security multiparts (not referenced by RFC number, > > which is 1847 > > You never stop to amaze me with RfC numbers I have > never before heard of... oh, that stuff, okay, now > where's that related to MSA and MDA considerations ? It's related to the concept of authentication/authorization and the end-to-end principle. It seems rather silly for some random MTA to decide whether or not some human sender or machine is allowed to send a message to me claiming to be from some author. If the existing mechanisms which are capable of providing true end-to-end authentication are used, there is absolutely no reason for some intermediate MTA to try to play nanny. > Okay, I'd interpret it as the address identifying the > mailbox in the forward path. [...] > So "RCPT-TO address" is a forward-path minus route, The point is that if the perfectly fine terminology used in the primary reference is used in the draft itself, there is no need for interpretation (i.e. "guessing"). > > other mail system components cannot determine whether > > or not delivery is "final" > > Then they have to assume that it is, and if something > beyond their control has its own ideas it's responsible > to get it right, e.g. a mailing list. > > > See above and RFC 3028 (esp. sect. 4.3). > > MUA-stuff, a MUA claiming to be no MUA is still a MUA. No, RFC 3028 is Sieve, which "is not tied to any particular operating system or mail architecture"; it can be run in an MUA, but can also be run elsewhere. See the RFC 3028 Abstract and Introduction. > > think about the word "gateway" for a moment or two. > > Yes, MUAs claiming to be a gateway are often a PITA. No, nothing to do with MUAs. An MTA acting as a gateway might indeed make final *SMTP* delivery, but not final delivery; moreover a subsequent gateway may reintroduce the message into SMTP. In other cases, the MTA may be unable to determine whether delivery is to a message store or to a temporary spooling area for subsequent gateway processing. In particular, your interpretation about "reject instead of accept and later bounce" is inapplicable in the case of many gateways; the gateway has no way to determine validity of the recipient mailbox equivalent -- if it turns out to be invalid, a "bounce" may well be the only way to provide an indication to the originator. [in more general terms, that interpretation means little if multiple "hops" of store-and-forward (SMTP) is used; if one late hop results in a permanent error reply code (or a timeout, etc.) the intermediate MTA that accepted and stored the message before attempting to send to the MTA or MDA that might be able to reject the message still needs to send a "bounce", as that is specifically required by RFC 2821 sections 2.1, 3.3, 3.7, 4.1.1.4, 4.2.5, 6.1.] > > So is it a person, a piece of software, a host, an IP > > address, or what? > > It's something with an IP connecting to port 25 or 587 > saying HELO or EHLO. And if that's you using telnet > it's perfectly okay. But it's still not clear what it is that is supposed to be authenticated. > >> Yes, it's simply the 2476(bis) 4.3 MUST, see above. > > Where's the justification for an imperative? > > In section 4.3 of 2476(bis), without authentication it > would be an open relay and no MSA. The draft still lacks a justification corresponding to BCP 14 "actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability". > > No. No matter what > > Now wait, my next statement belonged to this part: > > | If it's coupled with 2476(bis) "enforced submission rights". > > > there is an open window that an attacker can exploit. > > He had to get the "enabled" IP and had to know the MAIL FROM. Yes -- see the "evil twin" discussions on the IETF discussion list related to the draft under discussion. > [rfc2223bis-08.txt] > > "Active" and "IESG Evaluation" according to the official > > Internet-Drafts Database. Your source? > > A local copy of the draft, line 11: "Expires: February 2005". Expiration date can be extended (w/o changing the draft text) by request of the author or IESG. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf