Subject: HELO, IPR, A&R means new draft?; scope; Microsoft - (Re: DEPLOY - IP, HELO & touch count. )

From: Matthew Elvey <[email-masked]>
Date: Tue, 14 Sep 2004 14:14:45 -0700

This is a belated-due-to-to-travel follow-up to replies to this post:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03596.html
(Summary: Sender ID fails to be a solution that only requires sysadmin
action; it mandates end-user reconfiguration on a massive scale, because
it doesn't say that HELO checking should/must be done... The Microsoft
IPR are too encumbered...)

The issues I raised in my last post were appropriate during a last 
call:  They were raised earlier, and there were strong indications that 
they would be addressed (e.g. the Unified SPF discussion and 
documents).  Yet they were in fact not addressed by the specs that were 
in last call. 

"=-=-=-=" <-- topic separator

I think John Leslie said that under SenderID, a domain's reputation 
would be looked up by looking up the IPs its SPF2 record lists in an IP 
blacklist.
I think John is confused - that's not what I am expecting.  I'm 
expecting the domain itself to be looked up in a RHSBL.  That's Right 
Hand Side Block List.  (John's idea could prove useful, but I'd be 
surprised if it, e.g., scored well if coded as a SpamAssassin rule and 
evaluated)

=-=-=-=-=

On 8/25/2004 4:32 AM, Carl Hutzler sent forth electrons to convey:

> <Matthew Elvey said:>
>
>> Phrased differently:
>> Sender ID fails to be a solution that only requires sysadmin action; it
>> mandates end-user reconfiguration on a massive scale, because, IIRC, it
>> doesn't say that HELO checking should/must be done. Hence I (of
>> elvey.com) would have to get all my domain's end users to use MSAs that
>> I (as DNS admin of elvey.com) knew about. For fastmail.fm, my email
>> provider, who hosts mail for thousands of domains, they would have to
>> support this for each user of each domain!) If HELO checking is
>> mandatory, they just send HELO fastmail.fm, and ensure that fastmail.fm
>> has a good reputation.
>
>
> This is a VERY interesting approach. I think you are saying, scratch using
> DNS for "listing Domains allowed to be sent by an IP address", and instead
> have the system admin "program" those domains into the MTAs (e.g. a config
> in sendmail). The MTA would HELO the domain they are about to send for, IF
> THE MTA is told they are allowed to send for that domain in the first 
> place
> - otherwise the mail is rejected (and likely much closer to the submission
> MTA/MSA).
>
> This sounds really cool. But I am an engineer and must always ask, what is
> wrong with this and why has it not been thought of before?
>
> Lets see, forwarding cases....might work here with some PRA/Submitter type
> changes. Not a huge problem.

Forwarding case would work GREAT - no PRA/SUBMITTER needed.  Yes, 'The 
MTA would HELO the domain they are about to send for.'  This domain 
wouldn't have to match the MAIL FROM or PRA or SUBMITTER.  It would 
simply need to be a domain that had an appropriate reputation for the 
content.   E.g. if we assume AOL is responsible about ensuring very 
little spam is sent using the servers it authorizes to do HELO aol.com, 
and sends all email through these servers, then there is no forwarding 
to worry about. Helo aol.dom would trigger a reputation check on aol.dom 
as used in HELO, the repuation would be excellent, and no further checks 
would be necessary - the From: domain or PRA could be elvey.dom or 
DomainWithNoSPFrecord.dom.
Here's a sophisticated possible scenario that provides more flexibility: 
AOL might do HELO goodAolPayingCustomer.dom, if the mail is from one, 
and the customer hasn't recently sent a ton of email.  It might use HELO 
aolSuspectCustomer.dom where appropriate, before cutting the customer 
off completely.  AOL wouldn't have to pay to give 
goodAolPayingCustomer.dom a good reputation; it would deserve it.  AOL 
wouldn't have to cut off customers as often - it could limit use in a 
less draconian way.  Helo aolTrialUser.dom and HELO AOLFreeEmailUser.dom 
would make sense, provided AOL provided and used dedicated IPs for such 
mail and created the appropriate DNS records.
Just to clarify: the above is a sophisticated, enhanced solution that 
HELO-based reputations make *possible*.  It will be perfectly OK for an 
MTA (or all of a domain's MTAs) to have one domain that goes in all 
HELO/EHLO commands sent, and this is likely to be the usual case, and 
will work well.

>
> OK so what is wrong with this?

Well, no criticism so far, other than from Jim, which I've addressed 
thoroughly. 

> -Carl
On 8/26/2004 11:12 AM, Jim Lyon accurately summarized and conveyed:

> Matthew Elvey raises two points that I summarize as follows:
>
>> 1. If you don't know what a domain's outward-facing MTAs are,
>> it's really hard to build a SenderID record. (And he estimates
>> that half of his customers are in this boat.)
>
>
> True.
>
>> 2. If instead of SenderID, we'd merely authenticated the HELO name,
>> and built up reputation systems that say whether particular
>> HELO names behave reasonably, these people's lives would be easier.
>
>
> It's true, but it's a whole lot weaker form of authentication.

