Subject: (DEPLOY) In Support of Sender ID

From: "J. Trevor Hughes" <[email-masked]>
Date: Thu, 2 Sep 2004 14:13:13 -0400

I write as the executive director of the Email Service Provider Coalition
(ESPC).  The ESPC is a trade association made up of 54 email service
providers.  We estimate that our members provide delivery services to over
250,000 senders in the US alone.  And according to Ironport's SenderBase,
our members deliver approximately 12% of all email.

Both in a personal capacity and as a trade association, I write today to
express strong support for Sender ID.  The ESPC has been advocating for
authenticated email solutions for almost two years and feel that this is a
critical first step toward more comprehensive solutions to the spam problem.
Last year, the ESPC published a white paper on our vision for authenticated
email (Project Lumos, authored by Hans Peter Brondmo and Margaret Olson).

Within our organization, we have had three corporate attorneys from member
companies review the Microsoft license (I too am an attorney, although not
trained or licensed in patent law).  Resoundingly, we have found that the
issues raised within MARID are addressable, or at worst understandable,
given the context of situation.  I personally believe that Microsoft is
acting in good faith and in a rational manner and has moved forward with
patent protections as a defensive response to very real risks.  (See
http://www.groklaw.net/article.php?story=20040901004705872 for a decent
discussion on the reasoning behind a defensive patent claim on an otherwise
"free" license.)

Based on our review, the license terms have been deemed acceptable.  The
fact that pending patent claims are present is nothing new to the IETF.
Many RFCs have gone forward with IPR claims.  The issue should then distill
to whether the license presented is consistent with IETF standards.  I
believe that Microsoft has complied with, and indeed exceeded, the
standards.  The IETF has been notified of the IPR claims and royalty-free,
non-discriminatory license terms have been offered.  What more is required?

Much has been made of the fact that the pending patent content has not been
disclosed.  While this may be disconcerting to some, it represents a
balanced strategy to protect against predatory claims downstream.  A patent
application is the first time that a company exposes proprietary
information.  Any attorney representing a corporation would counsel against
disclosure of the patent at this stage in the process.  Suggestions that
this inappropriate (particularly from attorneys) fail to recognize the risks
associated with disclosure of the patent content.

Even more has been said about the sub-licensing of Sender ID.  While I do
acknowledge the concerns of many on this list, we feel that the friction
caused by sub-licensing is a worthwhile quid pro quo for the greater value
of broad implementation of an authenticated email solution.  Again, any
attorney acting as counsel for a corporation would seek such terms.  They
are neither surprising, nor objectionable.

I do want to raise one issue that has not been discussed on MARID yet (at
least as far as I have seen).  The eyes of the world are upon industry at
this time and great expectations have been created for authenticated email
technologies to emerge quickly and broadly.  The Federal Trade Commission
recently issued a report to Congress and strongly advocated for
authenticated email solutions.  They will be holding a workshop on the topic
later this fall.  Failure to move forward with Sender ID at this juncture
will likely put us back at least 6 months and perhaps more.  Such a delay
will only invite interference from legislators and regulators.  I certainly
do not think that is in the best interests on anyone!

Finally, I want to share a dystopian vision of how things may play out if we
fail to move Sender ID forward.  Multiple IP-based authentication mechanisms
will be a disaster for email.  We run the risk of balkanized ISP solutions -
and the ensuing demands of multiple protocols on all senders.  Not a good
result coming out of an effort to create a standard!

I urge the participants on this list to consider the greater good that will
be borne from the wide adoption of Sender ID.  This is a good tool.  The
actions of the various parties involved are understandable and reasonable.
The license terms are workable and within the scope of IETF standards and
history.  And it will have a positive effect on our ability to reduce
phishing and protect legitimate email.

J. Trevor Hughes

Executive Director

NAI

207 351 1500 (o)

207 351 1501 (f)

 <mailto:[email-masked]> [email-masked]

---

From: Kevin Peuhkurinen <[email-masked]>
Date: Thu, 02 Sep 2004 14:57:13 -0400

J. Trevor Hughes wrote:

> Even more has been said about the sub-licensing of Sender ID. While I 
> do acknowledge the concerns of many on this list, we feel that the 
> friction caused by sub-licensing is a worthwhile quid pro quo for the 
> greater value of broad implementation of an authenticated email 
> solution. Again, any attorney acting as counsel for a corporation 
> would seek such terms. They are neither surprising, nor objectionable.
>

They may not be surprising, but they are objectionable to a significant 
portion of the people who would be developing and implementing MARID.

