Subject: Re: Differences between CSV and Sender-ID

From: Dave Crocker <[email-masked]>
Date: Thu, 1 Jul 2004 21:08:53 +0800

Andrew,

N>     Is it clear to you that CSV has definite security advantages over
AN> SPF/Sender-ID?

1. Which specification are you referring to, for the latter? The
current candidates for names that folks from the SPF camp have been
using are SPF, Unified SPF, SPF Classic and Sender ID. I might have
missed one. In any event, none of those names appear as any working
group document and no one from the SPF camp has yet made a definitive
declaration of what specific document is being used for comparison
with CSV. When this is remedied, it will be possible to answer
substantive questions such as the one you asked here.

2. You do not ask about any operations (adoption, deployment,
administration) differences, nor about performance (efficiency,
scaling, etc.) differences. Nor do you ask about differences in impact
on the email infrastructure. I hope these, too, are considered
relevant.

AN> I'm only asking these questions so that we can hopefully refine the
AN> conversation on this topic.

At the moment, stability of reference would be even better than
refinement.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: "Olson, Margaret" <[email-masked]>
Date: Thu, 01 Jul 2004 09:54:29 -0400

> From: Dave Crocker <[email-masked]>
> 

I want to echo and reinforce this observation - I also no longer know what
"SPF" means. I understand SenderID as the combination of the marid-core and
marid-submitter proposals. I think I know what SPF classic is, but I am no
longer sure since it appears that there are proposals to interpret spf v1
records in a variety of ways beyond the current definitions.

This has caused me to ponder the wisdom of publishing SPF records.

Margaret.

---

From: wayne <[email-masked]>
Date: Thu, 01 Jul 2004 09:54:34 -0500

In <[email-masked]> Dave Crocker <[email-masked]> writes:

> group document

The SPF proposal was submitted quite a while ago, I have no idea where
it went to.  The Sender-ID proposal is the same as the "marid-core"
proposal. 

I can understand the confuse here.  Most of the problem is due to the
idea merging of SPF and Caller-ID before a name for the merged spec
was thought up.

Anyway, here is the run down:

SPF/SPF-classic

This is the original SPF spec and has been around for quite a while.
The spec was supposed to have been submitted (along with DMP, FSV, LMAP
and RMX(?)) and wase once found on the MARID charter webpage as input
documents.  It can be found at
http://www.ietf.org/internet-drafts/draft-mengwong-spf-01.txt

The "SPF-classic" is a play on the "New Coke"/"Coke Classic" thing,
since the merged SPF/C-ID proposal was first tagged with the "New SPF"
name.  

merged SPF and Caller-ID/New-SPF/SPF-ID/Sender-ID/MARID-core

This was the spec announced at the interim meeting.  See:
http://www.ietf.org/internet-drafts/draft-ietf-marid-core-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-rationale-00.txt

Unified-SPF

This doesn't have an I-D yet and is a fairly new proposal.  The idea
is outlined/discussed at http://spf.pobox.com/slides/unified%20spf/

Basically, it acknowledges that SPF-classic checks the 2821.FROM and
optionally the 2821.HELO and Sender-ID checks the
2822.From:/Sender:/etc.  Since proposals based on the SPF syntax and
semantics have already been used to cover most of the identities, it
is thought that will a few tweaks, the same system can cover basically
all the identities so far discussed.

Actually, the idea of using SPF records to cover many identities has
long been a goal by many of the SPF crowd and gets raised by various
people who don't realize that it has been suggested before.  The
Unified-SPF proposal is really just the natural evolution of SPF.

**** Score card of terms for this mailing list  ****

When reading this mailing list, it appears to be very uniform that
references to "SPF-classic" mean the original SPF proposal, as
outlined in the I-D mentioned above.  Almost all of the references to
"SPF" appear to be references to the same thing.

References to the term Sender-ID appear to uniformly mean the
marid-core/submitter proposal.

References to the term Unified-SPF appear to uniformly mean the
Unified-SPF proposal.

-wayne

---

From: Dave Crocker <[email-masked]>
Date: Fri, 2 Jul 2004 12:38:37 +0800

Greg,

GC> A HELO check can catch some really obvious bad cases (like spam or viruses
GC> using the receiver's own name) and some obvious good cases (like people we
GC> want to whitelist).

With respect to CSV, I think this needs to be phrased quite
differently, even though the semantics will probably seem similar, or
at least not contradictory. The reason for this need is that I think it
leads to a very different perspective on the implications of a CSV
mechanism versus an SPF-like mechanism.

HELO makes an assertion about the operation and accountability of the
MTA. There is quite a bit of history and current use of services that
vet sending SMTP clients and their network operators.

A HELO mechanism check can be used to produce a domain-name based
codification of such checking, rather than requiring that white/black
lists be maintained in terms of IP Addresses. The benefit of having a
domain name base involves all of the reasons we all like domain names
better than IP Addresses, for use by humans.

GC> CSV also uses HELO to tie a reputation to the sending MTA.

The concern about accreditation (of which "reputation" is a subset) is
rather interesting, here. What folks seem to be missing is that ALL
mechanisms that involve acceptance or rejection based on a name or
address has an accreditation component. Accreditation is, in fact, the
acceptance or rejection policy engine.

CSV merely specifies two external standards for such a mechanism.

So, yes, a mechanism that only seeks to detect forgeries does not have
an accreditation mechanism.  But forgive me if I am wrong:  I thought
folks were interested in detecting and preventing spam, and spam is
very, very much about accreditation, not forgery.

Forgery is a current symptom, rather than a core aspect of spam and
virus sending.  Eliminate forgery and there will still be masses of
spam and virus sending.

I had rather hoped we were trying to get at core issues nof fighting
spam, what with the scale of the problem and the cost and delay
inherent in any standards effort.

GC>  This seems to
GC> be based on the assumption that good mail comes from good MTAs, and bad
GC> mail comes from bad MTAs, which some have suggested is not well-supported.

"Some have suggested" is language that applies to any interesting
topic, for every possible point of view on the topic. Hence, it does
not carry any useful information. (Yeah, I am saying that a bit
sharply. It is a pet-peeve of mine about so-called news reporting and
I really hope the content-free utterance does not seep into serious
technical discussions.)