Please, I've already explained why it is stronger.  If you're going to 
say it's weaker after it's been explained WHY it's stronger, please 
respond to the provided arguments. You need to do this or you drag the 
conversation to the <Yes it is. No it isn't. Yes it IS...> level.  
[edit: it looks like you've had the argument with Doug in this thread.]

> I don't
> care whether a mail server is who he says he is, I care whether he's
> authorized to send the message he's trying to send.

Can we please graduate to more advanced banter than this?  The charter 
says what we care about. (It's adequate, even if the main goal is to 
address spam, including joe-jobs, phishing, etc.) 
The first half of the sentence states that you don't care about the 
server's Identity, and I know that you in fact do; SenderID relies on 
Identity.  I fail to find a logical argument for ignoring HELO.  You 
imply you care about the body of the message, but SenderID doesn't look 
at the body.  (Why are you calling a mail server a 'he'?  It's confusing.)

Jim Lyon later also said:

> Authorization: The SenderID test determines whether the sending MTA is
> authorized to send mail that claims to come from a particular domain.

This is a too-short definition (which you later improved upon); it's 
actually not accurate.  A mail message can claim to be from several 
domains. 

Jim later clarified things:

> The identity being authorized is the
> sending MTA's IP address. The action being authorized is to send a
> message on behalf of the PRA. The organization doing the authorization
> is the domain of the PRA.

PRA, if adopted, will be manipulated by spammers by the insertion of 
forged headers.  (I'm working on an example.)

=-=-=-=-=-=-=

I understand that the last call was considered by the Chairs to be a 
failure only because of the IPR issues.
There are other issues, I believe.
Some other points that inform whether SenderID was ready for RFC status:
I indicated that certain changes that appeared to be imminent would make
SenderID gain my support, but
it turned out that those changes were not made.
E.g. In June, I posted here:
http://www.imc.org/ietf-mxcomp/mail-archive/msg02404.html :

>  "I'm not trying to deep 6 SPF. I'm trying to make it stronger and
>  better by attacking its weaknesses virtually, while they are readily
>  fixable. Note, I recently expressed my support Unified SPF (which
>  incorporates a CSV-like check). BTW, I was surprised that the -01
>  SenderID drafts that came out didn't have any Unified SPF stuff in
>  'em. I interpreted something Meng said to mean that I should expect
>  to see it in a draft soon, so I'm still expecting that."

The cynic in me wonders if this was an effort to derail my plan to
create an I-D that remedied the weaknesses I saw. That was its effect.
-=-=-=-
I have a $50+ spf t-shirt. I'm trying to make MARID's work
successful. OTOH: A principal of my mail provider (fastmail.fm's
Jeremy H) is so unhappy with SPF that he's suggesting configurations
that appear designed to *sabotage* its effectivenness; an IESG
member's criticism is provided as justification:
http://www.emailaddresses.com/forum/showthread.php?threadid=22341&highlight=spf

A comment on the power of reputation: Remember, Unified SPF and its
cousins rely on reputation services.  Such services already exist :
[DNS|RHS][W|B]LS, etc.
If an EHLO domain gets an initial pass, the reputation check could be a
lookup of that domain speficially with respect to its use in EHLO, such
as a DNS lookup of  nonspammers.dom.ehlo.mail-abuse.org.  However, I
suspect this may not be necessary, and a DNS lookup such as
nonspammers.dom.SPF.mail-abuse.org would suffice, and a reputation
service would only need maintain a single reputation per domain with
respect to is use with Unified SPF and cousins.
What do folks think? A reputation service would need maintain how many
reputations per domain with respect to is use with Unified SPF and
cousins?
An add'l reputation that may be useful would be at, say
nonspammers.dom.bounce.SPF.mail-abuse.org.  This reputation might
reflect whether nonspammers.dom's mailservers were properly configured
to refuse mail at smtp time whenever possible, and thus not likely
sources of bogus bounces such as joe-jobs.

Andrew Newton wrote:
 > On Sep 8, 2004, at 12:06 PM, David Woodhouse wrote:
 >> A HELO scope would be useful.
 > That is already being covered by the CSV proposals.

No, not even close.  -protocol with CSV, and -protocol with a HELO scope
would be EXTREMELY different, can't believe you don't see this, Andy!
It's certainly been explained many times, on-list, by many people.  I
see strong confirmation that HELO scope would be useful, and an
appropriate change to make.  I see little reasoned opposition to a A
HELO scope.  Let's add it or hear some reasoned opposition.
-protocol with a HELO scope would have giant advantages over plain
-protocol or -protocol with CSV, which have been detailed on-list, e.g.
by me as reasons to make a HELO check mandatory, and as reasoning for
Unified SPF.  Certainly it has some disadvantages as well, which have
also been detailed on-list.  The only one that made sense to me was that 
it would make it more likely for a domain not to specify a list to be 
used for PRA or MAIL FROM verification.  The disadvantage of that is 
that such a domain would receive more joe-job bounces, though there's an 
argument that there would be fewer as well:  MARID requiring HELO is 
easier to deploy effectively, therefore likely to be deployed faster.  
Also this disadvantage applies to SenderID as well- it allows 
joe-job-type bounces to joe-job victims.  Only SPF+SRS doesn't have this 
disadvantage, and only where the unwanted bounces would be coming from a 
server that had implemented SPF.
Some reasons the market may go with the HELO scope instead of the others
(assuming this leave-it-to-the-market proposal flies) are that it has
the advantages of not using restricted IPR, doesn't break
forwarding/mail-list/backup mx operations, and doesn't require end-user
action to implement.
Also, Accuspam implicitly asked an interesting question - why specify
what the list of servers may be used for?  Here's an answer: It's
generally much easier to specify a list of servers that will
legitimately use a domain (e.g. elvey.com) in HELO than it is to specify
a list of servers that will use that domain in PRA or  2821.MAIL FROM! 
Hence some folks will only want to specify the former. Some folks may
want to specify a smaller set of servers for one versus another.
Accuspam said : "Publishing the approved mail servers is something
everybody can agree to do I think?" but this is more complicated than it
seems at first glance, because the set of approved servers for a given
domain is different depending on what its approved for.

As Meng said, if HELO and SUBMITTER (modified to not use the encumbered
IPR) always override MAIL-FROM, then there is no need for SRS.

In addition to/as part of the security review of SenderID:
 I think it's necessary that a number of MAYs and SHOULD [NOT]s turn
 into SHOULD [NOT]s and MUST [NOT]s.  There is far too much waffling -
 MUST [NOTs] MUST be used whereever there isn't a compelling reason not
 to.  IETF standards demand it.

Also, the way that Accredidation and Reputation services are to be used
is essential.  It belongs in a BCP, which should specify BFP (Best
Future Practice) for how various tests should be interpreted and acted
upon.  SPF claims to address the spam problem (according to text that
was on the spf.pobox.com home page) so the Accredidation and Reputation
services that are a necessary component to this solution must be
specified.  An incomplete spec that lacks these things has no business
aspiring to be an Internet Standard.  How can a spec that is grossly
incomplete be properly reviewed by us or the IESG?  It can't!
E.g. John Leslie is quite confused about how A&R might work, or I am, as 
mentioned above.

Regarding IPR:
I am certain that the Microsoft staff working in this area are smart
enough to be aware of how their license is defective and how it needs to
be fixed. They can all read. As time passes and they continue to fail to
fix it, blame for failure of the IETF to address the spam problem falls
gradually more squarely on Microsoft and its staff's shoulders. (They
got involved in the process, worked patent pending ideas they have
claims on into drafts amid promises of licensing that wouldn't be
problematic, Microsoft threw its weight around, and now the licensing is
not satisfactory.) As they've had ample time to do so and haven't done
so, we need to move on without PRA.

=-=-=-=-=

Subj:Re: problems with patents:  the IDN example from RFC3669

wayne wrote:

 >... the people running this working group.
 >
As I understand it: The members of the working group run the working
group. The chairs have limited authority.  They mostly express their
opinion as to what the rules are, and what consensus has been reached,
and help provide needed infrastructure.  Their opinions are not binding,
AFAIK.

For example, they've expressed an (IMO chilling, incorrect and
inappropriate) opinion that certain comments regarding Microsoft and its
interests were inappropriate.  I explained in my last post why some
(not necessarily all, of course) of such comments ARE appropriate in
this forum, with reference to IETF policy describing what is and is not
appropriate.
They don't get to decide.  (They get to invoke BCP 83 mechanisms, and
the IESG can express binding opinions.)

WRT to the importance of the highly divisive IPR issues, their opinion
doesn't hold much more weight than anyone else's, IMO.

I believe they shoot themselves in the foot by making consensus claims
that aren't accurate, e.g claiming rough consensus has been reached on
something when in fact it hasn't.  I sympathize however; they are trying
to meet deadlines and keep the peace.  It's a tough job.

