Subject: change of version string

From: Meng Weng Wong <[email-masked]>
Date: Mon, 9 Aug 2004 19:14:52 -0400

First of all, thanks Mark for a whole lot of work!

At the WG meeting in San Diego, a number of arguments were
cogently advanced regarding the change of version string.
I would like to comment on the proposed change.

Because v=spf1 strings were semantically associated with the
2821.mail-from parameter, and because Sender ID prefers the
2822.PRA/2821.SUBMITTER above 2821.mail-from, a change of
version string (to v=spf2 or suchlike) was proposed.  This
change is intended to disambiguate SPF Classic from Sender
ID, to accommodate sender domains whose policies regarding
the PRA might differ from their policies regarding the
mail-from.

While such a change is, from the standpoint of architectural
purity, absolutely the correct thing to do, I fear that in
practice it may lead to confusion, needless duplication of
records, and a failure to achieve the intended objective.
In other words, it is my opinion that engineering
considerations do not weigh in favour of changing the string.

I particularly do not want to see a world where the norm is:

  example.com TXT "v=spf1 a mx ptr"
  example.com TXT "v=spf2 a mx ptr"

Both records would contain the same content, yet senders
might feel the need to publish both "just to be on the safe side".

Assuming that the email ecosystem adopts the recommendations
of this working group, I believe that the number of
scenarios which would benefit from a distinction between
v=spf1 and v=spf2 is practically nil.  If I am right, and if
we change the string, I fear that implementors will complain
that we have inconvenienced them gratuitously.  While it is
true that anyone who has already implemented SPF Classic
will need to make a number of changes in response to PRA and
SUBMITTER, changes that relate to the version string are of
a different order.

Therefore, I recommend that we do not change the version
string.  To accommodate the rare (and so far hypothetical)
cases where disambiguation is desired, we can instead define
a scope modifier or scope macro which will serve the same
function at a much lower cost.

I do not feel particularly strongly about this.  If the
working group as a whole feels that changing the string is a
wiser course of action than not changing it, I will not
press my objection further, especially in light of the
deadlines.  I just want to share a point of view which I
feel is underrepresented.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 10 Aug 2004 10:40:19 -0700

>might feel the need to publish both "just to be on the safe side".

Both records do _not_ contain the same information.  The first
record has a target of MAIL_FROM; the second has a target
of PRA.  The fact that the strings "a mx ptr" happen to be
the same in both records does not change that fundamental
fact.  The fact that the same IPv4 dotted quad might appear in
an MX record and NS record for example.com doesn't change
the fact that the records tell you different things about how
that domain's systems are set up.  The situation here is
parallel; it isn't as obvious because you're using the overloaded
TXT record rather than the new RR.

As an aside, this is one of the practical reasons why subtyping
the TXT record is a bad idea; it gets very easy to confuse the types,
even for folks who have been working with it for a long time.

			regards,
				Ted Hardie

---

From: wayne <[email-masked]>
Date: Tue, 10 Aug 2004 13:46:45 -0500

In <p06110400bd3eb6b156f7@[67.161.18.242]> Ted Hardie <[email-masked]> writes:

> fact.

*sigh*

1) Meng said that they "contain the same content", not "contain the
   same information".  You appear to be confusing content with
   information.

2) Meng, and many others, have pointed out that in the vast majority
   of cases, the information *will* be the same and changing the
   version number will cause far more problems than it solves.

>        The fact that the same IPv4 dotted quad might appear in

This has *NOTHING* to do with RR types.  The same problems would exist
if we were talking about changing

  example.com TXTspf1 "a mx ptr"
  example.com TXTspf2 "a mx ptr"

That is, deleting a few characters and moving a quote doesn't change
anything.

The huge problem with *just* changing the version string is that it
cuts off future expansion.