> I do want to raise one issue that has not been discussed on MARID yet 
> (at least as far as I have seen). The eyes of the world are upon 
> industry at this time and great expectations have been created for 
> authenticated email technologies to emerge quickly and broadly. The 
> Federal Trade Commission recently issued a report to Congress and 
> strongly advocated for authenticated email solutions. They will be 
> holding a workshop on the topic later this fall. Failure to move 
> forward with Sender ID at this juncture will likely put us back at 
> least 6 months and perhaps more. Such a delay will only invite 
> interference from legislators and regulators. I certainly do not think 
> that is in the best interests on anyone!
>
Not true. SPF is more mature than Sender-ID.

> Finally, I want to share a dystopian vision of how things may play out 
> if we fail to move Sender ID forward. Multiple IP-based authentication 
> mechanisms will be a disaster for email. We run the risk of balkanized 
> ISP solutions – and the ensuing demands of multiple protocols on all 
> senders. Not a good result coming out of an effort to create a standard!
>

This is the most troubling issue that I forsee, I agree. However, I have 
to wonder why everyone who is pro-Sender-ID doesn't feel it necessary to 
try to pressure Microsoft into adopting SPF instead. To my mind, there 
are ZERO hinderences to Microsoft adopting SPF, but there are plenty of 
hinderences for most everyone else to adopt the encumbered Sender-ID.

> I urge the participants on this list to consider the greater good that 
> will be borne from the wide adoption of Sender ID. This is a good 
> tool. The actions of the various parties involved are understandable 
> and reasonable. The license terms are workable and within the scope of 
> IETF standards and history. And it will have a positive effect on our 
> ability to reduce phishing and protect legitimate email.
>

And I urge Microsoft to consider the greater good and drop their 
licensing requirements or else adopt SPF instead.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 02 Sep 2004 15:08:32 -0400

J. Trevor Hughes wrote:
> Many RFCs have gone forward with IPR claims.  The issue should then 
> distill to whether the license presented is consistent with IETF 
> standards.  I believe that Microsoft has complied with, and indeed 
> exceeded, the standards.  The IETF has been notified of the IPR claims 
> and royalty-free, non-discriminatory license terms have been offered.  
> What more is required?
> 
>  

You are making a mistake. The main question the IETF considers in 
regards to the IPR is not "whether the license presented is consistent 
with IETF standards". It is rather described in section 5.3 of RFC 3669:
"  The issue is not whether a particular piece of
    technology is IPR-impacted -- we use IPR-impacted technology every
    minute.  The question is how much the IPR protection will limit the
    technology's usefulness in building a robust, highly useful Internet.
"

In this specific case, even though Microsoft may have satisfied the 
letter of the law so to speak, that might not be good enough. If the IPR 
protection will hinder deployment that "will limit the technology's 
usefulness". That is the main question and unfortunatly, the licensing 
as it stands now presents a significant deployment barrier to a sizable 
portion of the Internet community.

I urge you to reread RFCs 2026, 3667, 3668 and 3669.

> solution.  Again, any attorney acting as counsel for a corporation would 
> seek such terms.  They are neither surprising, nor objectionable.
> 

If it hinders deployment, it is a problem even if it is "neither 
surprising, nor objectionable". I think that is the point that is hard 
to hammer through here - this is not a regular standard, and it requires 
much more committment and different handling, than anything any 
corporate lawyers have done before.

> forward with Sender ID at this juncture will likely put us back at least 
> 6 months and perhaps more.  Such a delay will only invite interference 
> from legislators and regulators.  I certainly do not think that is in 
> the best interests on anyone!
> 

At this point its a catch-22. Not approving the standard will cause 
problem. But you should also take into account that *approving* it will 
cause problems as well. Deployment of this standard will not happen 
until both the commercial and FOSS sides have been satisfied. As much as 
some of us may hate it, but this is one area where the commercial world 
and the FOSS *must* work together.

Approval of the standard on the MARID WG level means nothing. The final 
approval rests with the IESG and that will still take time.  Any kind of 
approval or lack of therefore, will cause further friction among the 
parties, including possible appeals to the IESG and IAB.

It might come hard to believe to the commercial world, but the role FOSS 
software plays in the Internet architechture is larger than any other 
area today. Majority of the architechture is built on FOSS such as BIND, 
Apache, sendmail, etc. You cannot simply ignore it and hope it will go 
away. Both commercial and FOSS sides *must* be willing to negotiate on 
this issue, and work on this together. Otherwise, even if this standard 
is approved, and not deployed, it would be useless. And then the 
senators will jump in anyway.