I'm sorry if the above is felt inflammatory.  I talked to a couple folks 
who felt it needed to be said, and is as toned down as I could make it.

=-=-=-=-

Clarification:

On 8/25/2004 1:55 AM, Stephane Bortzmeyer sent forth electrons to convey:

> On Tue, Aug 24, 2004 at 08:05:52PM -0700,
> Matthew Elvey <[email-masked]> wrote
> a message of 80 lines which said:
>
>> 1)A good fraction (I'd estimate 1/2) of my end users have their MTAs
>> configured to send through several SMTP servers, using different
>> From:'s
>
 > You mean "their MUAs", not "their MTAs"? Because, although I know MUA

>  with source routing (Thunderbird), I do not know how to do it
>  properly with typical Unix MTAs.
>
Yes.

=-=-=-=-=
Sorry these comments weren't more timely.

So, who's for a new draft with two scopes: HELO and MAIL-FROM?

(Wait, how about a third scope: From:?  This would be something 
phishedbank.dom might want to use to indicate that it would rather break 
forwarding than allow its domain to be used in From: without its 
authorization.  Do folks think phishedbanks would actually use such a 
scope?  (I'm reopening a closed can of worms; perhaps given the failed 
last call, it's time to do so.))

---

From: John Leslie <[email-masked]>
Date: Tue, 14 Sep 2004 19:14:15 -0400

> would be looked up by looking up the IPs its SPF2 record lists in an IP 

   More exactly, I said one could build a reputation service this way.
It was _a_ way to build a reputation service; not an _only_ way.

> expecting the domain itself to be looked up in a RHSBL. 

   The question is, how would such a RHSBL be maintained? It seemed to
me that any RHS that scored poorly under that scheme would need to be
on a hair-trigger because it could go from zero to a million spams in
a matter of seconds.

   (I'm not the least bit sure this is a good time to discuss the issue,
but I'd like to minimize confusion about what the issue is...)

--
John Leslie <[email-masked]>

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Sep 2004 16:53:34 -0700

> surprised if it, e.g., scored well if coded as a SpamAssassin rule and 

The obvious reaction to this technique would be to spoof IP addresses of
known good MX servers in these records.  As I said before, the mailbox
domain within SPF and Sender-ID is worthless for reputation checks.  In
this respect, John is right in this case.  The address must be used for
any checks or reputation assessment.

> > wrong with this and why has it not been thought of before?

It has been considered and there is language within CSV that
accommodates this approach. : )

> [edit: it looks like you've had the argument with Doug in this thread.]

I find it difficult to believe people will allow themselves to be harmed
by reputation services that hold them accountable for any MTA authorized
to send their mail.

I can imagine the conversation: (ac=angry party, rs=reputation service)
 
 ap> Why in the h*ll did you put by domain on your rhsbl?

 rs> There are incidents where this mailbox domain was used in spam.

 ap> I never sent this cr*p!

 rs> Ah, but you authorized the MTA that sent it.

 ap> What authorization caused this problem?

 rs> This will require investigating and a fee to resolve.

 ap> Too bad Sender-ID does not identify the authentic sender!
 
> > I don't care whether a mail server is who he says he is, I care
> > whether he's authorized to send the message he's trying to send.

May I add that the marid-mpr draft can safely answer this question
within a single DNS query and not require the potentially hundreds
needed by Sender-ID or SPF.

> > The identity being authorized is the sending MTA's IP address. The
> > action being authorized is to send a message on behalf of the PRA.
> > The organization doing the authorization is the domain of the PRA.
> 

> would be EXTREMELY different, can't believe you don't see this, Andy!

Please consider the need for two steps in this process.  One,
authenticate and validate the authorization of the MTA EHLO name.  Two,
obtain a list of authorized EHLO names referenced by the mailbox domain
being examined.  This list can be either nominal or comprehensive
without the nominal case inviting spoofing.  In which case, CSV remains
"as-is".  MPR records are much simpler and easier to maintain and obtain
than scripts for SPF or Sender-ID.   

I would suggest avoiding sequential TXT scripts needed with either SPF
or Sender-ID as being unworkable.  CSV used in combination with MPR and
BATV provides all the features claimed by either SPF, SRS or Sender-ID
without disrupting email to the same extent.

There is another issue with either SPF or Sender-ID records.  CSV and
MPR are named based solutions that work within the natural scale of DNS
and only require single non-sequential lookups.  SPF or Sender-ID
require either extensive iterative references to record names to obtain
addresses, or the repeating of IP addresses in a script form.  The
maintenance of such a list will be high, or the relative overhead to use
such a list will be high or both.

> IPR) always override MAIL-FROM, then there is no need for SRS.

With a public version of BATV there is no need for SRS either.

> E.g. John Leslie is quite confused about how A&R might work, or I am, as 

Let me clarify.  Neither Sender-ID nor SPF will support RHSBLs.

> last call, it's time to do so.))

You will find that the marid-mpr draft does allow the protection of the
>From and the MAIL FROM and is a good alternative to the PRA approach.

-Doug

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 14 Sep 2004 19:21:37 -0700

>on a hair-trigger because it could go from zero to a million spams in
This is a FAQ.  You can find an answer here:
http://spf.pobox.com/faq.html#churn
There are RHSBLs in production already.  They are maintained much like 
regular BLs.
(There are also URIRBLs that work quite well, BTW, but that is very OT.)

---

From: Meng Weng Wong <[email-masked]>
Date: Tue, 14 Sep 2004 22:41:51 -0400

On Tue, Sep 14, 2004 at 02:14:45PM -0700, Matthew Elvey wrote:
| I have a $50+ spf t-shirt. I'm trying to make MARID's work
| successful. OTOH: A principal of my mail provider (fastmail.fm's
| Jeremy H) is so unhappy with SPF that he's suggesting configurations
| that appear designed to *sabotage* its effectivenness; an IESG
| member's criticism is provided as justification:
| http://www.emailaddresses.com/forum/showthread.php?threadid=22341&highlight=spf

The unhappiness there seems to be with SPF Classic, and is
remedied by Unified.  I would like to take this opportunity
to expand on some ideas for the working group's
consideration.

| It's certainly been explained many times, on-list, by many people.  I
| see strong confirmation that HELO scope would be useful, and an
| appropriate change to make.  I see little reasoned opposition to a A
| HELO scope.

I now agree that checking HELO can be very useful, as it
satisfies the ESP->ISP whitelisting requirement nicely, and
also has the benefit of making life easier for forwarders
who would then be able to skip SRS.

The ESP->ISP whitelisting requirement can be satisfied by
way of a private arrangement between the parties involved,
so strictly speaking we do not need to standardize that
convention.

But if we want to remove the SRS requirement for forwarders
without weakening protection for the other identities, we
would have to require either one of two things:

1) that we make HELO checking mandatory for receivers, and
   that receivers be easily capable of whitelisting
   forwarding systems by that identity, or

2) that we make SUBMITTER mandatory for forwarding senders
   and receivers.

Of course, we would also specify that a positive result
(where auth+policy both pass) would override failures
elsewhere in the system.

Note that the trusted-forwarder.org checking in most SPF
Classic implementations essentially sneaks the first benefit
into the system, by way of a PTR identity.  That first rule
changes that to a HELO identity, but provides the same
benefit.

If consensus does not oppose HELO checking, then a
"unification" draft could require that receivers always
check the HELO identity (setting aside questions of protocol
and syntax).  Also mandatory would be the return path,
SUBMITTER (when checking before DATA), and PRA (when
checking after DATA) identities.  This choice of identities
is justified by the following argument:

 Making HELO-checking mandatory should satisfy folks who want
 to get their MTAs whitelisted easily.  This includes ESPs
 and forwarders.

 Checking the return path would satisfy folks who want to
 limit unauthorized use of their domain names in the return
 path.

 Checking the SUBMITTER and PRA identities would satisfy
 folks who think validating those addresses will help with
 phishing.

If folks agree, it might be useful to standardize that set
of identities in the "must check" list.

The essential difference between the HELO identity and an IP
address is that it's easier for a receiver to whitelist
*.mta.example.com and not worry about IPs.  This is one big
driver in the ESP->ISP whitelisting relationship.

The essential difference between the HELO identity and the
PTR, both of which are (nominally) hostnames, is that it's
easier for senders in some parts of the world to set up
forward-lookup (domain -> SPF/TXT/A -> ip) mappings than
reverse-lookup (ip -> PTR -> domain) mappings due to PTR
delegation brokenness.  Also we have been asked by the DNS
people to refrain from putting additional load on the PTR
system if possible.

| Some reasons the market may go with the HELO scope instead of the others
| (assuming this leave-it-to-the-market proposal flies) are that it has
| the advantages of not using restricted IPR, doesn't break
| forwarding/mail-list/backup mx operations, and doesn't require end-user
| action to implement.

Agreed, many of the CSV proponents have made these arguments
also.

| Also, the way that Accredidation and Reputation services are to be used
| is essential.  It belongs in a BCP, which should specify BFP (Best
| Future Practice) for how various tests should be interpreted and acted
| upon.  SPF claims to address the spam problem (according to text that
| was on the spf.pobox.com home page) so the Accredidation and Reputation
| services that are a necessary component to this solution must be
| specified.  An incomplete spec that lacks these things has no business
| aspiring to be an Internet Standard.  How can a spec that is grossly
| incomplete be properly reviewed by us or the IESG?  It can't!
| E.g. John Leslie is quite confused about how A&R might work, or I am, as 
| mentioned above.

Yes, a Unified proposal would need to discuss at least
reputation, at least in terms of local policy.  A spec for
Accreditation would also be useful.

As we are getting off topic for MARID, which is focused on
Sender ID at the moment, I suggest we discuss Unified
further in another forum, and report back with our findings
at a more appropriate time.

---

From: Daniel Quinlan <[email-masked]>
Date: 14 Sep 2004 22:24:24 -0700

Yes.
 
> 2) that we make SUBMITTER mandatory for forwarding senders

