Subject: RE: So ... did Dewey beat Truman?

From: "John Glube" <[email-masked]>
Date: Thu, 5 Aug 2004 12:18:26 -0400

The marid protocol should be set up so that the sender
writes a sender policy record which allows the receiver
under marid core to use this record to verify any one or
more of the data sets the receiver wants to check.

Let me explain.

Want to do an SMTP mail from check? Okay. 

Want to do an EHELO check? Great

Want to do an SMTP sender from check? Sure

Want to do any combination of SMTP mail from, EHELO and
SMTP sender from checks? Fine. 

Want to do any combination of SMTP mail from, EHELO, SMTP
Sender from and PRA checks. Hey, that's fine too.

(This is the AOL choice.)

PRA is moved to its own spot to give MS the option, feel
you need a defensive patent and royalty free license. Hey,
go for it. 

It may be that checking using SPF and Submitter is
sufficient. It may be that using CSV suffices. 

However, we should only say to receivers you must run
checks. Which checks you run is up to you.

In turn this lets the market decide which checks are
optimal and deliver the best results. 

If a service provider like AOL feels the optimal solution
is to check everything, hey ... go for it.

As to a public-key cryptography solution relying on DNS, on
the sender side, one would need to:

* amend the marid protocol to add the requirement to
publish a public-key;

* amend core to allow receivers to choose to check the
public key.

I would suggest it is too early to dictate this to senders.

Let me repeat so there is no misunderstanding:

* The sender under marid protocol publishes a sender
policy. 

To be acceptable, this sender policy must allow the
receiver to run any one or more of a series of tests based
on SMTP mail from, ehelo, SMTP sender from and PRA.

At some point in the future we will add a form of
public-key cryptographic test. 

* The receiver under marid core can elect what 'data sets'
she wants to check using the sender policy published for
the domain under the marid protocol. 

From the sender's perspective, he says to the receiver:

"Want to check SMTP mail from, ehelo, SMTP sender from, PRA
... go ahead. Its all there and everything is in order."

The receiver can say, for example thanks, but I only need
to check the ehelo using the CSV protocol. All the rest of
these checks are redundant. 

I am satisfied the data set from ehelo, along with the use
of reputation and accreditation services and ultimately a
light weight version of public key cryptography will
suffice.

Marid core should not tell a receiver you must check
everything, only that you may check one or more of the
following:

SMTP mail from 

The protocol for using SMTP mail from is found in SPF
(needs to be updated).

SMTP sender from 

The protocol for using SMTP sender from is found in
Submitter?

EHELO

The protocol for using EHELO is found in CSV.

PRA

The protocol for using PRA is found in PRA. 

(At some future point in time, a public key cryptography
solution or some other variant which we have yet to think
about.)

In this way, it allows proponents of particular solutions
to provide the receiving market with a choice. This market
can then decide which solution it wishes to use based on
what best suits the needs of the receiver. 

Write the rules so you dictate what information senders
must provide. 

Don't write the rules to dictate a solution for receivers.

Allow the rules to be flexible to let proponents fashion a
solution within the established framework which best suits
the needs of the specific receiver or class of receivers. 

So, if AOL feels, we want to check everything, then it will
look for a solution provider which allows it to check
everything.

At the same time if XYZ says, we don't need all this backup
checking and will only check this particular data set using
this approach, then presuming there is a solution provider,
that's up to XYZ.

:-) 

John

John Glube
Toronto, Canada
 
The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004

---

From: "Guillaume Filion" <[email-masked]>
Date: Thu, 5 Aug 2004 14:06:56 -0400

> more of the data sets the receiver wants to check.

It makes a lot of sense to me; and I'm pretty sure that it's what's going to
happen whatever the RFC says. It's better to design the protocol with this
in mind than complaining later that people are implementing only a part of
the RFC.

My 2 cents,
GFK's
-- 
Guillaume Filion, ing. jr
Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/
PGP Key and more: http://guillaume.filion.org/

---

From: "John Glube" <[email-masked]>
Date: Thu, 5 Aug 2004 17:44:44 -0400

Guillaume,

Here is the problem and its classic. 

We don't know whether it is possible for people to write a
sender policy which will work for everything. 

Even if it is possible, with all the chances for mistakes
in setting it up and as we have never done anything like
this on the Internet before on this scale, is it better to
go with something simple?

And what about less developed countries who are simply
struggling to get online. Are we going to simply say tough?