Yakov

---

From: Chuck Mead <[email-masked]>
Date: Thu, 02 Sep 2004 15:14:03 -0400

J. Trevor Hughes wrote:
<snip>
| I urge the participants on this list to consider the greater good that
will
| be borne from the wide adoption of Sender ID.
<snip>

Speaking *for* (in whatever capacity I may do so) the OSS community
members participating in this process I acknowledge everything you have
said and I agree with it, except for this part. My reasoning is
fundamental but IMHO if there are impediments at the licensing level
which affect Sender ID's adoption in open source software then when will
we see this "wide adoption" that you speak of? Thus far the clear answer
to that question is never. The redistribution issues caused by the
license are the direct root cause of this situation.

I am given to understand by communications from many sources that a
great deal of work is going on quietly, behind the scenes, trying to
work out this issue and I commend Microsoft for their willingness to
discuss them... that said we aren't there yet and I do not see how you
can believe that Sender-ID will be *widely adopted* given the current
license situation. What is the current installed base of the major
pieces of mail related open sourse software? I don't know and I dare say
that no one truly does but I *DO* believe that it would be more than
fair to say that the base is huge and represents a vast majority on
today's internet.

With regard to your position quoted above I remain wholly unconvinced
and would prefer that this body adopt SPF-Classic if the license terms
remain unchanged. It does what we need and it is unencumbered with IPR
issues so far as anybody knows! For my own part I have already
implemented SPF-Classic in production and have been running it for
months with nothing but positive effects.

- --
[email-masked], head geek
http://moongroup.com

---

From: Rand Wacker <[email-masked]>
Date: Thu, 2 Sep 2004 12:51:15 -0700 (PDT)

> hinderences for most everyone else to adopt the encumbered Sender-ID.

^Microsoft^the Internet at large

SPF and Sender ID solve different problems.  Sender ID authenticates the
message, SPF authenticates the channel.  While channel authentication is
useful for some purposes, message-based authentication of something the
end-user can see is much more desirable to many senders and recipients to
control spoofing of user-visible headers.

In that regards, the Sender ID technology presents the best IP-based
message authentication I have seen, and can provide an immediate benefit
to a large majority of message paths.  In the long run, a crypto-based
solution for message authentication is of course the best solution, and we
are all working on those as well.

When we start discussing channel authentication then we should compare SPF
and CSV, but SPF doesn't solve the immediate problems of header spoofing
that I want to address right now.

-Rand

---

From: <[email-masked]>
Date: Thu, 2 Sep 2004 16:28:46 -0400

> control spoofing of user-visible headers.

I agree that SPF and Sender ID solve slightly different problems, but
saying one authenticates the channel and the other the message is a
bit of a simplification.  (If anything, domain keys actually
authenticates the message.)

It's not any easier for the end-user to see one than the other.  In
one case, the MUA has to extract the envelope sender from the
SPF-Received header, in the other case, the MUA has to select one of
the From, Sender, Resent-From, or Resent-Sender headers to highlight. 
Patent claims aside, neither seems particularly hard to implement in
an MUA.  But that issue is somewhat irrelevant, because last I checked
the M in MARID stands for MTA and the charter says, "The primary
current use case for this facility is to allow recipient MTAs to
confirm that peer MTAs' actions are authorized by specific domains or
networks."  Sure, if the MTA can determine this, it can and should let
the end user know, but the main point here is not end users.

What I'd really like to hear about is an actual usage scenario in
which a message author (say a bank sending out statements) actually
requires Sender ID, and could not get the same effect with
SPF-classic.  Basically there are outsourcing scenarios where in
Sender ID you have to publish a TXT record in DNS, and with
SPF-classic you either have to publish a CNAME or a TXT and MX record.
 But so what?  The mechanisms are different, but the effects are the
same.

David

---

From: Ryan Ordway <[email-masked]>
Date: Thu, 02 Sep 2004 13:30:50 -0700

> > the best interests on anyone!

...

> senators will jump in anyway.

	Well said. I would also pose the question, what
percentage of the arguable majority of deployed SMTP
servers that run FOSS MTA software do so as a direct
result of said FOSS MTA being distributed with the
FOSS Operating System that they run on (some form of
GNU/Linux, *BSD, etc.)? 

	In the US it's an election year and I'm sure
that there are legislators on both sides of the aisle
that would love to add "Spam Slayer" to their political
resumes. You can rest assured that there will be
interference from legislators irregardless of SenderID's
being adopted or not. It might explain the apparent
hurry to push this standard, ANY standard, through
despite the IPR issues.

	Ryan

