On Wed, 2004-09-15 at 11:49, Chuck Mead wrote:
Kevin Peuhkurinen wrote:
David Woodhouse wrote:
On Wed, 2004-09-15 at 13:11 -0400, Kevin Peuhkurinen wrote:
To be brutally honest, unless you are an executive or member of our
board of directors or an extremely important customer, I just don't
care that much from a business perspective if you don't get my email.
That's perfectly reasonable. I understand your perspective. But that is
not an acceptable perspective for this working group, which must concern
itself with interoperability of the system as a worldwide whole.
Without meaning disrespect by the precise choice of words in my
paraphrasing of your sentiment -- it is not acceptable for this working
group to codify a scheme whereby everyone can retreat into a corner and
say "I don't care if you don't get my mail, and I don't care that I
don't get yours".
Agreed, but I also don't think it acceptable to say that nobody is
allowed to make that choice either. A RECOMMENDED wording, in my mind,
would be much more fitting.
If you were to use a MUST NOT, what sort of limitation on it would you
propose? "Implementors MUST NOT use '-all' until the IETF has
determined that 80% of all forwarders are compatible with the
specification"? How would you make that determination?
Exactly... and since many domains could safely use -all right now how
would saying "MUST NOT" advance the use of the protocol towards an
eventual "flag day"? I expect that answer would be short. It won't.
For this reason I respectfully encourage the group to not choose the
wording "MUST NOT" and "MAY NOT" with respect to implementation of -all.
There has to be another way to make it clear that this *could* cause
problems for domains choosing it as an option and yet still suggesting
that once those problems are solved -all is suggested!
Review the marid-mpr draft.
http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt
With MPR, not asserting a restrictive list (exclusive source) does not
invite spoofing as a means of usurping a domain's reputation, as would
be a problem with such lists in either Sender-ID or SPF. MPR depends
upon the initial step of using CSV to establish a truly authenticated
MTA name. From this point, it becomes a simple matter of creating a
name list of EHLO names which normally send mail for mailbox.dom. (This
takes advantage of built-in name compression and does not need to double
enter addresses or perform added queries to obtain an address.)
_mp.smtp.mailbox.dom. IN PTR mailbox.dom.
_mp.smtp.mailbox.dom. IN PTR our-access-provider.com.
_mp.smtp.mailbox.dom. IN PTR ads-r-us.com.
This would need a single DNS lookup to obtain the EHLO name list and NO
MTA addresses are required! A message sent from the MTA
EHLO=mx003.bulkmail.ads-r-us.com would be seen as authorized to send
mail for mailbox.dom.
By using the CSV authenticated MTA name for reputation services and
assertions, this does not burden the mailbox domain MTA send control
lists with a danger of being exploited. It also does not require an
indeterminate number of DNS queries to resolve.
MPR however allows big-bank.com to constrain their list of EHLO names
for RFC2822 From: xxxx(_at_)big-bank(_dot_)com to be the exclusive source of
their
mail. The receiving MTA or MUA could use this information to either
"color" the mail, or in the case of the exclusivity assertion, then
these agents may even reject the message. I would expect this rejection
behavior would need to a user based option.
This reintroduces protection once only somewhat available with Sender-ID
and the PRA algorithm. The major different between MPR and the PRA
algorithm is that the field selection is both better authenticated and
better defined. In the case of MPR, the authenticated EHLO should be
visible to the user within the MUA to avoid phishing and spoofing as an
additional precaution in newer MUAs.
(If only Outlook would forward mail without stripping the headers, and
then there would also be a simple means to report spam.)
Instead of using BATV, the EHLO name list could be defined as the
exclusive source for RFC2821 MAIL FROM. I feel BATV remains a better
solution, but offered this to show how the SPF type of operation could
be implemented using this approach.
-Doug