To move this particular point into something that might be productive,
please refer to the thread "who are we accrediting?" and note John
Levine's posting.  I'll post a response to it.

GC> I think checking the HELO *alone* is not an adequate solution to the
GC> problem set.

I agree.  RFC2822 author/sender based accreditation is also going to
be needed.  The nature and form of that accreditation is a different
question.

GC> If the main thing we want out of MARID is to stop people forging mail

I do not have access to the working group charter as I write this, but
I sure hope that forgery is not the primary concern of the working
group.

Otherwise, there is a rather large community of email users and
providers who are going to rather upset that we spent all this time
and did nothing that is intended to reduce spam.

On the other hand, I could see how "DNS-based MTA authentication" could
cause one to think that forgery is the focus.

GC> apparently-from and bouncing-to our own domains, a MAILFROM/PRA check is
GC> going to be required.

Some sort of rfc2822 author/sender accredition is going to be
required... in some cases.

GC> Mechanically, CSV and SPF are both capable of checking HELO.

Mechanically, CSV and SPF are both fruit. But let me tell you, you do
not want to think about or use durian the same way you think about and
use oranges.

However, your statement highlights a deeper problem in most of the
efforts to discuss CSV and SPF differences:  Such efforts are almost
entirely tied to mechanical and syntactic issues and do not focus on
underlying concepts.

CSV and SPF are fundamentally different pardigms.

    CSV vets an MTA's traffic.

    SPF vets an RFC2822 author/sender's message.

They are orthogonal informational-theoretic areas of consideration.

Where the confusion comes in, of course, is that SPF involves the MTA,
albeit through an indirection.

Let's try for some concise descriptions of the two paradigms:

SPF:

    Per-message MTA path validation, based on Author/Sender
    authorization and accreditations.

CSV:

    MTA traffic validation, based on MTA operator authorization and
    accreditation.

SPF vets an MTA's sending a single message.  It accredits the MTA
based on the RFC2822 author/sender.  While introducing a
path-dependency into the mechanism, it simply defers the hard
question, namely accrediting the author/sender.

CSV vets an entire MTA session.  It accredits the MTA based on the
operator of that MTA.

Current whitelist and blacklist services focus on the MTA network, ie,
the operator of the MTA.  So CSV provides a standardizing mechanism
for existing practise.

The limitations of that practise are demonstrated every day, but so
are the benefits.

GC>  - If the MTA name is also used as a HELO name for one of the MTAs

I do not understand what that means.  What is an "MTA name", other
than the string it puts into the HELO parameter?

GC>       - In most cases the existing SPF record should be sufficient, since
GC> it probably includes that MTA.

My guess is that you are talking about the narrow case in which the
RFC2822 author/sender has the same domain name as the MTA HELO.  While
a popular scenario, it is a long way from being the ONLY popular
scenario.  And that's the problem. SPF is problematic for a number of
other such popular scenarios.

GC> Semantically, there is some difference in the understanding between what
GC> the CSV check means, and what the SPF+HELO check means.

It is rather more than "some".

GC> It would be better to use ?include:comcast.net or ?ptr:comcast.net. That
GC> way the mail from those domains is still allowed, but not "guaranteed" to
GC> be from you.

This begs for an obvious question: What is the benefit to the
anti-spam world of something which offers no guarantees? Is that not
the same as saying "I enforce no anti-spam policies, since anyone can
claim to be part of my domain"? No accountability is a rather serious
deficiency.

GC> If the result comes back unknown, you can't attach reputation
GC> or whitelisting to that transaction, you just have to proceed in "legacy"
GC> mode.

And the value-add of SPF, in this scenario is what, exactly?

What does the administrator of the domain and/or the operator of the
receiving SMTP client get for their effort?

GC> If people are really worried about others forging their name in HELO

CSV's anti-forgery component is not it's focus.  Its focus is upon
accrediting MTAs.

Authentication is merely a necessary step along the path to assess
accreditation.

>>Is it clear to you that CSV has definite security advantages
>> over SPF/Sender-ID?

GC> There is general agreement that the smaller problem
GC> of HELO checking

"smaller problem"?

I hope you do not mean that identifying spam spigots is a small
problem or that doing it will be a small benefit.

That is one of the things CSV is useful for, that SPF is not.  Entire
networks of compromised machines can be blocked with a single
accreditation entry, no matter what the domain names they use for their rfc2822
author/sender.

GC> CSV may have a better security story, but I believe this is a direct result
GC> of deciding to include fewer features and less flexibility.

Methinks there is a lesson in protocol design, here.

GC> Regarding DDOS concerns, I think they can be solved by placing some limits
GC> on the amount of recursion possible and the total number of queries needed
GC> per mail message, and that should satisfy most concerns.

Offhand, I am not sure what you mean and I am certain I do not
understand how it pertains to protection against DDOS attacks.

GC> I think there is enough consensus in the group that we need to protect PRA
GC> and/or MAIL FROM,

There is agreement that we need a mechanism that identifies and
accredits rfc2822 author/sender IN SOME CASES.

GC> and that HELO is of secondary importance.

I'm not sure whether you noticed, but there is a rather different tone
in the comments about HELO checking now than there was a month or so
ago.

GC>   Not everyone
GC> agrees with this, but I think a majority of folks think that HELO checking

I am confused.  Were the chairs asking each of us to perform a rough
consensus assessment of the working group?

GC>   So, if we are going forward with PRA/SenderID or
GC> something like it, it should be easy enough to adapt it to HELO checking as
GC> well.

I'm sure we all look forward to the specification that satisfies your
expectation.

d/

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 2 Jul 2004 03:20:52 -0400

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: "Greg Connor" <[email-masked]>
Cc: "IETF MARID WG" <[email-masked]>
Sent: Friday, July 02, 2004 12:38 AM
Subject: Re: Differences between CSV and Sender-ID

> in the comments about HELO checking now than there was a month or so

Actually,  what I notice is a difference in your own tone.  First, last
year,  you "pulled a fast one" by having everyone, including the ASRG,
focused on SMTP compatibility.