So, does this mean we back away from making it a must on
the sender side and rather have it as a recommendation?

Prudent senders will take the time and effort to properly
configure their systems so that recipient's can run any
check they want.

Or will they? Unless it is mandatory, why do it?

On the receiving side, we have protocols which allow for
checks based on different aspects of the message header.

Which checks will be used will depend on a provider's
particular needs. 

A big ISP like AOL may need to use SPF, Sender-ID,
Submitter, CSV and DomainKeys given how everyone uses their
system. 

A small home based web hosting service or ISP may only need
to use SPF or CSV. 

Why do it? Because, it is the most cost efficient way of
dealing with the problem of spoofing and phishing, or
because a large enough group of service providers say if
you want to send email to us, you must? Be a prudent sender.

:-)

John

John Glube
Toronto, Canada

---

---

From: "John Glube" <[email-masked]>
Date: Thu, 5 Aug 2004 18:24:09 -0400

I am simply forwarding this on to the lists
as it did not seem to get posted.

From: Carl Hutzler [mailto:[email-masked]] 
Sent: August 5, 2004 9:50 AM
To: ""John" "Glube""; IETF-MXCOMP
Cc: [email-masked]
Subject: Re: So ... did Dewey beat Truman?

I see a lot of CSV or SPF or DomainKeys or SenderID, etc.

Why can we not change the "or" into an "and".

From AOL's standpoint, I would like to see SPF AND CSV AND
DomainKeys AND SenderID. The reason is that CSV, SenderID/SPF,
and DomainKeys all provide DIFFERENT information. They do not
conflict with eachother. 

Since they all provide different information, I would like to
have access to all of the data streams when an MTA connects to
me. This way I can make better decisions.

-Carl

On 8/5/04 12:05 AM, "John Glube" <[email-masked]> wrote:

> 
> Oh yes, the famous headline of the Chicago Tribune when
> Dewey was supposed to have beaten President Truman in the
> 1948 Presidential election.
> 
> Why that subject line? Because of this article:
> 
> IETF Prepares to Forward Sender-ID
> http://www.internetnews.com/xSP/article.php/3390221
> 
> The implication from the article, as a result of the author
> interviewing Andy Newton, one of the co-chairs of this WG
> was that Sender-ID had won and CSV had lost.
> 
> The only thing holding things up? According to the article,
> a fight going on within MS whether to insist on a license
> for Sender-ID or not.
> 
> However it seems based on quick notes released by the WG
> chairs, the issue remains open.
> 
> Why do I say this?
> 
> * The core draft protocol (aka Sender-ID) will now be
> divided into two documents, core and PRA.
> 
> * In the meantime, MS has been given until August 23 (the
> same date when last call starts) to file any IPR claims.
> 
> * The group can start discussing CSV.
> 
> And what about CSV?
> 
> It might be helpful if Andy could clarify whether the
> interview in the noted article is accurate, or did the
> reporter mangle his remarks and draw the wrong conclusions.
> 
> Why? Because the article leaves the impression the issue
> has already been decided.
> 
> Instead, with the split of Marid core into two documents,
> core and PRA, the community could enjoy the benefit of
> doing:
> 
> * PRA checks meaning both SENDER FROM and FROM checks as
> per PRA.
> 
> * SENDER FROM, MAIL FROM or EHELO checks all as per core.
> 
> (I appreciate some may balk at this, but bear with me.)
> 
> With the Marid protocol (SPF) being the design used for
> senders to publish DNS records, this allows people to build
> a receiving authentication model around any one of these
> four options depending on their needs, without prejudicing
> senders.
> 
> The benefits:
> 
> * It leaves MS free to claim a defensive patent on PRA and
> require a license should it so decide.
> 
> If MS decides to proceed in this direction, those
> developers who are happy to sign a license can do so. Those
> receivers who want to do full blown PRA checks can do so.
> 
> * It allows the open source community free to develop and
> implement an authentication model around SENDER FROM, MAIL
> FROM and/or EHELO FROM. Those receivers who would prefer to
> focus on the transportation stage for authentication can do
> so. 
> 
> * This approach does not prejudice senders since the record
> published using Marid protocol (SPF) can be used to support
> any authentication chosen by the receiver.
> 
> * It allows the market to decide which approach to use
> based on performance.
> 
> * It allows testing to proceed.
> 
> * It does not prevent ISPs and business networks from
> saying in essence, don't want your mail to be automatically
> rejected, then by such and such a date you must have
> published an SPF record or else we will automatically
> reject. As to whether it is delivered or not, depends on
> our policies.
> 
> * For marketing purposes call the whole thing Sender-ID to
> expedite implementation (presuming this name is available
> and not encumbered).
> 
> One thing. I am not trying to rehash old ground, or usurp
> what was discussed and agreed upon at the WG meeting. If
> the approach suggested is foreclosed by what was discussed
> and agreed upon, so be it.
> 
> John Glube
> Toronto, Canada
> 
> Version: 6.0.729 / Virus Database: 484 - Release Date:
27/07/2004