-- 
HELO, my name is root... you have SIGKILLed my father... prepare to vi!

---

From: Douglas Otis <[email-masked]>
Date: Thu, 02 Sep 2004 13:30:27 -0700

> that I want to address right now.

I have introduced the MPR draft to illustrate how to arrive at either
the SPF level of RFC2821 MAIL FROM as well as the RFC2822 From building
upon the CSV standard.  This also overcomes problems of the
indeterminate DNS overhead, replication of DNS addresses, "open" lists
creating spam exploits, and removes an ability to hide listing by way of
macros.  One fundamental difference is the treatment of reputation as a
separate function from that of mailbox domain to outbound server
association.

-Doug

---

From: Rand Wacker <[email-masked]>
Date: Thu, 2 Sep 2004 14:20:14 -0700 (PDT)

On Thu, 2 Sep 2004 [email-masked] wrote:

> SPF-classic.

I've talked to numerous large banks and consumer-oriented companies -- big
ones, the kind that run ads on TV -- and they've done the analysis on
their customer email address lists that a large majority (more than 50%)
go only one hop to large ISPs that don't allow forwarding, and to large
enterprises that discourage such.  So, for these sites, a majority of
their customers will be very well served by accurately authenticating the
From: address which is shown in their MUA *today*.  This is something that
SPF-classic can not provide today.

Another use case has to do with changes forwarders have to make so that
they don't create false positives.  The 2822 header additions required by
Sender ID are much less invasive than the 2821 MAIL FROM rewriting (SRS)
that SPF Classic requires, and the Sender ID changes do not change the
well understood and sometimes depended on MAIL FROM bounce address.

What still needs to be done is assess what types of paths either of these
solutions might break (I like that CSV doesn't have the potential to do
that).

-Rand

---

From: Sam Varshavchik <[email-masked]>
Date: Thu, 02 Sep 2004 18:44:58 -0400

Chuck Mead writes:

> license situation.

I don't know how actually willing is Microsoft, but I do know that many 
respected F/OSS community members have been trying to lobby behind the 
scenes, for which I commend them.

However, I am 100% certain that Microsoft will never accept F/OSS-compatible 
licensing terms, and the lobbying efforts will not succeed. I believe their 
only purpose is so that everyone can truthfully say that they tried their 
best.

Repeated calls on this mailing list for Microsoft to adopt F/OSS-compatible 
licensing terms will not do anything.  This is not going to happen.

---

From: <[email-masked]>
Date: Thu, 2 Sep 2004 19:05:00 -0400

> SPF-classic can not provide today.

Wait a sec... surely you don't claim that Sender ID can authenticate
anything with MUAs today.  I agree that in single-hop scenarios, mail
won't be rejected by Sender ID.  However, nothing stops forgery of the
From: header by viruses or spammers.  If I add a "Resent-Sender:
virus@com" header, today's MTAs are still going to display the
unauthentic "From: [email-masked]" header.

Anyway, are MUAs really within scope here, in a working group about
MTA authentication?

My challenge remains... describe a concrete scenario that requires
Sender ID, and that could not achieve the same effective result with
SPF-classic.  Vague references to banks don't convince me any more,
because I've thought through concrete scenarios, and in every case, if
you specify what needs to be sent to whom, and what the attacker is
trying to do, you'll see that SPF-classic is basically as powerful as
Sender ID.  Once you throw end users into the fray, you'll find that
in either case you need to make small modifications to the MUA, but
neither modification is particularly hard to do.

David

---

From: Michael Hammer <[email-masked]>
Date: Fri, 3 Sep 2004 08:43:11 -0400

I'm reluctant to join the fray as I find myself feeling caught in the
middle. Long time lurker, first time poster.

I speak for myself but work for a well known website which generates a
fair amount of outbound mail mainly from a web GUI interface which
customers interact with. Phishing is an issue for my employer and we
are clearly interested in solutions which work. We have changed our
mode of operation so that we could publish SPF1 records (by not
sending emails as if it was the user sending them). We also recognized
that other solutions such as CallerID and DomainKeys were on the
horizon.

The merging of CallerID and SPF into SenderID presented an opportunity
to provide a generally accepted solution to reduce forgeries for both
RFC2821 and RFC2822 headers. The issue of licenses does not directly
impact us with the most recent changes made by Microsoft as we would
simply be an end-user.