Earlier this spring, the co-chairs rules that 2822 identities would be
held off until 2821 identities could be finished, but that we would
return to 2822 identities.  It was made clear that people wanted both,
but the 2822 identities had not been tested (and still haven't), and
it wasn't clear how to check the 2822 identities without creating
large error rates (confirmed by the very limited testing done so far
on the PRA).

At the interim meeting this somehow magically got flipped (without a
confirmation of this decision on the mailing list) and now we are
working on 2822 identities.  Even so, it was made clear that people
wanted to test both.

By simply changing the version number, we are limiting out options on
how to proceed with 2821 checks.  

As I said here: http://www.imc.org/ietf-mxcomp/mail-archive/msg03081.html
the problems with both changing and not changing the version number
can be easily solved by falling back to SPF1 records if no SPF2 record
is published and by defining the Unified-SPF scope macro-variable in
the SPF2 record.

For the vast majority of people, publishing SPF1 records will be all
they need to do or worring about.  For those that require different
records for the PRA check vs the MAIL FROM and HELO checks, they can
publish SPF2 records.

-wayne

---

From: Ted Hardie <[email-masked]>
Date: Tue, 10 Aug 2004 13:57:53 -0700

Inline.

>    same information".  You appear to be confusing content with

No.  I chose the word information to contrast with "content".
I wish to highlight that their containing the same string
does not mean they are answering the same question.

>    version number will cause far more problems than it solves.

I don't think so.  They have tried to say "the answer to the two
questions would be the same", which is not the same as
"the information will be the same".  The answer to the question
"What is the last name of the current occupant of the U.S.
presidency?" and "What is the last name of the artist whose
debut album was 'The Kick Inside'?" may be the same,
but Bush, George W. and Bush, Kate are not the same.

As I pointed out in the recent face-to-face meeting, re-using
the same version string to answer a different question creates
a problem for those deploying these systems:  they must
understand how their string would be understood as an
answer to either question.  Given that we hope this will
have very wide deployment, and given that cost gets paid
by every domain from now on, this is a high price.  As
I channeled John Klensin at the mic, don't look at the current
deployment, look at the rate of deployment to make this call.

>That is, deleting a few characters and moving a quote doesn't change

I personally think this is a lot clearer that the two records are answering
different questions.  The following

example.com 3600	IN 104  "a mx ptr"
example.com 3600 IN 105  "a mx ptr"

is even clearer, since there is no implication that two RRs who happen
to be next to each in type code have anything to do with each other.
Mnemonics like TXTspf1 and TXTspf2 might imply they do.

<snip>

>records for the PRA check vs the MAIL FROM and HELO checks, they can

This doesn't seem to me an argument *against* making them distinct;
it seems to be an argument that the working group should not have chosen
PRA.  Given that it has, making them distinct seems to be pretty much
required.

Speaking without hats,
			Ted Hardie

---

From: Rand Wacker <[email-masked]>
Date: Tue, 10 Aug 2004 14:59:00 -0700 (PDT)

> might feel the need to publish both "just to be on the safe side".

I'm torn between the "records really are validating different things so
they should have different version string" and the "keep the adoption ball
rolling" camps, but I am going to bring up a separate point here.

Forgive me if this snake has been addressed before, but at the WG meeting
last week it seemed to be slightly different.  According to both folks
from Cisco and the in-house DNS experts I've asked, I believe that if you
put in multiple TXT records for the same FQDN (example.com as above), then
*all* of those TXT records are sent back in a single UDP reply packet, so
the 512 (more like 420) byte UDP packet restriction applies to THE
AGGREGATE SIZE of ALL text records for a single FQDN.

While the above example may be reasonably small, AOL's current SPF record
is pushing 170 bytes, which would limit them to publishing only three
concurrent records in the same FQDN space.

I believe that the working group made no objection to sub-domaining
records (publishing TXT in _marid.example.com), so if we go down the path
of changing the version number or even the format we should take that in
to consideration.

-Rand

---

From: John Levine <[email-masked]>
Date: 10 Aug 2004 23:18:38 -0000

> I believe that if you put in multiple TXT records for the same FQDN
> (example.com as above), then *all* of those TXT records are sent
> back in a single UDP reply packet, so the 512 (more like 420) byte
> UDP packet restriction applies to THE AGGREGATE SIZE of ALL text
> records for a single FQDN.

Yes, that's correct.  If a response includes multiple records, which
it will if the query is a TXT query and there are multiple TXT records
for the name, they're all sent in one response packet, which will have
well known problems if they don't fit in a 512 byte UDP response
packet, and less well known but more serious problems if they don't
fit in a single TCP packet.

One of the reasons that the DNS has multiple record types is so that a
query can specify the type it wants and just get the relevant records,
keeping responses small.  Overloading TXT breaks that.

> records (publishing TXT in _marid.example.com)

The problem with _marid subdomains is that they break wildcards, since
DNS wildcards don't permit _marid.*.foo.com.  Some of us have per-user
subdomains implemented with wildcards, and there's no good workaround.
We could publish the TXT records for *.foo.com and let the clients
throw out the ones they don't understand, but then we're back to
stuffing all the TXT records into the same packet.

The only band-aid I can see is to hack up our servers to special case
_marid.*.foo.com, which we weenies can do but I wouldn't wish on the
net in general.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: wayne <[email-masked]>
Date: Tue, 10 Aug 2004 18:16:16 -0500

> but Bush, George W. and Bush, Kate are not the same.

I can appreciate your comparisons of the same IP address showing up in
an MX and NS record and the above anlogy about two people with the
same last name of Bush.  You are trying to draw a shart distinction
between the questions and the answers.

The thing is that the two MARID questions being ask are:

1) Is it valid for this IP address send an email with a MAIL FROM
   and/or HELO claiming from being from the given domain?  (SPF-classic)

2) Is it valid for this IP address send an email with a From: header
   claiming from being from the given domain?  (SenderID)

These questions are much more closely related than NS or MX records.

To use your analogy, it is like asking these two questions about the
president:

a) Is the current occupant of the U.S. Presidency over the age of 35?

b) Is the current occupant of the U.S. Presidency a U.S. citizen?

The answer two these two questions is "yes" for all U.S. Presidents
that have ever been and will likely to ever be.  This is not just
because of some cosmic coincidence, but because these two questions
have a common root in the requirements of being a U.S. President.

Similarly, the answer to the two MARID questions are also almost
always the same because of common roots.

Understanding the common roots leads to a deeper understanding of what
we are doing.  Understanding what the co-chairs have said we will try
to address in the foreseeable future make finding this deeper
understanding very relavant to what we are doing today.

As far as cosmic coincidences go, I suspect many people can guess the
answers to the following questions:

1) Which week did the warranty of my laptop run out?

2) Which week did my laptop die?

3) Which week did I really need to post a bunch of stuff to MARID list
   about the current I-Ds, but is sitting on a dead laptop?

*heavy sigh*   (Yes, I have backups.  No, backups are not an easy
replacement.) 

In another message:

In <[email-masked]> Rand Wacker <[email-masked]> writes:

>>From Cisco and the in-house DNS experts I've asked, I believe that if you

Yes, is a well known issue and one of the goals of SPF was to make
records as small as practical.

> concurrent records in the same FQDN space.

AOL is not the largest SPF record I found when doing the surveys of
1.3 million email domains, but it is certainly one of the largest.
Even so, AOL can fit two SPF-like record into a UDP DNS packet.  

Meng et al worked hard to make the print of SPF records small, and
first thing the IETF doing doubling the space used.

> of changing the version number or even the format we should take that in

Publishing into a sub-domain doesn't really help if this working group
is going to turn about and create more records for 2821 identities.

Changing just the version number of SPF records is bad engineering,
bad for maintenance, creates confusion, and is short-sighted.

-wayne

---

From: David Blacka <[email-masked]>
Date: Tue, 10 Aug 2004 20:13:53 -0400

> TXT record rather than the new RR.

Just as an annoying DNS nit: IPv4 dotted quad addresses in MX or NS records 
are misconfigurations (in the MX case, this is somewhat common, but it is 
still wrong).  The targets of MX and NS records are DNS names, not IP 
address.  Those names then map to IP addresses via A or AAAA records.

Not that this diminishes Ted's point.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    VeriSign Applied Research

---

From: David Blacka <[email-masked]>
Date: Tue, 10 Aug 2004 20:08:57 -0400

> fit in a single TCP packet.

I admit to hearing this statement at San Diego last week, but I didn't 
understand it then, and I don't understand it now.  What is being referred to 
with the term "TCP packet"?  Is this a reference to the MTU?

I will admit to not being familiar with *all* DNS software, but I am having a 
hard time believing that there is DNS resolver software that a) does TCP, but 
b) somehow is unable to read an entire DNS message using TCP if it requires 
more than a few IP packets to transmit.