http://www.brandenburg.com/specifications/draft-crocker-spam-techconsider-02.txt

To paraphrase:  "Remember Compatibility, Incremental changes is the key
folks."

Many, including myself were talking about the necessary for changed,
including the key interest to focus of SMTP compliancy, including HELO for
over a year now.

But ever since SPF has forced the issue with MARID, you have been every
active and provided new work focusing on what many already knew.

Now you want us to change our servers in drastic ways!

I'm sorry for own tone (blame it a few jacks, ok four), but I don't
appreciate the lack of common courtesy to respond to my atleast 1 of my
inputs or comments to your CVS specification. I listened to your concerns
about the WG tangents. I spent quality time reviewing all the 3 docs (39
pages) and serious considering for implementation.  Not one response from
you. NADA!   If my comments "do not apply" or "bother you,"   I would only
know with FEEDBACK and then I won't have to be wasting more time.

Oh well,  you are going to ignore this also anyway, so never mind.

Thanks

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Greg Connor <[email-masked]>
Date: Fri, 02 Jul 2004 03:35:40 -0700

Hi Dave,

I'm not exactly pleased to see my post carved up, with a number of 1-3 line 
responses added for every 1-3 lines I wrote.  I feel it is a style that 
encourages fighting, bickering, and disagreement rather than mutual 
understanding and consensus-building.  However, I don't believe at all that 
you meant to be rude or anything.  Perhaps you interpreted my message as an 
attack against CSV and reacted defensively?

Anyway, you raise some good points here, so I will attempt to reply as 
concisely as I can.  It's going to appear disjointed but I will try not to 
break things up too much further than they already are.

--Dave Crocker <[email-masked]> wrote:

>
> Greg,
>
>
> GC> A HELO check can catch some really obvious bad cases (like spam or
> viruses GC> using the receiver's own name) and some obvious good cases
> (like people we GC> want to whitelist).
>

Without commenting on mechanisms, I totally agree with your explanation of 
HELO and its significance.  I was attempting to keep it a bit simple for 
the readers.  The two paragraphs above are a good explanation as to why 
HELO is significant, and why checking it (by whatever mechanism) is 
desirable.  All is well.

> inherent in any standards effort.

My statement wasn't meant as a negative.  I actually agree with what you 
said here.  CSV hangs reputation/accreditation on HELO, SPF chooses to hang 
it on another identity.  I certainly didn't mean to imply that 
accreditation is not important.

> GC>  This seems to
> GC> be based on the assumption that good mail comes from good MTAs, and
> bad GC> mail comes from bad MTAs, which some have suggested is not
> well-supported.
>

In the part you quoted, I was trying to point out one area of disagreement, 
without actually taking sides (I explained my own opinion after the "My 
opinion" tag), so my apologies for the vagueness.

So, to be clear, I am suggesting that this assumption is not valid or 
useful.  I think the reputation of the MTA is often interesting, but 
certainly not enough in itself to judge the quality of the mail.  But, 
after reading your message I am starting to think that you don't believe 
this assumption either, that there are only "good" and "bad" MTAs.  In that 
case, this disagreement is not directed at you, but at other CSV supporters 
(Matthew and Doug) who have been suggesting that checking HELO against a 
reputation is pretty much all you need and other proposals that check other 
identities are worthless, doomed to failure, or both.

> be needed.  The nature and form of that accreditation is a different

Right...  that's what I was trying to say too :)

> cause one to think that forgery is the focus.

Wow, we're interrupting mid-sentence now, I see :)  I won't spend much time 
on this one other than to say:
  1. I want to stop spam too, and I think stopping forgery is a necessary 
but sufficient step..
  2. I honestly believed that stopping forgery was the point of the WG and 
that stuff that stops spam by other means than stopping forgery would be 
ruled out of scope, and
  3. It looks like you agreed with the important part of my sentence anyway 
:)

> GC> apparently-from and bouncing-to our own domains, a MAILFROM/PRA check
> is GC> going to be required.
>

Agreed :)

> entirely tied to mechanical and syntactic issues and do not focus on

Right...  That actuall IS what I mean here -- I mean to separate the 
mechanics of each proposal from the underlying concepts.  The assertion I 
was trying to test is whether the mechanism SPF uses to test PRA, MAIL FROM 
and HELO is capable of doing the same things the CSV mechanism does.

If it cannot for strictly *mechanical* reasons, I would like to understand 
what they are.  So far the answer whenever I ask this is "Well, you COULD 
use SPF TXT records instead of SRV records, but why would you want to?"  If 
it's possible to present an end user with one tool that has two 
applications, that might be a worthwhile goal.  Speaking only of the 
*mechanism* I don't see that SRV records have an inherent advantage over 
TXT records, or that the underlying concepts of CSV depend on SRV records.

> CSV vets an entire MTA session.  It accredits the MTA based on the

I don't really agree that CSV and SPF are fundamentally different 
paradigms.  They are different, but I don't think fundamentally so, and I 
don't think either of them represents a "paradigm" really.

I think of SPF not as a great idea, but as a collection of great ideas. 
Some of these are:
 - A mechanism that maps (domain name, IP) onto (pass, fail, unknown)
 - Application of this mechanism to MAIL FROM, to vet a message path (or 
partial path, when forwarders use SRS)
 - Application of this mechanism to PRA, to vet a message path (or partial 
path, when forwarders use recommended headers)
 - Accreditation can be applied to the domain of any ID that returns pass 
result.
 - An ID that returns fail result should be treated as highly suspect and 
probably rejects.  An ID that returns unknown result should not be used to 
judge a mail as good or bad and the receiver should fall back to other 
methods.

CSV is also made of multiple great ideas, such as:
 - A mechanism that maps (domain name, IP) onto (allowed, disallowed, 
no_info)
 - Application of this mechanism to HELO, to vet an MTA
 - Accreditation can be applied to the MTA based on its name, if result is 
allowed.
 - An IP address specifically disallowed from using the name claimed in 
HELO should be treated as MTA-not-grata
 - An MTA that has no info CSV may check should be rated on other means 
(e.g. IP) or not at all.