I recognize that there is significant controversy over the licensing
issue with many posters to this list indicating that they will not
implement SenderID given the current situation. Fragmented
implementation of standards (specified or de facto) by recipient MTAs
(I'm setting aside the issue of MUAs as it would take a longer time
frame for implementation in any event) is perhaps worse than no
implementation at all. The risk of lost communications or
troubleshooting problems would at best be difficult. Differing and
competing implementations, whether within a standards framework or
outside of it, is likely to have a potentially large negative impact
on a core service provided over the Internet.

Given that last call is almost over and considering the lack of
consensus with regard to SenderID, I would prefer to see the Working
Group not put forward SenderID but I would not like to see it killed.
If core and unified SPF could be moved forward or simply SPF classic,
that would at least be a step in the right direction. There is
potential in SenderID that should not be discarded lightly. Given more
time and less "heat" it may be possible to resolve the current issues
given some flexibility by all concerned.

To illustrate why consensus is important to deployment I decided to do
a little checking after reading the post from J . Trevor Hughes
stating how strongly ESPC and it's members support SenderID. I 
decided to check the extent to which members of the Email Service
Provider Coalition have published either SPF1, SPF2.0/PRA or both. The
results are somewhat interesting and bear on the issue of deployment.
This is clearly a group of companies which should have a strong
interest in authenticated email solutions (As Mr. Hughes pointed out
in his email). If there are issues with achieving deployment (of
anything) by a group that should have the strongest motivation, what
happens when various large recipient (mail service providers) impose
inconsistent requirements on sending MTAs? My concern is that the
larger universe of organizations and companies will simply ignore any
standards and go with whatever meets their immediate need.

The results are as follows:

52 companies listed
27 have no TXT record in DNS (more than half)
17 have SPF1 only
3 have SPF2.0/PRA only
4 have both SPF1 and SPF2.0/PRA

The detailed list as follows:

NO                         Adknowledge, Inc.
SPF1                     aQuantive
SPF1,SPF2.0/PRA Constant Contact (Formerly Roving Software)
NO                        Digital Impact
SPF1                     DoubleClick
NO                        Experian
NO                        Got Marketing
SPF1                     ProspectivDirect
SPF2.0/PRA          SKYLIST
NO 24/7                 Real Media
NO                        @Once
NO                        Acxiom
SPF1                    Advertising.com
NO                        AFG Media
SPF1                    Bigfoot Interactive
SPF1                    BlueHornet Networks, Inc.
NO                       BlueStreak
SPF1                    Britemoon
SPF1,SPF2.0/PRA CheetahMail
NO                       Datran Media
NO                       Digital Connexxions
NO                       eDialog
NO                       EmailLabs
SPF1                    ExactTarget
NO                       Exmplar, Inc.
SPF1                    IMN
SPF1                   Inter@ctivate, Inc.
SPF1                   Internet Marketing Center
NO                      The Lift Network
NO                      Mediaplex
SPF1                   NetCreations, inc.
NO                      Performics
SPF1,SPF2.0/PRA Pexicom, Inc.
SPF1,SPF2.0/PRA Port25 Solutions, Inc.
NO                       Postfuture
SPF1                   Quris
NO                       RightNow Technologies
SPF1                    Responsys
NO                       Return Path
NO                       Savicom
SPF1                   Silverpop
SPF2.0/PRA        SmartSource
NO                      SourceLink
NO                      StrongMail Systems
YES                    SubscriberMail, LLC
SPF2.0/PRA        TargitInteractive
SPF1                   Topica
NO                      Traffix, Inc.
NO                      TranSend, Inc.
NO                      ValueClick
SPF1                   VerticalResponse
NO                      Yesmail

Michael Hammer  [email-masked]

---

From: "J. Trevor Hughes" <[email-masked]>
Date: Fri, 3 Sep 2004 11:01:11 -0400

[...snip...]

Michael,

Thanks for a thoughtful and objective response.

The ESPC is fully committed to email authentication and has been supportive
of SPF1 and Sender ID since the beginning. We've had a significant role in
helping to get to this point (including hosting a meeting at Harvard Law
School in January where the idea of merging Caller ID with SPF was discussed
with Meng and Microsoft).

One thing that is worth noting about your analysis is that the majority of
ESPs do not send their customer emails from their corporate domains. Many
employ dedicated IP addresses and vanity domains for each client. While
there is no reason not to implement authentication on their corporate
domains, it is not unthinkable that their first implementation would focus
on the client domains and not the ESP corporate domain (we encourage all
members to publish SPF1 and Sender ID for all domains).