It is more credible for me to believe that there is DNS software that won't 
fall back to TCP, or that there are some that don't actually allocate 64k 
(the actual maximum) of space for receiving a message. 

> stuffing all the TXT records into the same packet.

Since no one seems to be talking about removing the "v=spf1/2" from the 
beginning of TXT RDATA, I don't think "break" is the correct term here.  The 
_marid subdomain seems to improve the subtyping situtation in the 
non-wildcard case, and leave the status quo in the wildcard case.  This looks 
like a net improvement to me.

So if you need multiple TXT records at your wildcard, you will have to be 
careful about the size of that TXT RR set, but everyone else gets more 
leeway.

---

From: John Levine <[email-masked]>
Date: 11 Aug 2004 00:56:33 -0000

>with the term "TCP packet"?  Is this a reference to the MTU?

Yes.  I was surprised to learn that there is a bug in widely used
resolver libraries so that if it makes a TCP request, and the response
isn't entirely contained in the first packet, the resolver gives up and
retries.  A large DNS provider thought it was being DDOS'ed (actually, it
was being DDOS'ed) and tracked it down to this bug being triggered by
some large response data.

>more than a few IP packets to transmit.

Believe it.  I think it's due to bugs in the code that waits for a
response or a timeout and doesn't go back to look for more data after
getting the first data chunk back.  Given how few DNS queries have
needed TCP, and how few of the responses have been too big to fit in a
1500 MTU, it's not surprising nobody's noticed before.

>careful about the size of that TXT RR set, but everyone else gets more 

I suppose that's true.  It still seems to me to be asking for trouble,
since any unrelated application with TXT records is going to load up
the responses as well.

---

From: kent crispin <[email-masked]>
Date: Tue, 10 Aug 2004 18:51:07 -0700

> Mnemonics like TXTspf1 and TXTspf2 might imply they do.

But it would then follow that a new dns record type would have to be
generated for every change.  Alternatively, you could have a version in
the data:

example.com 3600 IN SPF "104 a mx ptr"
example.com 3600 IN SPF "105 a mx ptr"

