--On Saturday, January 24, 2009 15:37 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:
...
Keep in mind that there are things that send SMTP that don't
know their own names, may know there own addresses only in
private address space behind a NAT, and have no way to anchor
SPF information even if they wanted to.
I think the question is whether we want those things to be
able to send to any host but their configured gateways. Since
the split between submitters and relayers, time should be
mature for requiring the latter ones to behave somewhat
decently. Most of them actually do.
And that was exactly why my initial note tried to say "if there
is a sender that can't follow the rules because it doesn't have
enough information, it should be using Submit". I think our
preferences there are the same, and Randy and I didn't do RFCs
2476 and 4409 simply because we wanted to raise our RFC-count.
For better or worse, two operational realities intrude on going
very far in that direction:
(1) Many of those "configured gateways" aren't configured and
implemented to support Submit -- in the sense of either not
supporting 587 or not providing the "if you get trash, either
reject the submission or fix it so that anything you push onto
the public Internet meets the spec and intent of 5321/5322"
functionality that Submit expects.
(2) We should not forget that there are full-service SMTP
clients running on portable machines, small networks, without
unlimited resources, and/or serving small numbers of users.
Forcing all of those servers to be configured to use Giant
Provider gateways to send mail would be... well, a very
significant Internet policy change.
The EHLO name has better be unique for tracing and debugging.
OTOH, it has better be "meaningful" for filtering and
reputation management. Do these two kind of activities somehow
match the scenarios implied by that split?
Not sure. But let me suggest an orthogonal distinction. If one
assumes a sender of moderate competence acting in good
conscience and trying to make things work as well as possible,
the EHLO name, provides useful information for tracking down and
debugging, e.g., mail system failures, especially if it is used
in conjunction with other information that requires the same
assumptions. If one assumes a sender of moderate (or greater)
competence who is a Bad Guy trying to trick a recipient system
that doesn't want his traffic into processing and accepting it,
then domain names, IP addresses, etc., just aren't going to be
good enough. Of course, if one can assume that all Bad Guys are
going to be stupid and lazy, the equation changes.
john