The point of this exercise is to separate the "mechanism" carrying the 
message from the content and meaning of the message itself.  The SRV record 
mechanism is clever, but I got the feeling from reading CSV documents and 
speaking to you and other CSV supporters that it is not the main important 
thing that CSV does.

By suggesting that the mechanisms *could be* compatible, I don't mean to 
imply that the two types of checks already mean the same thing.  They 
don't.  SPF has a couple of modes where it checks HELO, but it lacks an 
explanation as to why one might want to do that, what the information 
means, and how to interpret it and act on it.

Why am I so keen to show that one mechanism could be used for both checks? 
Well, one of the first things that this WG worked on was deciding which 
identities to check.  My understand was, at the time, that there was a 
pretty strong consensus that we should work on both 2821 and 2822 
identities, and I *thought* we had also decided that if we tackle one 
identity first, we would do so in such a way that the other identities 
could be checked with the same or similar mechanism.

> The limitations of that practise are demonstrated every day, but so

That is an excellent point, and I agree.

> GC>       - In most cases the existing SPF record should be sufficient,
> since GC> it probably includes that MTA.
>

You are correct, that should have been "sender domain name" not MTA name.

I agree, this is definitely not the majority case.  I mention it here 
because it is really the only case where the SAME name may be used by both 
email addresses and HELO.  If the same name might be used by an MTA and by 
the RHS of an email address, I think chances are very good that the allowed 
IPs for both cases will be the same.

Again, this hearkens back to the discussion of which identities we want to 
be able to validate.  At the time, we identified HELO, MAIL FROM and 
From:/Sender:, and along with the idea that perhaps all three merit 
checking, we brought up the cases where the same domain name might be used 
in different contexts.  Each context might have wildly different meaning 
and usage, but where the NAME is exactly the same, the set of authorized 
IPs would usually be the same or a blend of the two usage sets would be 
suitable.  If I remember correctly, not everyone was convinced at the time 
that a single set of IPs would always work, so there was some discussion of 
a "scope tag" of sorts, but I think most of the group agreed at the time 
that the need for this would be rare.

> GC> Semantically, there is some difference in the understanding between
> what GC> the CSV check means, and what the SPF+HELO check means.
>

Agreed.  But if the implication is that they are different enough to 
*require* different mechanisms, I would not agree with that.

Let me say this again because I think it is important:
THE IDEA OF USING ONE MECHANISM TO VALIDATE DIFFERENT IDENTITIES IS NOT NEW.

As I continue to suggest that CSV *could* be implemented using SPF TXT 
records, people continue to look at me as if I'm speaking heresy.  All I 
can say is, please review the archives.  This same WG agreed that multiple 
identities are worthy of checking, and if possible they should be checked 
in the same or similar ways.  Did I misunderstand, or have we changed 
directions on this, or has everyone just forgotten what we talked about for 
the first month or more?

> GC> It would be better to use ?include:comcast.net or ?ptr:comcast.net.
> That GC> way the mail from those domains is still allowed, but not
> "guaranteed" to GC> be from you.
>

To quote Douglas Adams, "We demand rigidly defined areas of doubt and 
uncertainty!" :)

Seriously though, the "unknown" state was put in there for a reason.  In an 
ideal world, all my users would phone home and submit with SMTP AUTH and 
all our mail would go out the pre-defined block of IPs.  But, some domain 
owners might want partial coverage, and might need some usage cases to be 
supported in "legacy mode" for a while.  If a domain owner is not 100% sure 
he has rounded up all the roaming users, he may choose to write ?all at the 
end - in which case forgeries would not be stopped, but the +entries in the 
list can still be used to invoke reputation and whitelisting.  If all the 
roaming users happen to be on comcast.net, a record with ?ptr:comcast.net 
-all is much better than ?all -- possibly enough to make spammers/forgers 
move on to the next target.

In other words, the "unknown" state is a feature, not a bug.  If you don't 
agree, fine, don't use the feature.  Your characterization of this mode as 
a "deficiency" is uncharitable and seems to contain a high FUD to fact 
ratio.

If you had not taken the sentence out of context, my original intent would 
be a bit clearer -- I was actually responding to some other FUD based on a 
wrong understanding of SPF (or intentional misreading or other straw man). 
The example given by Doug and Matt both was "Well what about a domain that 
publishes include:comcast.net?  That means anyone on comcast.net could HELO 
as my own name!"  Yes, and this would be a mistake on the part of the 
domain owner; they are in effect saying "We trust comcast.net to not forge 
mail from us or otherwise use our name improperly."

> GC> or whitelisting to that transaction, you just have to proceed in
> "legacy" GC> mode.
>

See above regarding FUD.

I will note also that despite disparagement pointed at the "unknown" mode 
of SPF, CSV also has a de-facto "unknown" mode - you can just choose not to 
publish any records at all for that particular name.  I would assume that 
reputation would not attach in this case either.

> accreditation entry, no matter what the domain names they use for their
> rfc2822 author/sender.

Actually I was not referring to my own opinion as "general agreement" -- I 
was referring to the decisions of this WG as to which identities should be 
checked.  I believe it was agreed that 2821.MAIL FROM was most important, 
followed by 2822.From/Sender, and 2821.HELO was the least important of the 
three.

I DO agree though; identifying spam spigots is a big problem, and doing it 
is a big benefit.  You have made a good case for HELO checking.  I'm not 
suggesting that HELO checking shouldn't be done, and you're not suggesting 
that it's a total solution in itself that trumps others.  We may not be on 
the same page but I think it's in the same book :)

> GC> CSV may have a better security story, but I believe this is a direct
> result GC> of deciding to include fewer features and less flexibility.
>
> GC> Regarding DDOS concerns, I think they can be solved by placing some
> limits GC> on the amount of recursion possible and the total number of
> queries needed GC> per mail message, and that should satisfy most
> concerns.
>

Sorry, I didn't mean "[all] DDOS attacks" -- this was a specific reply to a 
specific concern in SPF.

I don't know why Matt and Doug chose to say over and over again how nasty 
and yucky and vulnerable SPF is, citing this as a reason why CSV is cool 
and wanted and necessary.  I don't think SPF and CSV are mutually exclusive 
and I don't think the "air of competition" serves any of us well.  I think 
CSV contains great ideas and so does SenderID.