(In this case the full rr set would be returned, and the client would
then know all supported versions and could make a choice, for whatever
that's worth.)

The issue of where the version number is located is independent of the
record type. 

-- 
Kent Crispin 
[email-masked]    p: +1 310 823 9358  f: +1 310 823 8649
[email-masked] SIP: [email-masked]

---

From: Rand Wacker <[email-masked]>
Date: Tue, 10 Aug 2004 19:53:12 -0700 (PDT)

On Tue, 10 Aug 2004, John Levine wrote:

> DNS wildcards don't permit _marid.*.foo.com.

I seem to recall at the WG meeting that people *did not object* to
breaking wildcards.  If I am incorrect I'll be happy to retract, but we
should probably refrain from rehashing what I'm pretty sure is a
discussion that has been archived around here once or twice.

-Rand

---

From: Rand Wacker <[email-masked]>
Date: Tue, 10 Aug 2004 19:56:03 -0700 (PDT)

> (the actual maximum) of space for receiving a message.

The issue is more operational, there will be quite a bit of resistance by
site security admins to open up TCP port 53 for queries of that size, and
even more resitance by sites that receive A LOT of mail to accept the
possibility of making outbound TCP queries for large number of incoming
messages.

-Rand

---

From: David Blacka <[email-masked]>
Date: Wed, 11 Aug 2004 00:19:48 -0400

> possibility of making outbound TCP queries for large number of incoming

I'm not sure what you are arguing about, here.  I was merely expressing 
incredulity that a bug of a particular nature would exist, but, I 
suppose I will have to take John's word for it.  I am still trying to 
imagine *how* this bug could have been written, but I suppose that is 
really just a lack of imagination on my part.

Seriously, falling back to TCP is how DNS works.  Firewalls can block 
it, software can not support it, clients can refuse to do it, but, in 
doing so, they must accept the responsibility that some of their DNS 
queries/responses will not work.

All we can do is recognize that operational constraints exist and 
suggest that folks do not publish overly large RR sets, which we appear 
to be doing.

--
David Blacka    <[email-masked]>
Sr. Engineer    Verisign Applied Research

---

From: Jim Fenton <[email-masked]>
Date: Tue, 10 Aug 2004 21:57:15 -0700

>of changing the version number or even the format we should take that in

I remember that one problem with _marid.example.com was that one lost wildcard behavior; it isn't possible to have _marid.*.example.com to resolve requests for sub.example.com.  But it was less clear to me whether one could publish a record for *.example.com and have it work "as desired" for messages from sub.example.com.

I have been a bit concerned about the loss of an outgoing counterpart to wildcard MX record behavior.  In other words, if you can have wildcard MX records to accept mail for *.example.com, you should be able to have something that indicates the outgoing mail servers for *.example.com.  This might be an area where a new RR has an advantage over _marid TXT records.

Short of wildcarding, here are a couple of options:

1. The recipient tries the domain in the PRA, and if that fails starts walking up the tree (first sub.example.com, then example.com, then (hopefully not) com) looking for a MARID record.

2. The originator includes a message header indicating the appropriate level of abstraction for the MARID record.  So a message from [email-masked] might have a header like "MARID-Domain: example.com".  I suspect this runs counter to the MARID approach of not changing the 2822 headers.  In the MASS world, Identified Internet Mail and DomainKeys both include this with the signature in order to find their keys or key authorization data.

Do either of these seem workable?  I'm concerned that the wildcards won't do the Right Thing.

-Jim

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 11 Aug 2004 09:11:26 +0200

John Levine wrote:

> The problem with _marid subdomains is that they break
> wildcards, since DNS wildcards don't permit _marid.*.foo.com

I'm not exactly sure what you're talking about, my nslookup
is not exactly new - what says 5.42 UCB 3/3/91 - and it has
no problem with wildcards:

_marid.xyzzy.claranet.de  text = "v=spf1 redirect=claranet.de"
xyzzy.claranet.de         text = "v=spf1 redirect=claranet.de"

> Some of us have per-user subdomains implemented with
> wildcards, and there's no good workaround.

xyzzy.claranet.de _is_ a per user vanity host, it's only used
for addresses @xyzzy (catch-all), and for http://www.xyzzy

So if you have a sender policy for *.example.org now and it
covers foo.example.org, then it would automatically cover
_marid.foo.example.org
                        Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 11 Aug 2004 11:18:05 +0200

wayne wrote:

> For the vast majority of people, publishing SPF1 records
> will be all they need to do or worring about.  For those
> that require different records for the PRA check vs the MAIL
> FROM and HELO checks, they can publish SPF2 records.

Existing sender policies use v=spf1 and are meant to check
only the MAIL FROM.  They don't allow SUBMITTER, where some
bounces would be sent again to an innocent MAIL FROM when
a malicious SUBMITTER got a PASS for his PRA, and something
between MX and MUA detects this or another problem too late
for a REJECT.

If that's the case then SUBMITTER is incompatible with SPF.
And if SUBMITTER is only an accelerated PRA test (allowing
early rejection before DATA) then anything not rejected by
PRA could later result in bounces to the forged MAIL FROM.

I really hate these bounces, and writing a script to send
MAIL FROM:<forged@xyzzy> SUBMITTER=[email-masked]
with Sender: trust me <[email-masked]> is easy,
and getting directi.example IN TXT "v=spf1 +all" is cheap.

At the moment this would result in a Sender-Id PASS and
later probably in a bounce to me.  And I don't want this.

But I do want to use "my" address From: nobody@xyzzy with
an MSA forcing MAIL FROM:<[email-masked]>, and I don't
want this to be rejected based on the v=spf1 sender policy
for xyzzy.

Therefore somebody wanting PRA _and_ MAIL FROM tests has to
say so in his sender policy, because that's the unusual case
after months of propagating and implementig SPF classic.

There are numerous documents and articles "in the wild" 
explaining classic SPF, and they don't say "but you can't
use your address in From: headers anymore unless [PRA]".

> it is like asking these two questions about the president:

PRA asks "is a U.S. citizen over the age of 35 eligible as
president ?"  SPF classic asks "is the U.S. president a U.S.
citizen over the age of 35 ?"  The answers can be different.

                        Bye, Frank

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 11 Aug 2004 02:59:03 -0700 (PDT)

> > example.com 3600 IN 105  "a mx ptr"

Perhaps it would be usefull if we allow one type of SPF record to reference
(include, refer to) another type of SPF record, this would eliminate 
duplication problems in case of long records and avoid issues with large 
dns packet (because of multiple large txt records) as well.

Right now in the drafts published it is not clear if this is allowed, but 
my reading from MARID drafts is that for MARID (i.e. v=spf2 or v=marid1,  
whatever) it is not and in case of reference, it must refer to the same 
v=marid type/version txt record. I understand this to be the resolt of an 
issue in that we can not easily reference different txt records for the 
same domain (FQDN), especially a problem when you have to reference same
FQDN as the record itself (i.e. like with above example). So to change 
that it would be necessary to slightly enhanced syntax to allow include 
to specify type (version) of SPF txt record. An example of what I'm 
proposing is below:

example.com TXT "v=spf1 a mx ptr"
example.com TXT "v=spf2 include:example.com/v=spf1"

(ok from the above example the include itself is longer the original 
 record, but for longer records, it makes more sense)

> The issue of where the version number is located is independent of the

Not quite, if we go with pure TXT-like record for new MARID dns type, then 
versioning is expected to be done same as with SPF TXT record (i.e. its 
part of the data text portion), But when doing new dns record type we do 
have an option of having some required parts of the data put into their 
own specified binary locations in record separate from main text portion.
In case of version number this saves a little (2 bytes taken by "v=") on 
the size of typical record. So for example record would look like:
  example.com SPF 1 "a mx ptr"
rather then pure text representation like
  example.com SPF "v=1 a mx ptr"

But doing it with one byte (or two bytes just in case) for version number 
does mean we're adding something new for IANA to keep track off and adding
new version type can not be done by "name" (i.e. "spf1" or "marid1") and
it we're expecting for all clients to know version number or be able to 
look it up by name in IANA records.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Peter Koch <[email-masked]>
Date: Wed, 11 Aug 2004 13:34:47 +0200

> isn't entirely contained in the first packet, the resolver gives up and

could we please have a bit more facts on the table? Which implementation is
that and up to which version?

> getting the first data chunk back.  Given how few DNS queries have

So that would be a resolver that implements at least part of TCP on its own?
Again, names please. There have been far too many rumors and hearsay wrt
DNS on this list.

> 1500 MTU, it's not surprising nobody's noticed before.

1500 is not a critical number here, 512 is. An there are lots of answers
that do need >512 octets, especially in the IN-ADDR tree.

-Peter

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 11 Aug 2004 04:50:25 -0700 (PDT)

On Tue, 10 Aug 2004, Rand Wacker wrote:

> breaking wildcards. 

Perhaps we were at different meetings, for I do not remember this.

Wildcards were not in fact discussed at WG meeting in any serious manner 
as it was understood that SPF TXT records were easy with wildcards as they
go directly under the domain and so will future dns specific record type.
As such people were not objecting because wildcards were in fact already
part of the design and fully supported.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 11 Aug 2004 13:54:20 +0200

> So that would be a resolver that implements at least part of TCP on its own?

No, anything that uses nonblocking I/O would be vulnerable to this 
programming error. It's not unusual. To name one well-known product: 
the Cisco PIX had a similar error in its SMTP implementation a year or 
three ago.

It could be that on some platforms, code using blocking I/O could be 
vulnerable too. It's been a few years since I looked into this in 
detail. Suffice to say: It's an easy mistake to make.

Arnt

---

From: Andrew Newton <[email-masked]>
Date: Wed, 11 Aug 2004 10:05:33 -0400

On Aug 11, 2004, at 12:19 AM, David Blacka wrote:

> I am still trying to imagine *how* this bug could have been written, 
> but I suppose that is really just a lack of imagination on my part.

Me too, as in I'm trying to imagine which API they used and why?

-andy

---

From: Michael Thomas <[email-masked]>
Date: 11 Aug 2004 07:46:15 -0700

> stuffing all the TXT records into the same packet.

  Forgive me since this is undoubtedly in the copious
  archives, but what is the scenario here that breaks?
  If I had a user subdomain off of the main domain like:

  user1.example.com

  couldn't I just publish a record like:

  _marid.user1.example.com

  ? Or is the problem that you'd need to enumerate each of
  your users? Or am I completely in the weeds here? And do
  you have any sense of how many sites would be impacted
  (ie, are we in 80/20 rule territory here)?
-- 
Michael Thomas	([email-masked] http://www.mtcc.com/~mike/)

---

From: Michael Thomas <[email-masked]>
Date: 11 Aug 2004 07:59:13 -0700

> possibility of making outbound TCP queries for large number of incoming

  More importantly, it calls into question why you'd want to
  use DNS in the first place. The nice aspect of DNS is that
  you have exactly one round trip with UDP. At the point
  that you have to truncate a response and refetch the
  entire RR set using TCP (assuming that you don't tickle
  the TCP bug John refers to), you might as well have used
  DNS to do an A or SRV lookup and used some _other_ tcp
  service that's assumedly more appropriate and/or purpose
  built for this application.

  So keeping the likelihood of < MTU size on the RR set
  seems like it out to be a _requirement_ since this wg is
  chartered to use DNS, and thus be DNS friendly. If it
  comes down to a tradeoff with wildcards, we'll just have
  to decide which is friendlier... but transport unfriendly
  DNS seems like a pretty bad option.
-- 
Michael Thomas	([email-masked] http://www.mtcc.com/~mike/)

---

From: Rand Wacker <[email-masked]>
Date: Wed, 11 Aug 2004 08:42:40 -0700 (PDT)

> go directly under the domain and so will future dns specific record type.

This was during the -protocol discussion when Mark was up on the
blocks.  Excerpt from the meeting minutes that Andrew just posted:

---
A long discussion on DNS issues was then undertaken by the room.
Participants discussed the issues of using new DNS record types instead of
TXT record types, the usage of prefixes to avoid conflicts, and the
utility of wildcards.  Many participants expressed concern with codifying
the use of TXT records.  Mark noted the definition of a new DNS record
type and the eventual transition to it.  Other participants related their
experiences with SRV records and the inability to use them.  Many in the
room asked that deployment considerations be given equal consideration to
architectural considerations and suggested that few were truly happy with
the use of TXT records but many understood the importance of the
compromise.  After much discussion about wildcards, the sense of the room
was that they are not as practical as they appear to be.
---

-Rand

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 11 Aug 2004 18:27:46 +0200

> Me too, as in I'm trying to imagine which API they used and why?

The berkeley APIs permit this bug easily. This is very off-charter, but 
if the chair asks I suppose it's okay ;)

Suppose you're reading a packet-based format. Usually the packets are 
something like (type, length, content). (DNS Is slightly different, but 
that doesn't matter right now.)

The protocol parser is supposed to first read the type and length, and 
then 'length' bytes of content.

With the berkeley API, that involves two read() calls. Or maybe just 
one, if you optimize a little. So, first you call select() or poll() to 
be told about the arrival of the data, then read() twice to read them.

If the read() that reads the content returns a short read (that is, the 
program asks for 'length' bytes, the OS returns something less, such as 
1500), then the program _should_ not parse yet, but instead call 
select()/poll() and read() again.

The bug happens when the developers never see a short read and forget to 
handle that case. Short reads don't happen very often often on the 
100Mbps LANs used by most developers.

(I've seen this bug in three products in the past ten years.)

Arnt

---

From: George Mitchell <[email-masked]>
Date: Wed, 11 Aug 2004 10:01:35 -0700 (PDT)

At Tue, 10 Aug 2004 10:40:19 -0700, Ted Hardie <[email-masked]> wrote:
> fact.  [...]

Surely this is a distinction without a difference.  If you ask me,
"What checks do you want me to make on email which arrives with
MAIL FROM: [email-masked]?", and then you ask me "What checks do
you want me to make on email which arrives with a PRA of
[email-masked]?", would you be surprised if I answered
"... a mx -all" in both cases?  Perhaps there are cases in which
people want the checks to be different, but this will be the
exception (and I think a rare one) rather than the rule.  I
strongly agree with Meng that the problems associated with
changing the version string outweigh the possible theoretical
advantage.

-- George Mitchell

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Aug 2004 11:34:26 -0700

> changing the version string outweigh the possible theoretical

The difference and advantage of one scheme over the other is not
theoretical.  SPF allows the RFC 2822 From to differ from the RFC 2821
MAIL FROM.  This allowance enables provider customers to continue using
recognized return addresses seen within their messages.  SPF also checks
the MAIL FROM validity to help prevent a spoof bounce technique often
used by spammers to dodge repudiation checks.

Sender-ID places an onerous restriction on the mail sender with respect
to the use of their well-known mailbox address and Sender-ID does not
prevent the spoof bounce technique.  Nor does Sender-ID conserve network
bandwidth with rejected mail, as does SPF.  It would be irresponsible to
conclude acceptance of this restriction by those that have published SPF
records.  I suspect the principle motivation to publish SPF records was
to find relief from the spoof bounce techniques.
 
There have already been some on this list indicating a series of checks
be made, one for SPF (to enable the bounce protections) and then
Sender-ID to impose limits upon the RFC 2822 From address.  The logical
outcome will be inclusion of a Resent-From header by ISPs when forced
into using Sender-ID as a means to negate this expensive restriction.

A CSV check of the HELO/EHLO domain would provide a mail identifier
enhancement that can be used with an accreditation service and assist
enforcement policies.  Sender-ID can not be safely used with
accreditation checks nor does it identify how mail was introduced.

If there are already wildcard SPF records, and then adding wildcard
Sender-ID records will collide and may cause a response problem. 
Wildcard records granting "open" lists would likely be used as a spammer
exploit adding random sub-domains forcing a huge load on the DNS
server.  I recall other issues raised in opposition to the use of
wildcards.  It seems highly inappropriate for Microsoft to demand a
signed contract, and to usurp the function and meaning of SPF records.

This all seems to come under the topic why TXT records should not be
overloaded.  To be fair, this was a warning ignored by the WG at the
interim meeting.

-Doug

---

From: John Levine <[email-masked]>
Date: 12 Aug 2004 02:27:50 -0000

>covers foo.example.org, then it would automatically cover

That's quite true, but that loses the benefit of segregating the MARID
records in _marid.  Say you have three services, _marid, _able, and
_baker, each of which has its own TXT record.  In the absence of
wildcards, you'd put one record each under _marid.foo.example.com,
_able.foo,example.com, and _baker.foo.example.com.  

If you have wildcard subdomains, you'd like to put one record each at
_marid.*.example.com, _able.*,example.com, and _baker.*.example.com,
but you can't, since DNS wildcards don't work that way.  So what you
have to do is to put all three records at *.example.com so that
applications using any of the services get all three records and throw
away the ones they don't want.  The problem is that the DNS packet
includes all three records so its size is the sum of all the records.
If the records get big, blammo.  This is specifically an issue if there
are two versions of SPF records.

-- 
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711
[email-masked], Mayor, http://johnlevine.com, 
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 12 Aug 2004 06:47:49 +0200

John Levine wrote:

> Say you have three services, _marid, _able, and _baker, each
> of which has its own TXT record.

Tnx, now I got, *.example.com would be ambiguous.  But maybe
we could get around this problem with an additional "_below":

_marid.www.example.com exists => ready, use it for _marid
_baker.www.example.com exists => ready, use it for _baker

No _marid.foo.example.com => try _marid._below.example.com
No _baker.bar.example.com => try _baker._below.example.com

Quite expensive, but no more conflicts for different services.
Could that be a solution for the "don't abuse TXT fraction" ?

                         Bye, Frank

---

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

Am I the only one experiencing déjà vu? Haven't we been through all these 
discussions before, like right before and during interim WG meeting....

---

From: John Levine <[email-masked]>
Date: 12 Aug 2004 19:51:25 -0000

>Could that be a solution for the "don't abuse TXT fraction" ?

You're basicallly proposing a new DNS wildcard system.  That's not a
terrible idea (there's certainly been enough criticism of the existing
system), but it's a considerably larger scale change than any we've
suggested so far and MARID isn't the right place to propose it.  In
the past, people have proposed using zone cuts as a kind of faux
wildcards, which isn't a good idea either.

Keep in mind that if marid, able, and baker are each assigned their
own DNS record type, existing DNS wildcards work fine.  There is a
solution to this problem, just not one that overloads everything into
TXT records.  Too bad a large vendor that likes to make all of its
protocols extensible didn't realize that DNS is also extensible when
they wrote their DNS proxy code.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: "Scott Kitterman" <[email-masked]>
Date: Thu, 19 Aug 2004 12:32:03 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of william(at)elan.net
> Sent: Wednesday, August 11, 2004 5:59 AM
> To: IETF MARID WG
> Subject: Re: change of version string

> dns packet (because of multiple large txt records) as well.
Or perhaps we could say that mail receivers MAY use an v=spf1 records if no
SPF2 record is returned.  As I understand it, any query for a TXT record
will return all TXT records for the domain, so if the TXT version of SPF2 is
queried for, the v=spf1 record will be returned if it exists.

I understand that some are concerned with the difference between 2821
mail.from and 2822 PRA.  I've read all the drafts and as nearly as I can
tell, the mechanisms defined in my v=spf1 record will work perfectly well
for Sender-ID.

For those, like me, for whom the records would be the same, allowing for
backward use of the earler SPF records would simplify things considerably.
It would also allow for Sender-ID checks to be usefully evaluated much
sooner since a large body of v=spf1 records is already published.

For those who are concerned about the distinction, but want to use v=spf1,
if they publish an SPF2 record, then they can define that distinction.

The change I am proposing would be to Page 5 of The Sender-ID Record: Format
and Interpretation, draft-ietf-marid-protocol-02.

Change:

   A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup
   TXT record at the same time, or wait for negative answer.  SPF2 type
   SHOULD be used if available.

To:

   A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup
   TXT record at the same time, or wait for negative answer.  SPF2 type
   SHOULD be used if available.  If a v=spf1 record is returned from
   the TXT record lookup, it MAY be used if and only if no SPF2 (SPF2
   RR or SPF2 TXT) record is returned.

I believe that would make life simpler for many of us without undue
complication for others.

Scott Kitterman

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Aug 2004 12:54:00 -0700

On Thu, 2004-08-19 at 09:32, Scott Kitterman wrote:
> On Wed, 2004-08-11 at 5:59, william(at)elan.net wrote: 
>
> > Perhaps it would be usefull if we allow one type of SPF record to
> > reference (include, refer to) another type of SPF record, this would
> > eliminate duplication problems in case of long records and avoid
> > issues with large dns packet (because of multiple large txt records)
> > as well.
>

There should be a concern doing this.  Those that published v=spf1
records were intending this record to be applied to their RFC2821 MAIL
FROM mailbox.  This would allow _any_ RFC2822 mailbox to be used.  Those
publishing this record may have fully expected to retain this freedom,
which now you feel obliged not to respect out of expediency.

This lack of respect seems to extend to the use of SPF2, as the
identifier for Sender-ID.  Why not fully depart, instead of this half
measure which only seems to obfuscate the fact these algorithms and
mechanisms are entirely different.  Sender-ID is not even better in many
respects.

-Doug

---

From: "Scott Kitterman" <[email-masked]>
Date: Thu, 19 Aug 2004 16:17:19 -0400

> From: Douglas Otis
> Sent: Thursday, August 19, 2004 3:54 PM
> To: Scott Kitterman
> Cc: MARID
> Subject: RE: change of version string
>
Anyone who doesn't want their v=spf1 record used for Sender-ID checks can
publish an SPF2 record that says spf2.0/pra +all.  That's an effective
opt-out of Sender-ID.  While I agree that the records for SPF Classic and
Sender-ID may be different in some cases, I expect that will be the
exception.  For the bulk of cases, I believe that the same record can be
accurately parsed for both.  I definitely believe that to be the case for
mine.

Having one record where one record will do while still allowing for two
records where necessary will make life easier for domain owners trying to
support one or both efforts.  One could also, in theory, say that in the
absence of an v=spf1 record, use the SPF2 record if present.  Since there is
a significant fielded code base of v=spf1 parsers in use, I think that it
would make more sense to have Sender-ID parsers use either record when they
are deployed.

They key point is to make it easier for domain owners to publish.  Getting a
critical mass of domain owners with records is essential to escape the catch
22 of receivers not checking because no one publishes records and no one
publishing records because no one checks.  Since there is a significant base
of v=spf1 records published, we can gain a lot of momentum by leveraging off
of the SPF classic community.  Finally, they are generally technically aware
early adopters who can reasonably be expected to understand the impacts of
2821 versus 2822 checking and its effect on them.

As far as what you call it, I don't care.  I just use what's in the drafts.
Myself, I wouldn't make any arguements in favor of Sender-ID over classic
SPF, but Sender-ID is what's on the table, so that's what I'm trying to
address.

Scott Kitterman

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Aug 2004 13:57:50 -0700

On Thu, 2004-08-19 at 13:17, Scott Kitterman wrote:
> Douglas Otis wrote:
> > > Or perhaps we could say that mail receivers MAY use an v=spf1
> > > records if no SPF2 record is returned.  As I understand it, any
> > > query for a TXT record will return all TXT records for the domain,
> > > so if the TXT version of SPF2 is queried for, the v=spf1 record
> > > will be returned if it exists.
> > >
> > > I understand that some are concerned with the difference between
> > > 2821 mail.from and 2822 PRA.  I've read all the drafts and as
> > > nearly as I can tell, the mechanisms defined in my v=spf1 record
> > > will work perfectly well for Sender-ID.
> > >
> > > For those, like me, for whom the records would be the same,
> > > allowing for backward use of the earler SPF records would simplify
> > > things considerably. It would also allow for Sender-ID checks to
> > > be usefully evaluated much sooner since a large body of v=spf1
> > > records is already published.
> > >
> > > For those who are concerned about the distinction, but want to
> > > use v=spf1, if they publish an SPF2 record, then they can define
> > > that distinction.
> > >
> > > The change I am proposing would be to Page 5 of The Sender-ID
> > > Record: Format and Interpretation, draft-ietf-marid-protocol-02.
> > >
> > > Change:
> publish an SPF2 record that says spf2.0/pra +all. 

Why not wait for them to opt-in to Sender-ID?  You want mail rejected as
a result of this usurping of the record?  There may be many that feel
Sender-ID records of any kind are not safe, as they rely upon the
RFC2822 content, but there is no means for this content to be assured.
Blacklisting could make _any_ records for Sender-ID perilous. They may
have felt SPF was relatively safe, but feel Sender-ID is not.  You offer
no recourse as a result of this expediency taken.  They may have been
expecting to use differing access with this RFC2822 From address you
destroy without risking the publishing of Sender-ID records.

> That's an effective opt-out of Sender-ID.

That is asking for their DNS to be bombarded with Sender-ID spam
exploits.  That is also asking for their domain to be blacklisted.  Some
opt-out. :(

> While I agree that the records for SPF Classic and Sender-ID may be
> different in some cases, I expect that will be the exception.  For the
> bulk of cases, I believe that the same record can be accurately parsed
> for both.  I definitely believe that to be the case for mine.

That comparison is overlooking how these records are used.  Publishing
these records was agreeing to how this record was to be applied, and not
to just their content.

> would make more sense to have Sender-ID parsers use either record when they

This has happened because TXT records are being overloaded.  What
solution is there when the next version of records are to be published?

> 2821 versus 2822 checking and its effect on them.

This still does not provide a suitable option for saying "Leave me out
of Sender-ID!"

> Myself, I wouldn't make any arguments in favor of Sender-ID over classic

There are potentially serious downsides to Sender-ID and there should
not be any auto-magic opt-in.  Error on the side of caution. 

-Doug

---

From: "Scott Kitterman" <[email-masked]>
Date: Thu, 19 Aug 2004 17:57:34 -0400

> Sent: Thursday, August 19, 2004 4:58 PM
> To: Scott Kitterman
> Cc: MARID

Acutally, now that I think about it, spf2.0/pra ?all would be a much safer
opt out.  Shouldn't get blacklisted over that one any more than you would by
publishing nothing.

> these records was agreeing to how this record was to be applied, and not

I agree that v=spf1 publishers would have to look at Sender-ID and decide if
they wanted to avoid it.  I do think that it shouldn't be a major burden for
those savy enough to have already adopted SPF classic.

> solution is there when the next version of records are to be published?
For the next version of the record, the actual RR type ought to be
available.  One major advantage of using one record for both is to minimize
the load on TXT records.

> This still does not provide a suitable option for saying "Leave me out
Of course, being left out of both SPF and Sender-ID is trivial.  Continue to
not publish a record.  Yes, it does make it harder to get out of Sender-ID,
but not out of SPF.  I think that spf2.0/pra ?all would be close enough.

> not be any auto-magic opt-in.  Error on the side of caution.
Why not wait is twofold.  First, two help jump-start adoption of the MARID
solution (assuming it's Sender-ID) and the second is to simplify record
publishing for those of us who will continue with Classic SPF.

Most of the commentary I've seen on the list seems to favor a single record
for both.  There are some that are concerned with that.  Here's a way for
both groups to have their way.

Scott Kitterman

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 20 Aug 2004 19:07:40 +0200

Scott Kitterman wrote:

> publish an SPF2 record that says spf2.0/pra +all.  That's an
> effective opt-out of Sender-ID.
............^^^^^^^
v=spf1 means MAIL FROM only, and nothing else, no united PRA -
SUBMITTER - Caller-Id - Domain Key stuff.  There's no need to
"opt out" from something when you never opted-in before.

If you want to "opt-in" to these schemes you're free to try it.
Maybe it works for you, I doubt it, and I'm sure that PRA won't
work for me.

> we can gain a lot of momentum by leveraging off of the SPF
> classic community

Deliberately misinterpreting sender policies would be abuse.
Wayne's idea "spf2/pra,spf" vs. "spf2/spf" is better, only the
latter is compatible with v=spf1.

                          Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Aug 2004 11:37:38 -0700

On Thu, 2004-08-19 at 14:57, Scott Kitterman wrote:
> > > Anyone who doesn't want their v=spf1 record used for Sender-ID
> > > checks can publish an SPF2 record that says spf2.0/pra +all.
> >
> > Why not wait for them to opt-in to Sender-ID?  You want mail
> > rejected as a result of this usurping of the record?  There may be
> > many that feel Sender-ID records of any kind are not safe, as they
> > rely upon the RFC2822 content, but there is no means for this
> > content to be assured. Blacklisting could make _any_ records for
> > Sender-ID perilous. They may have felt SPF was relatively safe, but
> > feel Sender-ID is not.  You offer no recourse as a result of this
> > expediency taken.  They may have been expecting to use differing
> > access with this RFC2822 From address you destroy without risking
> > the publishing of Sender-ID records.
> >
> > exploits.  That is also asking for their domain to be blacklisted.
> > Some opt-out. :(
> 
> Actually, now that I think about it, spf2.0/pra ?all would be a much
> safer opt out.  Shouldn't get blacklisted over that one any more than
> you would by publishing nothing.

If there is a filtering advantage for referencing a Sender-ID record,
even an '?' "open" record, then this type of record becomes a means for
spam exploits.  This also puts the DNS server at risk of being
overloaded.  Regardless of the scenario, publishing an "open" record of
_any_ type is not without risk.  It could also lead to this Sender-ID
domain becoming blacklisted, if this record is abused.  An "open" record
can easily be abused.  Such "open" lists should be struck as offering an
irresponsible option, once repudiation is considered being done either
through rejection or filtering.  Filtering is much more insidious. :(

> > > While I agree that the records for SPF Classic and Sender-ID may
> > > be different in some cases, I expect that will be the exception.
> > > For the bulk of cases, I believe that the same record can be
> > > accurately parsed for both.  I definitely believe that to be the
> > > case for mine.
> >
> > That comparison is overlooking how these records are used.
> > Publishing these records was agreeing to how this record was to be
> > applied, and not to just their content.
> 
> I agree that v=spf1 publishers would have to look at Sender-ID and
> decide if they wanted to avoid it.  I do think that it shouldn't be a
> major burden for those savy enough to have already adopted SPF
> classic.

The burden can not be avoided, when a Sender-ID record must be published
as a means to exclude the SPF record being assumed valid for Sender-ID.
If a message is relayed to the recipient, then it could become promoted,
likely by means of a Resent-From header, that will soon become
ubiquitous at relays, as a result of Sender-ID.  Some may then adopt a
evaluation strategy that attempts to deduce the original PRA identity
for assessing repudiations, as this method falls completely apart.

> > > Having one record where one record will do while still allowing
> > > for two records where necessary will make life easier for domain
> > > owners trying to support one or both efforts.  One could also, in
> > > theory, say that in the absence of an v=spf1 record, use the SPF2
> > > record if present. Since there is a significant fielded code base
> > > of v=spf1 parsers in use, I think that it would make more sense to
> > > have Sender-ID parsers use either record when they are deployed.
> >
> available.  One major advantage of using one record for both is to
> minimize the load on TXT records.

This two record types for a set of information is bad.  Already there is
a high level of DNS traffic for this scheme, and now this requires two
record paths be checked.  Will the record sets always match?  Could be a
means to confuse checking schemes that do not check both records?

> > > They key point is to make it easier for domain owners to
> > > publish.  Getting a critical mass of domain owners with records is
> > > essential to escape the catch 22 of receivers not checking because
> > > no one publishes records and no one publishing records because no
> > > one checks.  Since there is a significant base of v=spf1 records
> > > published, we can gain a lot of momentum by leveraging off of the
> > > SPF classic community.  Finally, they are generally technically
> > > aware early adopters who can reasonably be expected to understand
> > > the impacts of 2821 versus 2822 checking and its effect on them.
> >
> Of course, being left out of both SPF and Sender-ID is trivial. 
> Continue to not publish a record.  Yes, it does make it harder to get
> out of Sender-ID, but not out of SPF.  I think that spf2.0/pra ?all
> would be close enough.

This is not the same as no record.  This is saying, "Anyone and
everyone, use this record if you wish to claim my domain in your mailbox
address as having Sender-ID '?' status."  This could be worse than no
record, as it implies acceptance of this "open" Sender-ID record status.

> > > As far as what you call it, I don't care.  I just use what's in
> > > the drafts.  Myself, I wouldn't make any arguments in favor of
> > > Sender-ID over classic SPF, but Sender-ID is what's on the table,
> > > so that's what I'm trying to address.
> >
> Why not wait is twofold.  First, two help jump-start adoption of the
> MARID solution (assuming it's Sender-ID) and the second is to simplify
> record publishing for those of us who will continue with Classic SPF.

There should not be any need to "jump start" a scheme that proves
effective deterring abuse.  As Sender-ID does not provide an effective
or safe means for abating abuse, this is more likely the reason for
adding a grandfather clause that seeks to ignore intent of the record. 
This linked DNS record scheme seems well aimed destroying both DNS and
mail.  A dedicated server could offer much shorter responses than crazy
lists of DNS records.  Part of a philosophy, "Break it, and you bought
it?"  What is the next proprietary scheme for mail and DNS?

> Most of the commentary I've seen on the list seems to favor a single
> record for both.  There are some that are concerned with that.  Here's
> a way for both groups to have their way.

This is still overloading records.  Sender-ID will assume ownership of
TXT, regardless of wording in the standard.  This is a problem already
burdened with potentially hundreds of DNS record lookups. :(

-Doug

---

From: "Scott Kitterman" <[email-masked]>
Date: Fri, 20 Aug 2004 15:08:41 -0400

> Sent: Friday, August 20, 2004 2:38 PM
> To: Scott Kitterman
> Cc: MARID

> record, as it implies acceptance of this "open" Sender-ID record status.
Upon reflection, I think that Wayne's proposal is better.  It meets my goal
of only having to publish one record without the downsides that you point
out here.  Being able to only publish one record (what I proposed) would be
great.  Being able to publish one record the describes what scope it is
intended for is better.  It will take a little longer since the currently
deployed SPF parsers will have to be upgraded to read the new record type,
but I suspect the advantages are worth it.

Scott Kitterman

---

From: Roy Badami <[email-masked]>
Date: Sat, 21 Aug 2004 04:05:55 +0100

>>>>> "Frank" == Frank Ellermann <[email-masked]> writes:

    Frank> ............^^^^^^^ v=spf1 means MAIL FROM only, and
    Frank> nothing else, 

Actually, v=spf1 means a mandatory check on MAIL FROM, a mandatory
check on HELO when MAIL FROM doesn't contain a domain (which generally
boils down to just the MAIL FROM:<> case for all but the most liberal
recipients) and an optional check on HELO in other circumstances.

I would be quite keen on future work to allow MAIL FROM checks within
Sender ID (though now is the time to ensure that the versioning system
allows that in a clean way, not the time to spec that work).

I'm less convinced that merging HELO checks into Sender ID is the
right way to go.  But now is not the time to discuss that, either (and
as CSV is a WG work item which adresses the HELO identity, we can have
that discussion once Sender ID is out the door).

     -roy