This cannot work since not all receivers can do SUBMITTER since matching
SUBMITTER to the message is patent-encumbered and the license... you know.
 
Other than that point, I agree and I like.

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 14 Sep 2004 23:20:43 -0700

On 9/14/2004 4:53 PM, Douglas Otis sent forth electrons to convey:

>The obvious reaction to [John's] technique would be to spoof IP addresses of
>known good MX servers in these records.  
>
Yes, the technique won't work.  For folks unfamiliar with RHSBLs:
http://www.rfc-ignorant.org/how_to_domain.php has usage info for their 
RHSBLs.
Ditto http://www.securitysage.com/antispam/rhsbl.html;
http://www.scconsult.com/bill/dnsblhelp.html#3-8

> <>As I said before, the mailbox
> domain within SPF and Sender-ID is worthless for reputation checks.

<moved, also by Doug:><>
<>

> <>I find it difficult to believe people will allow themselves to be harmed

<ditto>

>Let me clarify.  Neither Sender-ID nor SPF will support RHSBLs.
Doug, did you get my email - of a possible broad, strong example showing 
it falling down.
If foo.dom's SPF/SenderID record lists just MX, and doesn't send spam, 
how/why would a reputation service blacklist foo.dom?
e.g .
foo.dom.    IN    TXT      "v=spf1 mx -all"

>>>>....<why HELO>
>>>This is a VERY interesting approach. [...]
>>>
Right, it's not new.  It just doesn't have Marketing Might behind it. 
Of course now it has an encouraging nod from AOL...unofficially, of 
course :)

>>as used in HELO, the reputation would be excellent, and no further checks 
Carl- I'm curious as to whether you think AOL would take advantage of 
this flexibility if it was available.
Is this planned use of HELO roughly what you thought it was? 

>     <snip>

>needed by Sender-ID or SPF.
Cool, though to be fair: what's the upper limit on the number of DNS 
queries marid-mpr might require, assuming a malicious sender attempting 
a DoS?

> <snip>
Confusing paragraph, that.

>such a list will be high or both.
Very efficient.

>...
Folks agree/disagree with that?  (Applies only to SPF and SenderID.)

>>incomplete be properly reviewed by us or the IESG?  It can't!
Folks agree/disagree that MARID specs should cover how they will work 
with A&R services? 
(IMO blacklists and whitelists ARE A&R services.)  The result codes 
from, e.g. sorbs - http://www.dnsbl.us.sorbs.net/using.shtml are more 
than a binary result - some BLs provide bitmapped result codes.
Doug: What do you think?

>>From and the MAIL FROM and is a good alternative to the PRA approach.
Indeed. I have.  It's hell slogging through the acronyms though - MCAL, 
MCNL, etc.  I'll have to read it again in order to be clear on what goes 
where - A vs PTR vs APL... 
Just read BATV - glad to see it!  Perhaps it could pursue a standards 
track - the 'Public Tagging' component means interoperability is 
important so it should pursue standardization.

---

From: Matthew Elvey <[email-masked]>
Date: Wed, 15 Sep 2004 00:21:11 -0700

On 9/14/2004 7:41 PM, Meng Weng Wong sent forth electrons to convey:

>|...
I don't understand why you always talk about HELO checks only in 
combination with whitelisting.
Any domain relevant for a MARID record check is a good candidate for 
checking whitelists and blacklists (A&R services)...
Certainly, it's particularly urgent that forwarders get whitelisted if 
an SPF check on MAIL FROM will otherwise be done because it will fail.
But it makes sense, IMO, for any domain used in HELO that has a good 
reputation (and is authorized for use by the MTA, of course) to result 
in a 'pass'.

BTW, is there a definition of ESP?  As I understand it, fastmail.fm and 
hotmail.com, for example, aren't what you'd call ESPs.  (I'm not sure 
what I would call them.) Is ESP a euphamism for Bulk Mailer?  (E.g. that 
sends anything from bank statements, and bank marketing spam, to 
mainsleaze)  I'd say it's http://www.espcoalition.org/members.php and 
competitors.