> GC> I think there is enough consensus in the group that we need to
> protect PRA GC> and/or MAIL FROM,
>

No comment at this time, Senator. :)

> in the comments about HELO checking now than there was a month or so

I noticed.  CSV has done a lot to bring HELO into the spotlight.  This is a 
good thing.  As long as CSV isn't trying to elbow other proposals out of 
the way, I don't have a problem with it.

In fact, Unified SPF is based pretty strongly on my efforts to get HELO 
placed more prominently on SPF's radar screen.  I have gone from not taking 
HELO seriously to actively preaching the gospel of HELO to spf-discuss and 
#spf on IRC.

I don't think HELO has eclipsed PRA/MAIL FROM/SUBMITTER in importance or 
utility.

> consensus assessment of the working group?

I was referring again to the rough consensus reached at our first-phase 
milestone.  I believe it was agreed that 2821.MAIL FROM was most important, 
followed by 2822.From/Sender, and 2821.HELO was the least important of the 
three.  Perhaps I misremember, but that's what I thought we said.

> GC> something like it, it should be easy enough to adapt it to HELO
> checking as GC> well.
>

Being worked on.  I think you will be pleased.  As I said before, if 
Unified SPF borrows some ideas from CSV, please consider that a form of 
flattery :)

--
Greg Connor <[email-masked]>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 2 Jul 2004 22:45:50 +0800

Greg,

GC> I'm not exactly pleased to see my post carved up, with a number of 1-3 line
GC> responses added for every 1-3 lines I wrote.  I feel it is a style that
GC> encourages fighting, bickering, and disagreement rather than mutual
GC> understanding and consensus-building.

It is a well-established style, designed to cite precisely the text
being responded to, in the style of a dialogue, and without carrying
unnecessary baggage from the quoted message. It presumes that folks
have access to the original, so it need not worry about the 'flow' of
the message. In this case, I felt that responding to the details of
your note was appropriate.

GC> So, to be clear, I am suggesting that this assumption is not valid or
GC> useful.  I think the reputation of the MTA is often interesting, but
GC> certainly not enough in itself to judge the quality of the mail.

You might want to discuss that view with the substantial fraction of
the anti-spam listing services that do not share your view.

GC>  But,
GC> after reading your message I am starting to think that you don't believe
GC> this assumption either, that there are only "good" and "bad" MTAs.

Discussion will probably be more productive if we refrain from
guessing each other's beliefs.

GC>   In that
GC> case, this disagreement is not directed at you, but at other CSV supporters
GC> (Matthew and Doug) who have been suggesting that checking HELO against a
GC> reputation is pretty much all you need

None of the CSV folk have made any statement like that.

GC>  and other proposals that check other
GC> identities are worthless, doomed to failure, or both.

None of the CSV folks have made any statement like that.

GC>   1. I want to stop spam too, and I think stopping forgery is a necessary
GC> but sufficient step.

That has not been the typical view of SPF proponents.  Nor does it
have any objective, analytical basis.

Spam does not require forging.  Forging is simply a convenient hack,
so it is used... for now.  Spammers have shown an impressive degree of
adaptability.  Take away one convenient hack and they find others.

>> required... in some cases.
GC> Agreed :)

I hope you, and everyone else, understand that I said something
significantly different from what you said.

>> entirely tied to mechanical and syntactic issues and do not focus on

GC> Right...  That actuall IS what I mean here -- I mean to separate the
GC> mechanics of each proposal from the underlying concepts.  The assertion I
GC> was trying to test is whether the mechanism SPF uses to test PRA, MAIL FROM
GC> and HELO is capable of doing the same things the CSV mechanism does.

Marshall Rose recently published an article about helicopers and
submarines in an ACM periodical.  If there is an online citation to
it, I suggest you take a look at the point it makes.

GC>  Speaking only of the
GC> *mechanism* I don't see that SRV records have an inherent advantage over
GC> TXT records, or that the underlying concepts of CSV depend on SRV records.

I think Douglas has been doing quite a good job of speaking to that
point.  A careful review of his postings on that matter might be
helpful.

>> CSV vets an entire MTA session.  It accredits the MTA based on the
GC> I don't really agree that CSV and SPF are fundamentally different
GC> paradigms.

Do you disagree with any of the summaries about the two that I list,
above?

If you do, then please explain.

GC> I think of SPF not as a great idea, but as a collection of great ideas.

Actually, what you then proceeded to describe was a bunch of
mechanisms.

What I am rather pointedly trying to do is conduct a discussion based
on the concepts and information-theorectic aspects of the two services.

GC> The point of this exercise is to separate the "mechanism" carrying the
GC> message from the content and meaning of the message itself.

That might be *your* goal, but *mine* is to make sure we all are in
synch about the differences in the NATURE of the two services, before
haggling over the details of the mechanisms.

GC> I will note also that despite disparagement pointed at the "unknown" mode
GC> of SPF, CSV also has a de-facto "unknown" mode - you can just choose not to
GC> publish any records at all for that particular name.

There is a significant difference in cost between doing no work,
versus doing a bunch of administrative configuration and networking
querying and analysis of the responses, only to produce an unknown.

GC> I don't know why Matt and Doug chose to say over and over again how nasty
GC> and yucky and vulnerable SPF is,

Perhaps because they have some relevant operations experience with
complex configurations and the deliterious effects of functional
interactions for complex mechanisms.

GC> citing this as a reason why CSV is cool
GC> and wanted and necessary.

Actually, I read their notes as saying two separate things.  One is
about the spiffiness of CSV.  The other is criticism of SPF.

d/

---

From: wayne <[email-masked]>
Date: Fri, 02 Jul 2004 23:42:49 -0500

>     SPF vets an RFC2822 author/sender's message.

Dave:

You appear to be confusing SPF with Sender-ID.  SPF vets the 2821.FROM
and the 2821.HELO.  Sender-ID and Caller-ID vet the
2822.From:/Sender:/etc.

I posted the following messages as a direct reply to address your
confusion: 
http://www.imc.org/ietf-mxcomp/mail-archive/msg02494.html

