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.