We recently issue a press release
(http://www.espcoalition.org/083104senderid.php) stating that all new ESPC
members are required to implement SPF1 and that all existing members are in
compliance or in the process of implementing.  I expect that we will require
Sender ID compliance in the near future.

I don't think there is any lack of consensus among the ESPC members. Less
than a month ago almost 100 of our members visited Microsoft for a day long
summit on Sender ID and expressed our support.

Many of our members have posted their own thoughts to this list and I expect
you will see more postings over the next few days as last call approaches.

Trevor

---

From: Rand Wacker <[email-masked]>
Date: Fri, 3 Sep 2004 09:14:43 -0700 (PDT)

> SPF-classic.  Vague references to banks don't convince me any more,

The following is not a vague reference, but an actual planned deployment
(I just can't tell you who is planning it for obvious reasons):

Large Bank communicates with numerous customers addresses at Large ISP.
Large ISP has indicated that they will verify inbound authentication
credentials and has negotiated preferred delivery of authenticated mail
from Large Bank's domain.  Large ISP has given Large Bank the ability to
add a limited number of bank-controlled domains to the Large ISP preferred
whitelist.

Large Bank has quite a bit of customer email delivered by a third party.
This third party delivers mail with a bounce address (MAIL FROM) of
outsource.com (so they can do the bounce processing), but a From: header
of largebank.com.  Large ISP will only whitelist largebank.com (because
that is who the ISP/Bank customers want to hear from, they don't care
about hearing from outsource.com).

In this case, Sender ID would let Large ISP whitelist largebank.com and
still allow outsource.com to deliver mail for the bank (as long as the
bank's DNS records let it do so), /and/ continue to process bounces
properly.  SPF doesn't permit From: header whitelisting (at best) and
breaks bounce handling (at worst).

WRT to Resent-From spoofing and the PRA, its important to note that it is
the PRA result which is whitelisted, so if a phisher uses Resent-From:
phisher.com w/ From: largebank.com, the message will not get preferred
treatment by the ISPs whitelist.

-Rand

---

From: <[email-masked]>
Date: Fri, 3 Sep 2004 13:15:13 -0400

> breaks bounce handling (at worst).

Okay, now suppose SPF-classic were adopted as a standard.  Large ISP
would now whitelist MAIL-FROM addresses in *.largebank.com instead of
whitelisting those addresses in the PRA.

If the bank wants outsource.com to send the mail, it sets up either a
CNAME, or else:

$ORIGIN largebank.com.
outsource MX 10 largebank-bounces.outsource.com.
outsource TXT "v=spf1 include:spf.outsource.com -all"

And outsource.com now sends mail using bounce address
"outsource.largebank.com."  (As a bonus, if for some reason
outsource.com had to be fired quickly, largebank could redirect
bounces quickly to their replacement.)

Now, of course, just as phisher could always use a PRA of
[email-masked] with a From: address of largebank.com, the
phisher can also use a MAIL-FROM address of [email-masked]. 
But again, just as in your example, the mail would not be whitelisted,
which is the desired result.

The mechanisms are slighly different, but the achieved security policy
is the same.  I'm sure that largebank.com and outsource.com would be
happy to use either approach depending on what got standardized.

David

---

From: Graham Murray <[email-masked]>
Date: Fri, 03 Sep 2004 18:37:58 +0100

> about hearing from outsource.com).

And prior to Sender-ID being published, a recipient looking at the
headers will see that the mail was not sent from largebank.com and at
least some of them might discard the email as not genuine - especially
as phishing is so rife at the moment. If instead of this they were to
create a sub-domain 'outsource.largebank.com' for outsource.com to use
and set up the DNS for that sub-domain to point to outsource.com's
servers then both SPF1 would work *and* customers examining the
headers would see that it comes from a host within largebank.com and
would therefore put more trust in the authenticity of the emails.

As I have said before, organisations like largebank.com who use third
party domains in their emails are making life easier for phishers. If
customers see genuine emails sent from third party domains, they are
less likely to suspect the forged emails sent by phishers.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 03 Sep 2004 15:03:09 -0700

> treatment by the ISPs whitelist.

In the case of the MPR draft, the From header can receive specific
restrictions.  Whether a field is restricted or not does not impact
reputation services or MTA authentications.  This allows such
restrictions to be applied as needed without the risk of a list treated
as representing the nominal sources of mail, rather than the exclusive
source of mail, serving as a spam exploit because of the double role of
also associating the MTA to the mailbox domain.

-Doug