ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
> I'm afraid I don't have a choice. The requirements you appear to be advocating
> are unjustified and unworkable in practice. If you're thinking about proposing
> a language change saying that all systems engaged in SMTP client activities
> MUST or even SHOULD also have an acessible server to accept problem reports,
> that's simply not going to happen.
>
> Ned
The point is well stated, but this doesn't jive with the requirement
that MAIL FROM must be a valid acceptable address.
I don't see a conflict. We're talking about the host the SMTP client runs on,
whose "name" could be determined either from the EHLO/HELO argument, PTR lookup
of the IP address, synthesized as a daomin literal of the IP address, etc. This
is entirely separate from the MAIL FROM address, and nothing says that the MAIL
FROM address has to have anything to do with the host name of the SMTP client.
(Hopefully we've left all the "append your host as a source route onto the
return path stuff behind some time back.) Indeed, any SMTP client that
unconditionally stuffs its own host name in there is violating a different set
of requirements if the resulting address doesn't work.
In others words, in an anonymous transaction (not authenticated, no info
nor history on the domain), the receiver has no real substantiated clue
that the client has no INBOUND mail box for notifications or feedback.
Correct. But that feedback isn't supposed to be directed at the preceeding
host. It's supposed to go to the MAIL FROM address. Of course if the MAIL FROM
is broken or forged or whatever that presents a problem, but this is
independent of whether or not there's an SMTP server on the preceeding host you
can send postmaster mail to.
I think one of the things Frank is after is a way to report problems either
when it is clear it's an issue with the host the SMTP client is running on or
when the MAIL FROM doesn't work. The problem is that the SMTP architecture
doesn't provide a means for a client to say "report any issues you have with me
to this address". Of course it would be possible to add such a capability, but
even if it made sense to do so (I for one am not convinced) this is not the
time or place for it.
It really has nothing to do with the scale of the system. Small or
large, they are all viewed the same to the outside world.
As well they should be. Quite a lot of effort usually goes into making this
view possible, in many cases including a lot of hackery at the network and DNS
levels.
In my view, it would be really stupid for legitimate systems NOT to have
a valid return path mail box handy and ready to accept feedback
regardless if its read, not read and/or ignored, included always
accepted, relayed or dropped. The address was accepted is the key
point because it s standard requirement the return path be valid.
Again, we're not talking about the MAIL FROM here.
In lieu of this standard return path expectation, this type of behavior
can and is used for automated black listing, e.g., failed bounces are
automatically black listed.
I really don't want to get into the relative merits of MAIL FROM validation
right now - I'm pretty sure there are a bunch of differing but strongly held
opinions in this area.
Ned