Your continued confusing of Sender-ID with SPF is as bad as if people
confused your earlier proposals of DSAR/HNAA with CSV.  Worse, it
appears that your confusing is creating problems for others.

Now, since SPF-classic (see link above) doesn't have anything to do
with the 2822 information and *does* validate the HELO domain, most of
your message is, at best, irrelevant.

Granted, SPF-classic's validation of the HELO domain has not been
cited as a key feature of SPF, so this confusion is a little more
understandable.  I did address it in this recent message:
http://www.imc.org/ietf-mxcomp/mail-archive/msg02508.html

-wayne

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 3 Jul 2004 03:15:53 -0400

----- Original Message ----- 
From: "wayne" <[email-masked]>
To: "IETF MARID WG" <[email-masked]>
Sent: Saturday, July 03, 2004 12:42 AM
Subject: Re: Differences between CSV and Sender-ID

> http://www.imc.org/ietf-mxcomp/mail-archive/msg02508.html

I think you might be underestimating what SPF can do here to match the basic
concept in CVS with one simple change.  :-)

It starts with this assertion:

    SPF HELO lookups results can only result in NONE, PASS or FAIL.
    It is not logical to have a SOFTFAIL or NEUTRAL. without breaking
    the "chain of trust" concept.

Add this and you have the key fundamental premise of CSV - persistent
domains.

If you need me to explain this, I will.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 03 Jul 2004 03:28:11 -0700

> appears that your confusing is creating problems for others.

I think much of this confusion comes from continuing reference to SPF+
which has yet to be defined.  As such, there is no clear definition yet
as to what SPF _currently_ checks, so your distinctions are only
somewhat accurate, if at all.  I agree that looking at the historical
documents of what SPF _had_ been checking and what Sender-ID _is_
checking is different, but as Sender-ID _is_ the current incarnation of
SPF, why are you making this distinction?  Are you suggesting a desire
to abandon Sender-ID?  This is confusing.

> your message is, at best, irrelevant.

Here you are confused.  The checking of the HELO domain by SPF-Classic
does not provide the same results as obtained by CSV.  Looking at the
inputs and outputs alone fails to consider the _completely_ different
dataset involved.  There was wisdom in Sender-ID dropping this
meaningless HELO check made by SPF-Classic.  This continues to confuse
many others as well. 

> http://www.imc.org/ietf-mxcomp/mail-archive/msg02508.html

The goal of CSV is to establish a _single_ accountable entity for the
mail stream.  the SPF-classic occasional validation of the HELO domain
was only to see if _any_ entity was accountable.  Even if this check is
made every time, it still remains an entirely different (and
meaningless) check.  The goal of SPF/Sender-ID was to flag some concept
of "from" as having been confirmed.  The HELO domain provides a very
nebulous reference for such confirmation, and thus the wisdom excluding
this check.  Reinstating this check would only continue this original
muddle.  CSV is, was, and remains entirely orthogonal to SPF/Sender-ID.

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 03 Jul 2004 09:12:11 -0400

Dave Crocker <[email-masked]> wrote:
> so it is used... for now.

  FYI, I have been in discussions with large financial 1institutions,
who see forgery as a serious problem.  Tracking down and/or stopping
forged spam is a high priority for them, and will save them large
amounts of money.  They don't see forgery as a "convenient hack" for
spammers, they see it as a direct and purposeful attack on their
business.

>  Spammers have shown an impressive degree of adaptability.  Take
> away one convenient hack and they find others.

  The locks on my doors stop certain kinds of criminals.  I know that
they don't stop determined criminals, but I still use the locks.  The
locks stop the casual thieves, and more than pay for themselves.

  I know that there will probably always be spam, and that it's
impossible to get rid of *all* of it.  But calling a direct attack on
someones name a "convenient hack" belittles other peoples problems and
their attempts to deal with those problems.

  Spammers forge peoples names to gain false association with an
established positive reputation, or to move the negative side-effects
of spam onto third parties.  Stopping forgery will have a direct
positive effect on the reputation and administration costs of innocent
bystanders.

  Alan DeKok.

---

From: wayne <[email-masked]>
Date: Sat, 03 Jul 2004 08:47:55 -0500

In <[email-masked]> Douglas Otis <[email-masked]> writes:

> which has yet to be defined.

Your message is the only reference to "SPF+" I can find on this
mailing list.  Since you have apparently created the term "SPF+",
please go ahead and define it.

>                               As such, there is no clear definition yet
> SPF, why are you making this distinction?

Sender-ID is not SPF.  That is why Sender-ID has a different name than
SPF.

There are no protocal police.  There is nothing anyone can do to force
people to use or not use either SPF or Sender-ID.  There is certainly
a large and growing number of people who continue to use SPF.  There
are also people who almost certainly start using Sender-ID once stable
specs published (e.g. ones without XML requirements, etc.)

As such, your reference to SPF in the past tense has no basis in
reality.  Similarly, your reference to people using Sender-ID in the
present tense has no basis in reality.

>                                            Are you suggesting a desire

I have made no such suggestion that I want to abandon Sender-ID.  If
the PRA algorithm works as well as claimed, I will add it to my SPF
library and have it support both SPF and Sender-ID.

> Here you are confused.  [discussion of CSV vs SPF snipped]

I have more to comment on this, but I'm afraid I'm already 5 minutes
late leaving to pick up my kids, so I'll have to post it tonight.

-wayne

---

From: wayne <[email-masked]>
Date: Sun, 04 Jul 2004 01:14:03 -0500

> late leaving to pick up my kids, so I'll have to post it tonight.

fyi;

I wrote to Doug offlist because I realized that Andy and Marshall have
requested that CSV discussions on the MARID list should be minimized.
If anyone is interested in my reply, contact Doug or me.  I don't
consider the email private, just not in-scope for this list.

-wayne

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 Jul 2004 14:15:57 +0700

Alan,

>> so it is used... for now.
AD>   FYI, I have been in discussions with large financial 1institutions,
AD> who see forgery as a serious problem.

I did not say that forgery is not a problem.

I said that it is not essential to spamming.