>   forwarding systems by that identity, or
I don't see the necessity of the second half of that sentence.  You 
assume receivers will insource whitelist maintenance, and I see no 
reason for making that assumption. I'd say "1) that we make HELO 
checking mandatory for receivers, and easy for A&R service checks to be 
made on the authorized domain."

>into the system, by way of a PTR identity. 
>
That's good, but the full A&R stuff should be in there too.

> That first rule
IIRC, a unification draft was started. Right?
Should this new unification draft be called SPF3? SenderID2? USPF?  What 
would you prefer it be called?

>and syntax).  

>Also mandatory would be the return path,
>  
>
Mandatory?  My reading of the Unified stuff (e.g. the .ppt slideshow) 
was that if HELO resulted in a pass (i.e. a whitelist or strong A&R 
check) then no further checks would be made.
Also what's mandatory? a DNS record supporting it?  It always being 
tested and passing?

> limit unauthorized use of their domain names in the return
Checking this would make sense if previous tests hadn't resulted in a 
pass and/or the retrn path was going to be used - a bounce was going to 
be induced/sent to it.

> folks who think validating those addresses will help with
You've gotta drop PRA.   You'll never get a majority, let alone rough 
consensus, for something 'till you do; someone else's draft will proceed.

>driver in the ESP->ISP whitelisting relationship.
It's also easier to blacklist a domain than an IP!

>people to refrain from putting additional load on the PTR
Oh, I missed that request.  A pointer and/or quote would be appreciated 
if it wasn't made on this list.

>Agreed, many of the CSV proponents have made these arguments
Yup -  I was surprised HELO wasn't in SenderID; I had expected it to be 
more, not less prominent than it was in SFP.

>at a more appropriate time.
IMO, this is the right place/time to discuss HELO and Unified.  
CSV/MPR and Unified are the leading contenders now.

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 15 Sep 2004 01:26:54 -0700 (PDT)

"Matthew Elvey" <[email-masked]> wrote:
>>>> This sounds really cool. But I am an engineer and must always ask, what
>>>> is wrong with this and why has it not been thought of before?
>>
>>>> Lets see, forwarding cases....might work here with some PRA/Submitter
>>>> type changes. Not a huge problem.

With the marid-mpr draft, there is no need to assert the list as
comprehensive (closed) as it is not used to identify the MTA in any
manner.  As such, the typical implementation could treat this list as
nominal to "color" the mail at the MUA and not force rejection of possible
spoofing.  There would be no forwarding issues in that case.

> queries marid-mpr might require, assuming a malicious sender attempting

Unlike the 20 limit recursion in SPF or the 10 script records in Sender-ID
that may then require hundreds of DNS queries to assemble these record
sets, MPR would require one or two queries for a PTR list of EHLO domain
names using the label _mp.smtp.mailbox.dom and a single A record query
using the same _mp.smtp.mailbox.dom label.  (None of this is using reverse
DNS.)  When the MAIL FROM and the From are the same, just a single list
would be needed.  With CSV done first, MPR queries are optional and will
not negatively effect someone's reputation as a result of these MPR check
not being made.  Reputation would always be done using CSV and mail
"coloring" could be done with MPR.

> Confusing paragraph, that.

Currently both Sender-ID and SPF attempt to combine identifying the MTA
and authorizing the sending of the mailbox domain message.  An exploit
these collapsed functions (bogus) authentication with mailbox-domain
authorization create is when the authorization list is "open" (nominal
authorized MTAs, as with ... ?all), this allows others to usurp the
reputation of the mailbox domain by obtaining the bogus authentication.

Closed records could be called "comprehensive" as they encompass the
entire set.  In the case of SPF or Sender-ID, closed records are an effort
to "idiot proof" the mail but then creates problems with forwarding.  With
MPR, these functions are separate and do not allow the exploit.  By
"coloring" the message when outside the nominal mail channel and making
the authenticated EHLO visible, there should be little need to close the
list except for those domains that are typical targets of spoofing.  I
should note that marid-mpr allows for better "idiot proofing."

>>> to.  IETF standards demand it.

With respect to SPF or Sender-ID, there are optional modes that everyone
seems to think are foolish to use, but are still in the draft such as
+all.

> than a binary result - some BLs provide bitmapped result codes.

I think there is more to this than describing how things may work, but
also must consider how these services will be effective at correcting
problems.  To move to a name based reputation or blacklisting, the name
must be authenticated first-hand and not make assumptions about the mail
channel integrity.  In my view, this rules out MAIL FROM and any RFC2822
headers to be used for reputation purposes.

I think much more needs to be provided in the reputation results with a
minimum of time in existence and a complaint count that zeros when the
domain administrator acknowledges the events.  There can be flags that
indicate opt-in only policy agreements, black-listed, unusual traffic
change, size of domain, etc.  I think there needs to be a move away from
relative rating schemes.

> where - A vs PTR vs APL...

It is a bit curt, but was intended just to illustrate how it could be
done.  I had more text, but I trimmed some of the narrative.  I think
feedback will help point out areas that need clarification.

> important so it should pursue standardization.

Yes, I agree.  Much better than the SRS concept in my view.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 15 Sep 2004 04:57:51 -0700 (PDT)

On Tue, 14 Sep 2004, Meng Weng Wong wrote:

> to expand on some ideas for the working group's consideration.

Instead of commenting directly on particular parts of Meng's post, I'm 
going to forward my post to MARID list way back from March 2004. 

My position has not changed - if we deploy one type of SMTP identity 
verification, we should probably deploy another one along with it and 
they both work better filing each other weeknesses. And still think that 
just one identity being is not enough to override negative from another, I 
believe that at least two identties must give postitive authentication 
results to override a negative (if I were to assign values to spf 
modifiers,it would be "-" = -2, "~" = -1, "?" = 0 and "+" = 1) and I do
not believe that setting up PTR is such a problem as some believe (AOL 
requires all mail servers that connect to theirs have it for example).

Now here goes my old post which is still quite relevent today:
--------------------------------------------------------------

Date: Sun, 28 Mar 2004 20:33:17 -0800 (PST)
From: "william(at)elan.net" <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Cc: IETF MXCOMP <[email-masked]>
Subject: Re: Different identities for different problems?

On Sun, 28 Mar 2004, Yakov Shafranovich wrote:

> The goal of attacking hijacked machines is stated in the introduction of 
> the DRIP proposal.

Bad idea - there is nothing that stops spammer from using domain with no 
dns record and it really does not help situation with zombies. All DRIP 
does is possibly help a little with forgeries seen in the end usually in 
the received header which help with tracking and that is all (but usually 
tracking is done by ip anyway).

What does help is the record in reverse DNS (as in MTAMARK) indicating 
that no emails should be sent from this dial or dsl or corporate net 
and this MUST be done by ISP and not anybody else - they are the ones who 
control the ip block and know what is supposed to be there or not, however 
it needs to be more complex then MTAMARK as handle redirection and 
inclusion of user data properly (i.e. SPF or similar). There are also some 
issues with RFC2317 (which is in my opinion just a bad RFC that instead 
of proposing to do futher reverse subdelegation with NS, tried to get by 
with CNAMEs - bad, that means it will only work for PTR records and not 
anything else that might be in in-addr).

