Sorry, no. The relevant MTA is the point of access into the mail
distribution service. That's equivalent to a telephone handset.
Without appologies - NO! WRONG!
The equivalent of a telephone handset is the mail client. Note that
I use that term not 'MUA', the user knows it as Outlook, or Eudora.
The user is not aware of the MTA, any more than they are
aware of the
'exchange' they might hypothetically be on.
[NOTE: Both of the following statements are from the perspective
of the receiving MTA, not the perspective of the relaying MX]
If we assume that an MUA shall not connect directly to a
receiving MTA,
but instead shall always use a relaying MX for outbound mail, then the
MUA+MX is equivalent to the phone, because the identity
("phone number")
is bound to the MX, not the MUA (at least for purposes of
RFC2821 checks
on the receiving MTA).
It's only in cases where the MUA connects directly to the
receiving MTA
that the MUA itself is sufficient to be considered the "phone".
Well as I said, I was using the term mail client because I really
wanted to concentrate on the user experience. Comparing something
the user never sees to a telephone handset seems totaly bogus to
me.
I could live with the MUA+MX analogy you propose, but I still
don't see much value in the analogy. In the telephone world the
end user experience is entirely controlled by the telcos.
What Dave seems to be arguing to preserve is the odd fact that in
the Internet you can do the equivalent of tweaking your own
SS7 switching in wierd and wonderful ways. This and the fact that
there are a billion internet users is meant to be an argument.
What we are doing here is simply defining a method of helping you
to ensure that your mail gets through unmolested by spam filters.
If this proposal is not going to be compatible with a set of use
paterns they should propose an alternative approach in ASRG and
show that the unmet use patterns are important enough to deserve
attention.
I propose the following as a way to get closure on the 821/822
issue:
1) There are two issues that might be addressed by means of a
DNS record that advertises the IP addresses of outgoing
mail servers. Authenticating the party that accepts
accountability for the message and authenticating the
message source.
2) The use of 821 protocol data is desirable for the purposes
of establishing accountability since this information is
available before the message body is transfered.
3) The use of 822 protocol data is essential for the purpose
of verifying the origin of the email sender since this is
the only information the end-user will see.
4) For the purposes of controlling ordinary spam it is sufficient
to determine that there is a party who is willing to be
held accountable for the message. If alice(_at_)example(_dot_)com sends
a message through ISP.example and the reputation of ISP.example
is excellent the message can be accepted as 'unlikely to be
ordinary spam'.
5) Accountability is not sufficient in the case of certain types
of criminal spam that attempt to impersonate another party
such as a bank or other financial intermediary. In these cases
the ability to identify unauthorized messages impersonating the
domain name is highly desirable.
6) There is no reason why a validation procedure that is performed
by the incomming MTA should preclude further and additional
checks at a later stage.
For this reason I believe that the way to end this argument and to move
forward is to simply add a flag to the domain profile record to state
whether rfc822 from should be verified.
In the case of paypal.com, citibank.com, verisign.com, bankamerica.com, etc.
the answer is clearly yes, if a message comes from a source that cannot be
positively verified as genuine then throw the message away, it is most
likely to not merely be spam but a criminal attempt to defraud someone.
In the case of phill(_at_)hallambakersecurity(_dot_)blogspot(_dot_)com the
answer is, clearly
not. It is sufficient for the email origin to be verified as having come
from comcast.net and that comcast are in turn accredited as having a
responsible email forwarding policy.
Phill