Get rid of forging and you will not reduce spamming at all.

In any event, the forgery protection that financial institutions
require is considerably stronger than the anti-spam forgery protection
schemes being considered in this working group.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 Jul 2004 14:11:47 +0700

Folks,

(what follows does distinguish between Doug's comments and the ones he
was responding to, just in case anyone wonders...)

>> http://www.imc.org/ietf-mxcomp/mail-archive/msg02494.html

DO> I think much of this confusion comes from continuing reference to SPF+
DO> which has yet to be defined.

My assessment was based on draft-ietf-marid-core.  I don't care what
acronym is used.

I was fairly careful in the statement that is quoted at the beginning
of this message, because it applies to all of the *SPF* and *-id
proposals as they have been described.

>> your message is, at best, irrelevant.

SPF Classic has/had everything in the world to do with RFC2822
information, because it is the RFC2822.Sender that sets the
RFC2821.MailFrom header.

DO>   The checking of the HELO domain by SPF-Classic
DO> does not provide the same results as obtained by CSV.  Looking at the
DO> inputs and outputs alone fails to consider the _completely_ different
DO> dataset involved.

right.

DO> The goal of CSV is to establish a _single_ accountable entity for the
DO> mail stream.  the SPF-classic occasional validation of the HELO domain
DO> was only to see if _any_ entity was accountable.

this is a rather interesting point that I had not previously
appreciated.  thanks!

d/

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 05 Jul 2004 14:41:19 -0400

> I said that it is not essential to spamming.

  It is essential to a particular class of spam, as I mentioned in my
previous message.  I was trying to explain why broad statements about
forgery and spam could be construed as belittling something that, for
many, is a serious problem.

> Get rid of forging and you will not reduce spamming at all.

  I've been saying that on ASRG for about a year.  This isn't news.

  Prevention of forgeries will, however, reduce the impact of spam on
innocent third parties.

  RBL's stop spam from one IP, but the spammer can just move, and spam
again.  Does this mean that RBL's are useless?  Of course not.
Similarly, MARID won't stop spam, but that doesn't mean it's
addressing a trivial problem.  I don't see weekly statements on
anti-spam lists saying "RBL's won't stop spam", but I do see such
statements about MARID.  I don't know why, and I just don't get it.

> schemes being considered in this working group.

  As I've been saying, MARID is a start, but not the end solution to
spam.

  My comments were not intended to re-hash old issues.  Rather, they
were intended to point out that what for you seems like a "convenient
hack" is for others, including myself, a direct and personal attack on
our systems and reputation.

  I'm not trying to belittle your position.  Rather, I'm trying to
ensure that you don't belittle mine.

  Alan DeKok.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 06 Jul 2004 10:53:32 -0400

On 7/5/2004 2:41 PM, Alan DeKok wrote:
> previous message.

There are a lot of tools that only stop spam on an incidental basis, but
are really only useful because of that incidental benefit. Think RFC2821
syntax checks, greylisting, callback systems, etc., all of which are
designed to probe implementation weaknesses instead of "block spam", but
which happen to achieve that goal anyway. MARID would be the similar.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 7 Jul 2004 15:54:08 +0700

Eric,

>>   It is essential to a particular class of spam...
EAH> There are a lot of tools that only stop spam on an incidental basis, but
EAH> are really only useful because of that incidental benefit. Think RFC2821
EAH> syntax checks, greylisting, callback systems, etc., all of which are
EAH> designed to probe implementation weaknesses instead of "block spam", but
EAH> which happen to achieve that goal anyway. MARID would be the similar.

There is an important difference between local algorithms that have
transient utility against a problem, versus global standards that have
no enduring benefit.

The difference is adoption cost in terms of time and effort, notably
when it requires global cooperation.

Perhaps you know of a global standard that was/is designed for
targeting such a narrow bit of behavior and has been beneficial, but I
don't.

Especially when removing the targetted behavior will do nothing to
reduce the core problem.  That is, none of this will reduce spam.

As I say, the Internet community is going to be a bit disappointed
that we spent this much time and effort and did nothing to reduce
spam.

d/

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Jul 2004 14:17:28 -0400

> reduce the core problem.  That is, none of this will reduce spam.

I don't think the results have to be binary for them to be useful,
especially if the benefits are only sold as incidental.

"Spammers will move to other domains" is a reasonable long-term viewpoint
but on the other hand the spammers aren't that smart in the short-term,
and there is some question about their intelligence over longer views as
well. I mean, I still get plenty of dumbasses using localhost as their
HELO identifier (rejected immediately) which everybody knows is easy to
block and easy for spammers to adapt around (but they still do it), or
using non-existent domains in their envelope sender addresses, or ...

Lots of things that work well today are "easy to get around by doing X
instead of Z", and yet the spammers keep on doing Z anyway.

---

From: wayne <[email-masked]>
Date: Wed, 07 Jul 2004 15:39:10 -0500

> Get rid of forging and you will not reduce spamming at all.

I have no idea how you could prove a statement like this true or
false.

I've heard it said that DNSBLs have not reduced spamming at all and
that if it wasn't for DNSBLs email would be unusable today.  Barring
the creation of alternate universes where DNSBLs didn't exist, no one
will really know if either of these claims is true.

Certainly spam, like other forms of theft, will never completely go
away.  Spam, like other forms of theft, requires many different tools,
including defensive measures, identification/accreditation, and legal
actions.  

Nothing proposed on this WG is going to stop spam.  I find it amusing
that Alan and Dave are discussing such issues and Alan hasn't even
pointed out that even doing ICMP port unreachable responses to SMTP
connections won't stop spammers.  See: http://www.striker.ottawa.on.ca/

If even as an immediate and absolute response as an ICMP port
unreachable won't stop spammers from attempting to send spam to
striker, such things as SPF, Sender-ID, CSV, MTAmark, etc. don't have
a chance.

-wayne

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 07 Jul 2004 17:37:45 -0400

wayne <[email-masked]> wrote:
> Nothing proposed on this WG is going to stop spam.

  No one is claiming it will.  Anyone claiming that MARID will stop
spam should be educated as to how it works.