But DRIP and/or RMX can be combined together with MTAMARK helping each 
other out. If ISP is not willing to (or what is more likely that its slow 
to act and) properly whitelist the IP of client machine then DRIP or RMX 
can come in and user can setup his email server to specifically whitelist 
this one ip (and only one or two but singular ips not ip range as not to 
give a hole for spammers to setup domains that whitelist entire world).
Same true going back to RMX where airport kiosks annd forwarding server 
and similar (these are the biggest problems with RMX as far as who will 
suffer), their reverse ip can possily be whitelisted and then this will 
indicate that the mail server at that ip will send emails with RMX not 
matching 821 Mail-From (or 822 Mail-From if people on this list think that 
is better).

My thinking is that all of these DRIP, RMX, MTA-MARK should be done 
together if people are willing to do even just one of them. Each one can 
serve its own purpose and at the same time when records are whitelisted
by two of these and blacklisted by the last one, then the policy should
be to let email through allowing to deal with either possible errors in 
setup or delibebetly when its appropriate in the situation. If people 
think it opens the hole for spammers, I can explain that in reality the 
hole is minor one and when using these holes spammers will expose themselve
quite a bit (for example spammer that wants to whitelist his zombie proxy 
will have to setup domain with RMX and DRIP records for each proxy; this 
will allow to track proxy to specific spammer and also provides record of 
intent for law enforcement).

If people are interested I'll write details on this, but I dont want to 
bother if there is not some initial support for it and if everyone just 
continues to argue and push their favorite proposal focusing on one single 
element (except SPF which at least tries to do things in more combined
way focusing how to best accomodate different client implementations).

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Wed, 15 Sep 2004 10:13:25 -0400

On Sep 15, 2004, at 1:24 AM, Daniel Quinlan wrote:

> SUBMITTER to the message is patent-encumbered

How did you come to this conclusion?

-andy

---

From: Tony Finch <[email-masked]>
Date: Wed, 15 Sep 2004 17:48:49 +0100

> How did you come to this conclusion?

It requires use of the PRA algorithm. Checking SUBMITTER against a
Sender-ID record is equivalent to checking the PRA against a Sender-ID
record, which is covered by M$'s vague IPR claims.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LANDS END TO ST DAVIDS HEAD INCLUDING THE BRISTOL CHANNEL: WEST OR NORTHWEST
BACKING SOUTHWEST 3 OR 4, INCREASING 5 TO 7 LATER. MAINLY FAIR. GOOD,
OCCASIONALLY MODERATE LATER. SLIGHT OR MODERATE, BECOMING ROUGH IN THE WEST.

---

From: Tony Finch <[email-masked]>
Date: Wed, 15 Sep 2004 18:00:55 +0100

On Wed, 15 Sep 2004, william(at)elan.net wrote:

> There are also some issues with RFC2317 (which is in my opinion just a
> bad RFC that instead of proposing to do futher reverse subdelegation
> with NS, tried to get by with CNAMEs - bad, that means it will only work
> for PTR records and not anything else that might be in in-addr).

What makes you think that? To extend an example from RFC 2317:

   $ORIGIN 2.0.192.in-addr.arpa.
   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
   ;...
   0/25            NS      ns.A.domain.
   1               CNAME   1.0/25.2.0.192.in-addr.arpa.

   $ORIGIN 0/25.2.0.192.in-addr.arpa.
   @       IN      SOA     ns.A.domain. hostmaster.A.domain. (...)
   @               NS      ns.A.domain.
   1               PTR     host1.A.domain.
                   TXT     "ASRG.MTA=yes"

The CNAME refers to the whole RR set, not any particular RR type.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: SOUTHEAST 4 OR 5 INCREASING 7 TO SEVERE GALE 9,
VEERING SOUTH 6 OR 7 LATER. RAIN. GOOD BECOMING MODERATE OR POOR &NBSP;.

---

From: Meng Weng Wong <[email-masked]>
Date: Wed, 15 Sep 2004 13:09:45 -0400

On Wed, Sep 15, 2004 at 05:48:49PM +0100, Tony Finch wrote:
| 
| It requires use of the PRA algorithm. Checking SUBMITTER against a
| Sender-ID record is equivalent to checking the PRA against a Sender-ID
| record, which is covered by M$'s vague IPR claims.
| 

I wouldn't have a problem if somebody wanted to treat
SUBMITTER as a first-class identity.

The constraint that PRA == SUBMITTER could be left for
patent-encumbered implementations to enforce.
Implementations which do not wish to touch PRA could leave
that constraint unenforced.

Because we would subject the SUBMITTER identity to
reputation/accreditation/local-whitelisting/policy checks
before accepting the message, the risk of weakening
protections for the other identities seems diminished.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 15 Sep 2004 10:10:29 -0700

>record, which is covered by M$'s vague IPR claims.

Of course, this assumes that SUBMITTER is being checked.  In past discussions on SUBMITTER, it hasn't been clear (to me) that this would always be done.  Which makes me wonder how much value SUBMITTER has, since it can then be spoofed to anything that works.

On the other hand, perhaps if the SUBMITTER address is checked against (just) the From address, and if different the From address is rewritten to make the SUBMITTER address that was used visible to the recipient, it might be useful.

-Jim

---

From: Andrew Newton <[email-masked]>
Date: Wed, 15 Sep 2004 13:43:38 -0400

On Sep 15, 2004, at 12:48 PM, Tony Finch wrote:

> Checking SUBMITTER against a

Considering that there is no patent claim against the -submitter draft, 
I find this really hard to believe.  If you believe this, then you 
might as well believe that checking MAIL FROM against a DNS record is 
covered by their claims.

-andy

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 15 Sep 2004 11:11:16 -0700 (PDT)

> What makes you think that? To extend an example from RFC 2317:

1. Answering as to why I think RFC2317 is bad will take quite a number of 
   bits and is probably absolutely off-topic to this list. If you're 
   interested I'll answer answer in private.

2. RFC2317 may well be depreciated in the future and replaced with DNAME
   for dns forwarding of reverse dns zones. RFC2317 style delegation is
   not widely used today anyway.

3. The CNAME from PTR did not work on some of the servers I have.
   The problem is resolevers and not strictly standard, it appear some 
   resolvers will simply not do query on txt when asked about ip address - 
   but you can still force it manually by asking txt on
   reverse-ip.in-addr.arpa. Its not a big deal.