-- 
Carl Hutzler
Director, AntiSpam Operations
America Online Mail Operations
[email-masked]
703.265.5521 work
703.915.6862 cell

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004

---

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 07 Aug 2004 12:16:28 +0200

> configure their systems so that recipient's can run any

No, with SPF/FROM-HDR they will delete their sender policy.
Users want to use "their" mailbox address in From: headers,
even if it doesn't match the MAIL FROM.

As soon as a mail is deleted after a mismatch they'll complain
to the provider of "their" address.  After the 2nd deletion
they will go to another provider without "restrictive" sender
policy.  And after some complaints from unhappy users AOL or
GMX or ... will delete their sender policy and stop to check
sender policies.

The typical user cannot define his own personal sender policy,
just like a typical user cannot define his own personal REJECT
rules.  Big ISPs won't offer this, it's too expensive and too
complex.
                       Bye, Frank

---

From: Graham Murray <[email-masked]>
Date: Sat, 07 Aug 2004 12:46:37 +0100

> even if it doesn't match the MAIL FROM.

[snip]
> rules.  Big ISPs won't offer this, it's too expensive and too

But will the 'typical' big ISP user want to use a From: address which
is different from the ISP allocated (MAIL FROM) address? If the
customer wants to define his own sender or reject policy or use his
own domain then he always has the option of using a mail hosting
service or moving to a smaller ISP which does offer this.

For larger companies, especially those like financial institutions who
are likely targets of phishing, it would be to their advantage to
ensure that all mail they send out has their domain in all of the MAIL
FROM, EHLO, and From:. The current practice I have seen of well known
companies sending out (legitimate) mailshots (to customers) with a
MAIL FROM and EHLO of somepr-or-marketting-company.com with From:
[email-masked] does not help at all in the fight against
phishing.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 07 Aug 2004 17:36:19 +0200

Graham Murray wrote:

> will the 'typical' big ISP user want to use a From: address
> which is different from the ISP allocated (MAIL FROM)
> address?

If that typical user is me, then yes.  The German market has a
lot of call-by-call ISPs for modem / ISDN users, and depending
on the time and the day of the week I use different ISPs.

Most of these ISPs offer mail services.  And a majority of the
ISPs with mail services allow POP3 access independent of the
IP (i.e. I can get my mail from ISP A even if I'm online using
ISP B).  But ISP A won't allow me to send mail while I'm using
another ISP.

Therefore I use my address at ISP A always as From: address,
but my MAIL FROM depends on the mail provider (ISP A, or a MSA
of a 3rd party, or the smart host of another ISP).

I have no idea how usual or unusual that is, but the default
smart host of the biggest German ISP enforces a From: address
matching the MAIL FROM matching the identified user (RADIUS):
They simply replace From: and MAIL FROM.  Many Usenet users
(not exactly "typical") are very unhappy with this practice.

> he always has the option of using a mail hosting service or
> moving to a smaller ISP which does offer this.

Sure, but these services are generally not "free", i.e. not
included by call-by-call ISP services.  One of the SPF ideas
is that this is a voluntary thing.  Sender-Id would force MSAs
of 3rd parties to implement RfC 2476 8.1 "MAY" even if they're
not interested in Sender-Id, _or_ the users of these MSAs could
upgrade their MUA to do this automatically, _or_ they insert a
Sender: manually, _or_ they don't know what's going on, their
mail is rejected, and they're unhappy with this MARID business,
where they can't use their favourite From: address everywhere.

If the only problem in this case is the missing Sender:, why
not handle the Return-Path as "PRA" (only in this case) ?  The
MUA of the recipient wants to display a verified "PRA", so this
MUA knows the new "PRA" concept, and therefore it could handle
this obvious problem.
                        Bye, Frank