>  I find it amusing that Alan and Dave are discussing such issues and
> Alan hasn't even pointed out that even doing ICMP port unreachable
> responses to SMTP connections won't stop spammers.  See:
> http://www.striker.ottawa.on.ca/

  I have never claimed that ICMP port unreachables would stop
spammers, so I don't see why you're bringing it up, or how it's
relevant to MARID.  See the ASRG archives, where multiple people
re-establish a dormant domain after 3 years, and instantly receive
spam.  Spammers are sending to everyone, always, whether or not anyone
is listening.

  And the problem behind the situation on my page about ICMP port
unreachables is *not* about spam, believe it or not.  It's about theft
of services.  The spammers were "owning" someone's machine, and they
therefore didn't care what the cost of spam was, as those costs were
borne by the administrators of the "owned" machine.  No SMTP-based
anti-spam solution can prevent these situations.

  Let me repeat that, in case I was unclear: Some spam is sent through
otherwise legitimate "owned" MTA's, and nothing we do in SMTP, or to
SMTP, will have ANY effect on that kind of spam (except turning off
SMTP for that MTA).  The ONLY solution to such theft is a combination
of legal & non-SMTP technical approaches.

> striker, such things as SPF, Sender-ID, CSV, MTAmark, etc. don't have

  I don't care about people sending spam to striker, as I have other
methods to deal with that.  I care about people forging mail FROM
striker, as it's difficult for me to deal with those messages via
local configuration or policy.

  I'm now starting to see spam forged FROM people I exchange email
with, TO me.  This says to me that spammers are not only forging
messages, they're trolling list archives for pairs of addresses which
will probably make it through content filters.  Forgery prevention
systems are therefore even more relevant.

  If this thread continues, please continue it only on ASRG.  It's
getting off-topic for MARID.

  Alan DeKok.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Jul 2004 07:25:31 +0700

Eric,

EAH> but on the other hand the spammers aren't that smart in the short-term,

spammers have proved to be smart, adaptable and quick. the current
methods of spam-sending represent highly sophisticated, large-scale
distributed systems.

nothing has yet reduced the amount or impact of global spam.  in fact,
spam has only gotten monotonically worse.

so we probably should be reticent to build a global standard that
assumes the spammers will be slow-witted and slow-responding.

d/

---

From: wayne <[email-masked]>
Date: Wed, 07 Jul 2004 20:29:26 -0500

> spam should be educated as to how it works.

Alan:

I think we are actually in violent agreement on these issues.

While I can't recall anyone claiming that any MARID/LMAP proposal
would stop spam, I have seen several comments about how not stopping
spam is somehow a major flaw.

While I think that many of the MARID/LMAP proposals will both reduce
the rate of growth of spam and increase the costs for spammers, those
aren't my main goal here.  I hope to help stop forgery, (slightly)
increase the accountability email, reduce the mount of bogus
bounces/C-Rs/"virus" warnings, and make whitelisting far more useful.

-wayne

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Jul 2004 22:13:54 -0400

On 7/7/2004 8:25 PM, Dave Crocker wrote:

> spammers have proved to be smart, adaptable and quick.

Older spammers who are savvy enough to compete maybe, but not the new
and/or stupid ones.

Anyway, the empirical evidence shows that old filtering tools continue
being useful, which is in direct contradiction to the essence of your
opinion. Who am I going to believe, you or my lying logfiles?

> assumes the spammers will be slow-witted and slow-responding.

The words I used were 'incidental benefit'.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Jul 2004 09:37:59 +0700

Eric,

>> spammers have proved to be smart, adaptable and quick.
EAH> Older spammers who are savvy enough to compete maybe, but not the new
EAH> and/or stupid ones.

Eric, your model of current, common spam-sending operations is
apparently wildly different from the one I have been getting from
senior, dedicated spam-chasers.

EAH> Anyway, the empirical evidence shows that old filtering tools continue

you continue to use experience with local, isolated mechanisms to
somehow justify an approach to global, interoperable standards.  I
don't understand that.

d/

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Jul 2004 22:41:13 -0400

> somehow justify an approach to global, interoperable standards.  I

Nor can you understand the meaning of 'incidental benefit' apparently

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 7 Jul 2004 23:21:24 -0400

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 07, 2004 8:25 PM
Subject: Re: Forging (was Re: Differences between CSV and Sender-ID )

> spammers have proved to be smart, adaptable and quick.

The only evidence of adaption has been at 2822 and the hackers (the smarter
ones of the abuse crowd) finally realizing they can exploit some aspects of
2821 - SORBIG!

The industry really started screaming when SORBIG started to exploit
everything about SMTP using a dual distribution concept.

That is when I finally got involved - no more or less a reason.  The payload
is the responsibility of the sysop or any post smtp operation.  Although
there was adapation by spammers, sysops had somewhat of a handle of this
with the post smtp mail filters tools.  But when it wasn't spam but viruses
and bounces were being forced - POOF!  - Major problem.

If you close 2821 -  minimize payload acceptance,  you drastically reduce
the effectiveness of any spammer adaptation at 2822.  Its a non-issue
basically.

MARID must be give more power to 2821.

This is why I have kept repeating,  any MARID logic that requires PAYLOAD to
be used will suffer the consequences, not only in the 2822 adaptation but in
increasing payload bandwidth as well.

I should also note this is a network wide consideration, not just a local,
isolated experience.  All my customers are benefiting from the more SMTP
enforcement concepts and DNS reductions efficiency ideas used for our SMTP
server.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 8 Jul 2004 05:25:59 +0200

> senior, dedicated spam-chasers.

Some spammers are smart, and are disproportionally visible to 
spamfighters. Others - many others - are not.

Arnt

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 7 Jul 2004 23:49:41 -0400

----- Original Message ----- 
From: "Hector Santos" <[email-masked]>
To: "Dave Crocker" <[email-masked]>; "Eric A. Hall"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 07, 2004 11:21 PM
Subject: Re: Forging (was Re: Differences between CSV and Sender-ID )

>> Eric Said:

>> Dave Said:

> Hector Said:

I would like to add or state I have seen no adaption as of yet at 2821.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Jul 2004 07:25:31 +0700

Eric,

d/