4. The point I made back is no longer important because, by May 04,
   I came up with idea to not bother putting TXT records directly
   in IN-ADDR zone but to put them in forward zone of PTR dns name
   pointed from IN-ADDR zone (see example later in this post):

   That works much better as far as deployment is concerned:
    1. Most mail servers already look up PTR name of incoming client
    2. If there is no PTR name, why bother asking for TXT
    3. ISPs are relactant to give its customers access to INADDR and
       most ISPs are unwilling to do redeligation like RFC2317 suggests
       (I can explain why, but it would take quite a bit of text).
       But at the same time ISPs are usually willing to set inaddr to
       to dns names that their dedicated-level customers want; once
       this is done customer has full control of what to enter for
       mail policy record (like SPF) and does not need to bother
       contacting ISP if he needs to make changes to the policy.
    4. For many mail servers, reverse dns points to the correct forward
       name of the mail server which is very often also used for EHLO
       As such for many systems, one policy record can cover both
       EHLO and PTR scopes

   For reference here is  example of how PTR record can be entered:

     1		     PTR     mail1.example.com.

   $ORIGIN example.com.
     mail1   	     CNAME   "v=spf1 ptr -all"
     mail1   	     CNAME   "SPF2.0/PTR ptr -all"
     mail1	     A	     192.0.2.1

> The CNAME refers to the whole RR set, not any particular RR type.

In fact strictly speaking you're not supposed to be able to enter any 
other type of dns record for host if you enter CNAME there.

---
William Leibzon, Elan Networks:
 mailto: [email-masked]
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/

---

From: Tony Finch <[email-masked]>
Date: Wed, 15 Sep 2004 19:10:38 +0100

On Wed, 15 Sep 2004, Andrew Newton wrote:
> > Checking SUBMITTER against a Sender-ID record is equivalent to
> > checking the PRA against a Sender-ID record, which is covered by M$'s
> > vague IPR claims.
>
> Considering that there is no patent claim against the -submitter draft, I find
> this really hard to believe.

My comment is not about which drafts are covered by the patent claims but
about why an implementation that checks SUBMITTER necessarily infringes on
the IPR.

The IPR claim is against using -core and -pra in combination. -core
defines a system for checking the PRA against a -protocol record. If you
instead check the SUBMITTER against a -protocol record, -submitter
requires that you ensure that the SUBMITTER is the PRA. Thus, you are
checking the PRA against a -protocol record, which is covered by the IPR
claim.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LYME REGIS TO LANDS END INCLUDING THE ISLES OF SCILLY: WEST OR NORTHWEST
BACKING SOUTHWEST 3 OR 4, INCREASING 5 TO 7 LATER. MAINLY FAIR. MAINLY GOOD.
SLIGHT OR MODERATE, BECOMING ROUGH IN THE WEST.

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 15 Sep 2004 11:30:33 -0700 (PDT)

On Wed, 15 Sep 2004, Jim Fenton wrote:

> Of course, this assumes that SUBMITTER is being checked.  In past 
> discussions on SUBMITTER, it hasn't been clear (to me) that this would 
> always be done.  Which makes me wonder how much value SUBMITTER has, 
> since it can then be spoofed to anything that works.
> 
> On the other hand, perhaps if the SUBMITTER address is checked against 
> (just) the From address, and if different the From address is rewritten 
> to make the SUBMITTER address that was used visible to the recipient, it 
> might be useful.

I'll remind that I posted a set of ideas to extend SUBMITTER in similar
way -  http://www.imc.org/ietf-mxcomp/mail-archive/msg04726.html

I'd like to receive more comments about this as far its only been one 
public comment and 4 private ones (but all positive ones!).

Also it would be good if we had an answer from Pete Resnick regarding
interpretation of RFC2822 and how it applies to the the current marid-core
draft and its use of Resent-From headers by different types of 
forwarders and by mail lists. Such interpretation would help in deciding 
what the next steps should be in regards to the SenderID and Submitter.

---

---

From: Daniel Quinlan <[email-masked]>
Date: Wed, 15 Sep 2004 12:22:47 -0700

Daniel Quinlan wrote:

>> This cannot work since not all receivers can do SUBMITTER since
>> matching SUBMITTER to the message is patent-encumbered

> How did you come to this conclusion?

The submitter can put whatever value they want in the SUBMITTER field.
The receiver needs some way to associate the SUBMITTER value with the
RFC 2822 message or the check is not meaningful.  The method for
associating SUBMITTER is PRA and PRA is patent-encumbered.  Since Meng
presented two options and one can be used for everyone and other cannot
be used by everyone, the latter therefore doesn't satisfy the
requirement presented by Meng.

The associated requirement is that whatever non-PRA methods we define
(mail-from and helo, for example), we need some RFC 2822 header(s) that
MTAs can add so later stages (like MDA-based or MUA-based filters) have
access to the envelope data and, if it has already been done, the
result.

Daniel

-- 
Daniel Quinlan                     ApacheCon! 13-17 November (3 SpamAssassin
http://www.pathname.com/~quinlan/  http://www.apachecon.com/  sessions & more)

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Sep 2004 12:37:41 -0700

> might as well believe that checking MAIL FROM against a DNS record is 

Submitter information is not within a specific header.  Safe use of the
Submitter parameter requires the assertion affirmed (by way of the PRA
algorithm).

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 16 Sep 2004 01:16:32 +0200

Matthew Elvey wrote:

>> we have been asked by the DNS people to refrain from putting
>> additional load on the PTR system if possible.

> Oh, I missed that request.  A pointer and/or quote would be
> appreciated if it wasn't made on this list.

<http://article.gmane.org/gmane.ietf.mxcomp/2707/match=apnic>

                          Bye, Frank

---

From: Matthew Elvey <[email-masked]>
Date: Thu, 16 Sep 2004 21:58:14 -0700

Well, draft-ietf-marid-protocol-03.txt was very disappointing, so I went 
ahead and did what needed doing.

I made some edits and made a new Internet-Draft based on it: SPF3.
I summarize the changes as follows:
s/typos/corrections/
s/Most of 6.2  Processing Limits/<new text>
s/mail from or PRA/HELO/
s/mfrom,pra/helo/
s/spf2.0/spf3.0/
s/Mark,Meng/me/
s/SenderID/SPF3/
Some tweaks to the Abstract.
Allow SPF1 records to be used. Strangely, 
draft-ietf-marid-protocol-03.txt didn't allow this!

The effort put into the edit may have produced something of lesser 
quality than one expects from Microsoft.

Comparison of SPF3 and CSV+MPR:
Organizationally, it's superior, in that it leverages the existing base 
of SPF1 records.  It's easier to understand, includes examples, and it's 
easier to create TXT records - of bind, GoDaddy and ZoneEdit, only BIND 
supports what CSV requires. 
Technically, it's inferior, in that its usage of DNS is less efficient 
and less standards-based. MPR also has the cool bitmapped fields for 
explicit protection of 2822.From:, etc.  This could be added to SPF3.

Comparison of SPF3 and SPF1 or SenderID:
It's superior, in that it doesn't break forwarding, is much more 
efficient, and can't be tricked by forged or misleading headers,  
requires about 99% less effort to implement, on a global basis,  is 
based on an algorithm that predates M$' patent filing, and provides 
something that can be better accredited.

=-=-=-=-=
Rest of this post: Re: HELO and Unified ; new scope? ;  Microsoft oops; BCP

On 9/15/2004 12:58 AM, David Woodhouse sent forth electrons to convey:

>
>My suggestion is that we should go forward with an entirely _different_
>scope, not just unify on either mail-from or whatever the unencumbered
>pra replacement would be.
>
>There are many possibilities which would offer us some 'handle' on the
>owner of the mail server in question, without all the problems which
>both mail-from and pra scopes suffer.
>  
>
The 'handle' needs to be something non-free, otherwise spammers will 
make an infinite number of them.
Domains are a good choice.   A domain with a valid SSL cert would be 
another choice.
Spamhaus.org's .mail proposal would be another good choice.
Unsigned certs or signed thawte freemail certs would not be acceptable.

=-=-=-=-=

There's a false statement in Microsoft's previous IPR disclosure statement:

>VIII. Other Notes: ** A license to implement these specifications
>will be made available at http://www.microsoft.com/mscorp/standards on
>or before September 15, 2004.
>
http://www.microsoft.com/mscorp/ip/standards/ has it.

=-=-=-=-=

>>>additional load on the PTR system if possible.
(And the mess of mis/unattributed quotes continues. I didn't write that.)

><http://article.gmane.org/gmane.ietf.mxcomp/2707/match=apnic>
Thanks.  An interesting thread.  It suggests that the RIRs have little 
to worry about.
If MARID is halfway successful, the load on their servers is likely to 
go way DOWN.
PTR lookups are already the norm.  MARID should cut mail volumes are cut 
by more than half (most mail is spam), so PTR lookups can be expected to 
go down as well.

BTW, RIR gross failure to address their responsibilities, as evidenced by
http://www.spamhaus.org/sbl/listings.lasso?isp=APNIC ,
(not to mention
http://www.spamhaus.org/sbl/listings.lasso?isp=ARIN ) <ahem> well, 
umm...  I...
They're knowingly providing Spam Support Services...

=-=-=-=-=

With respect to being able to outright reject forgeries without breaking 
forwarding: 
With HELO checks + A&R, I can see this becoming reasonable BCP.  Here's how:
Forwarders (and mailing list hosts) will be expected to be runnning 
MARID on their MTA.  If they are too lazy to do so, then they will be 
found to be forwarding on obvious (to anyone using MARID) forgeries, and 
thus their reputations will (justifiably) suffer.  It will probably not 
be fair to blame 'em for all spam they forward, but it will be fair to 
blame them for forwarding on obvious forgeries. The responsible 
forwarders running MARID can be expected to have good HELO reputations.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 17 Sep 2004 15:16:27 -0700

> Of bind, GoDaddy and ZoneEdit, only BIND supports what CSV requires. 
> and less standards-based.  MPR also has the cool bit-mapped fields for 

Are you referring to web-based GUI interfaces for DNS entries to support
services?  Looking at their documentation, it was not clear that it was
possible to enter a TXT record either.  I would imagine do-it-yourself
providers will offer needed interfaces for elements supporting their
service once it becomes prevalently needed.  CSV is simple enough to
have it defined without any user intervention other than selecting the
host.

It is not clear what was being compared in this sentence.  I will assume
you were saying CSV is inferior.  : )

The SRV record is used extensively by Microsoft and acts as a
replacement for their WINS.  On some older versions of Bind, the name
checking is disabled to allow the underscore.  Use of the SRV record
does not require a text parser to interpret the record.  The SRV record
also automatically assembles relevant address records reported in the
additional data section.  Use of a TXT record which encodes other
domains, users, error messages, hostnames, addresses, settings, macros,
and is extensible will require a forever evolving parser.

With more and more flavors of TXT records employed due to the example
made by SPF, as well as adopting a practice of using wildcards, any use
of an extensible text script is not without risk.  Unlike other DNS
records with content defined by the record type, the TXT record should
assume opaque text strings.

Unlike SPF, names are consistently used and do not require the double
entry of host addresses as SPF may.  The alternative to replicate
address entry when using SPF, is to use record references and then cause
subsequent DNS lookups to then obtain the addresses for each reference. 
SPF is neither more standard or efficient.  The MPR name lists also
removes the need for subsequent lookups which are the bane of the SPF
approach.

The MPR lists, being a separate from the MTA authentication and
authorization, avoids the problems of "open" lists that invite
spoofing.  MPR can be deployed with an "open" list as a SHOULD without
any exploit concerns.  By marking or "coloring" the mail as being
outside the nominal mail channel, this should offer better consumer
protection than that achieved with Sender-ID's PRA algorithm yet not
breaking mail forwarding.

> Forwarders (and mailing list hosts) will be expected to be running 

Is this in reference to CSV?

-Doug

---

From: Matthew Elvey <[email-masked]>
Date: Fri, 17 Sep 2004 20:43:28 -0700

First: Have any of the folks who've done surveys of the DNS for SPF 
records archived the actual records they found?
I hope so; they may turn out to be useful down the road.

On 9/17/2004 3:16 PM, Douglas Otis sent forth electrons to convey:

>services?  
ASPs providing DNS services.  (Same thing said differently?)

>Looking at their documentation, it was not clear that it was
>possible to enter a TXT record either.
>
They support TXT records.

>  I would imagine do-it-yourself
In the case of SPF1, coming up with reasonable data to feed the wizard 
at pobox.com is the main stumbling block.
Given a good result from the wizard and raw access to TXT, it's easy to 
put the former into the latter.
But again, the data required for a good SPF1 record (e.g that doesn't 
have ?0/0) is often difficult to determine.
CSV is simpler, so if raw access to the required RR type is available, 
we'd be good; with a wizard, we'd be great.
It would be a bit of a 'stub' wizard- one or two questions, tops.

>you were saying CSV is inferior.  : )
Uh, no.   I was saying SPF3 is inferior in certain tecnical respects in 
comparison to CSV+MPR!
It was clearer when it was in context.

>The SRV record is used extensively...  
>
>Use of a TXT record which encodes other
Right; there's a risk-benefit evaluation to me made.  I'm sensing most 
people prefer to take the risk and get the benefit; but I wouldn't call 
it a rough consensus yet.

>removes the need for subsequent lookups which are the bane of the SPF
Yes, SPF is neither more standard or efficient, etc.
In SPF3, domains are consistently used, and it's more efficent than 
SPF/SPF1 or SenderID/SPF2.

>breaking mail forwarding.
This would be so greatly clarified by specific sample M.A.R.I.D. 
illustrating such open lists failing!

>Is this in reference to CSV?
It's in reference to any MARID scheme relying heavily on HELO, such as 
CSV, or SPF3.

I'd wager you're in agreement.

I put SPF3 up here:
http://elvey.com/it/sieve/draft-ietf-marid-spf3-00.txt
as it's not up at
iietf.org/internet-drafts yet.

To save folks time, I put up
http://asrg.sp.am/wiki?action=history&id=Spf3 .

Folks may want to look at that to see a quick diff showing the
"*Substantive Changes*" between my draft and draft-ietf-marid-prococol-03.