Subject: DEPLOY: Permitting '-all' to be used immediately represents a flag day.

From: David Woodhouse <[email-masked]>
Date: Wed, 15 Sep 2004 10:23:50 +0100

Each of the mailfrom and pra scopes make flawed assumptions about
forwarding practice, and it would be necessary for uninterested
forwarding sites to modify their behaviour in accordance with any new
RFC.

Sites would need to modify the SMTP-reverse-path, or add a new header to
conform with mailfrom/pra respectively.

The use of '-all' in any such record makes the assumption that
forwarding sites have _already_ upgraded. This is not realistic -- the
date of publication would in effect be a 'flag day'. 

We should avoid such an occurrence. The first publication must prohibit
("MUST NOT") the use of '-all' in records of either scope until such
time as it is later decided that the Internet as a whole is quorate with
respect to whatever reverse-path/header modification is required for
each.

-- 
dwmw2

---

From: Graham Murray <[email-masked]>
Date: Wed, 15 Sep 2004 11:42:51 +0100

> respect to whatever reverse-path/header modification is required for

I very strongly disagree. On the contrary, the use of -all should be
encouraged as soon as possible. In the vast majority of cases (the
exceptions being web sites such as greeting cards and 'email this news
item') the forwarding is done by, or on behalf of, the recipient of
the email. That the mail might be forwarded should not be of any
concern to the sending domain which publishes -all MARID DNS
entries. Do not forget that as far as the sender is concerned, the
site doing the forwarding is the intended recipient of the email. So,
it is the recipient's problem and responsibility to accept mail sent
to addresses which are then forwarded to them.

---

From: wayne <[email-masked]>
Date: Wed, 15 Sep 2004 05:58:00 -0500

> ("MUST NOT") the use of '-all' in records of either scope until such

No.

I own several domains that do not send email.  Period.  All such email
claiming to be from them are forgeries.  It makes no difference
whether these emails have been forwarded or not, they are forgeries.

Using "-all" is perfectly valid.

Even in cases where a domain does send email, it should be up to the
domain owners to decide whether they think that the problems with
forwarders outweigh the problems with forgeries.

-wayne

---

From: Mark <[email-masked]>
Date: Wed, 15 Sep 2004 11:17:10 GMT

Graham Murray wrote:

>> We should avoid such an occurrence. The first publication must
>> prohibit ("MUST NOT") the use of '-all' in records of either scope
>> until such time as it is later decided that the Internet as a whole
>> is quorate with respect to whatever reverse-path/header modification
>> is required for each.
>
> encouraged as soon as possible.

I completely, and vehemently, agree with Graham, on both counts: people who 
have taken their time in the transitional phase (~all) should be actively 
encouraged to start using -all; and -all records SHOULD NOT be prohibited; 
not now, not ever.

As I have pointed out earlier, interpreting SPF records is not obeying local 
policy, but REMOTE policy; namely, that of the domain owner. If the domain 
owner feels comfortable enough about his setup to use -all, then we SHOULD 
NOT break things by ignoring that policy; nor encourage people to revert to 
the "I am in the process of making up my mind/setting up my installation" 
stage, which ~all effectively is.

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

---

From: David Woodhouse <[email-masked]>
Date: Wed, 15 Sep 2004 12:32:35 +0100

> Using "-all" is perfectly valid.

I agree that using "-all" by itself is valid. Rather, it is the use of
".* -all" which should be prohibited -- other records which permit mail,
_followed_ by '-all'.

> forwarders outweigh the problems with forgeries.

I disagree. We are supposed to be designing protocols for interoperation
between sites; a scheme which actually works in practice. You cannot
allow sites to merely disregard the way the real world works, to the
detriment of others. Or would you also advocate permitting TCP
implementations to do what they like with retries in the case where the
link is congested?

-- 
dwmw2

---

From: David Woodhouse <[email-masked]>
Date: Wed, 15 Sep 2004 12:28:42 +0100

On Wed, 2004-09-15 at 11:42 +0100, Graham Murray wrote:
>  Do not forget that as far as the sender is concerned, the

That may be true, but it is the responsibility of this working group to
propose a solution for this newly-imposed problem, and ensure that any
necessary changes to current practice become widespread -- _before_
starting to rely on assumptions about it.

I am not suggesting that '-all' should be permanently forbidden, merely
that it must be forbidden in the first release of the new specification,
and must remain so until such time as the proposed solutions are
widespread.

-- 
dwmw2

---

From: <[email-masked]>
Date: Wed, 15 Sep 2004 08:04:36 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of David Woodhouse
> Sent: Wednesday, September 15, 2004 7:29 AM
> To: Graham Murray
> Cc: [email-masked]
> Subject: Re: DEPLOY: Permitting '-all' to be used immediately
> represents
> aflag day.
>
>
>

There *is* a solution.  If your domain does forwarding through SMTP servers that do not yet have the
mechanism(s) necessary to work, then publish with ~all.  For those domains who don't have/allow any
forwarding and/or the known allowed forwarders have the necessary mechanisms in place, -all is
perfectly acceptable.

> and must remain so until such time as the proposed solutions are

I have to 100% disagree:
If the solution does not start working for at least *some* in the short term, then there will be
reduced/zero perceived benefit which discourages buy-in from undecided fence sitters.

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
[email-masked]
Fax: (416) 441-9085

---

From: Kevin Peuhkurinen <[email-masked]>
Date: Wed, 15 Sep 2004 09:52:21 -0400

Add my name to those that disagree with you.   I have "-all" in my SPF 
records because I am confident that all legitmate business related 
emails from my company will be sent from the servers specified in my SPF 
records and none others.   If recipients are concerned about the 
possibility of missing some email due to greeting card companies and the 
like, they can use a whitelist for those.   Otherwise, being in the 
banking industry, I am much more concerned about stopping forgeries than 
I am about permitting online greeting card emails.

---

From: Tony Finch <[email-masked]>
Date: Wed, 15 Sep 2004 15:04:03 +0100

On Wed, 15 Sep 2004 [email-masked] wrote:
>
> There *is* a solution.  If your domain does forwarding through SMTP
> servers that do not yet have the mechanism(s) necessary to work, then
> publish with ~all.

You do not understand the problem. The difficulty with forwarding occurs
at the receiving sites, not the sending sites that publish Sender-ID
records. If you use -all you must never send email to an alias-fowarding
address -- but you have no way of knowing which addresses these are.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SELSEY BILL TO LYME REGIS: WEST OR NORTHWEST 4 OR 5, DECREASING 3, THEN
BACKING SOUTHWEST 3 OR 4 OVERNIGHT. FAIR. GOOD. MODERATE BECOMING SLIGHT.

---

From: David Woodhouse <[email-masked]>
Date: Wed, 15 Sep 2004 15:48:20 +0100

On Wed, 2004-09-15 at 09:52 -0400, Kevin Peuhkurinen wrote:
> records and none others. 

Your confidence is misplaced. As an example -- if you ever send a mail
to the address [email-masked]', it's likely to get forwarded to
wherever I happen to be reading my mail at the time, such as an email
address at my current place of employment. Neither you nor the sysadmin
at the final destination may have any idea about the arrangement, which
is an established practice and which has worked for decades.

Breaking this so abruptly would constitute a flag day. Your naïveté
is a prime example of why such records should temporarily be prohibited,
until such time as the rest of the world has adjusted.

By immediately allowing the use of '-all' on domains which actually send
mail, we would promote discord and harm interoperability. 

> Otherwise, being in the banking industry, I am much more concerned
> about stopping forgeries than I am about permitting online greeting
> card emails.

Then you should be looking at a scheme which actually offers true
end-to-end verification of identity. You could start by PGP-signing your
output.

-- 
dwmw2

---

From: <[email-masked]>
Date: Wed, 15 Sep 2004 11:20:32 -0400

> [mailto:[email-masked]]On Behalf Of Tony Finch
> Sent: Wednesday, September 15, 2004 10:04 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: DEPLOY: Permitting '-all' to be used immediately
> representsaflag day.
>
>
>

Valid point.

With more thought, you are correct, sorry.

I still support -all, because:
Another way of looking at it is, if the receiver wants to forward other (valid) email address(es) to
his/her actual email address, the onus is on the recipient to ensure that the MTA doing the forward
on his/her behalf has the necessary mechanisms.  If it does not then either accept the risk of
rejected email OR strive to get the sender to send to the final email address directly.

I prefer the latter, which under consideration:
-if the sender a person, then an auto reply on the account saying (please now use my direct address
to contact me) should suffice
-if the sender is automated (such as mailing list) then the person should have updated their
subscription/registration/whatever with the direct email address.

Terry Fielder

---

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

On Wed, 15 Sep 2004 [email-masked] wrote:
>
> Another way of looking at it is, if the receiver wants to forward other
> (valid) email address(es) to his/her actual email address, the onus is
> on the recipient to ensure that the MTA doing the forward on his/her
> behalf has the necessary mechanisms.

Most recipients are not capable of doing so, and most forwarding sites do
not have the necessary mechanisms. The necessary mechanisms either do not
work adequately (in the case of /pra) or are problematic (in the case of
/mailfrom).

> If it does not then either accept the risk of rejected email OR strive
> to get the sender to send to the final email address directly.

The point of using a forwarding address is to have a stable email address
independent of the final destination. It's a huge pain to have to update
everyone's address books every year or two.

> -if the sender a person, then an auto reply on the account saying
> (please now use my direct address to contact me) should suffice

Backscatter is part of the problem not part of the solution.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTH FITZROY: NORTHEAST 4 OR 5 IN EAST, OCCASIONALLY 6 NEAR CAPE FINISTERRE,
OTHERWISE VARIABLE 3 OR 4. FAIR. GOOD.

---

From: Mark <[email-masked]>
Date: Wed, 15 Sep 2004 16:40:29 GMT

[email-masked] wrote:

>> You do not understand the problem. The difficulty with
>> forwarding occurs at the receiving sites, not the sending
>> sites that publish Sender-ID records.

There is no such thing as a "receiving site" here. Or rather, the term is 
used rather misguidedly to denote a site who forwards. If I send mail to a 
'receiving' site, which forwards that mail, then that site is simply another 
hop in the sender chain.

>> If you use -all you must never send email to an
>> alias-fowarding address -- but you have no way
>> of knowing which addresses these are.

This 'problem' is hardly new; it is covered in section "Does SPF break email 
forwarding?" in the SPF FAQ, at:

http://spf.pobox.com/faq-old.html

The answer is given there, too. Worth quoting is this one:

If you don't have procmail, the .forward could instead just say 
"|/usr/sbin/sendmail -oi -f [email-masked] [email-masked]"

Professional forwarders should implement SRS. It does not suffice for them 
to be SPF compliant on the receiving end, yet to omit implementing the 
necessary rewriting scheme (or use SUBMITTER, once it comes into fashion) on 
the sending part of the equation.

- Mark

---

---

From: Rik van Riel <[email-masked]>
Date: Wed, 15 Sep 2004 12:46:33 -0400 (EDT)

> respect to whatever reverse-path/header modification is required for

Agreed.  In fact, there might just be too many email forwarding
accounts out there to ever have a scheme like SPF work right.

The validation of email really needs to be from the sender to
the recipient, regardless of whether or not anybody else in-between
handled the mail...

Rik
-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

---

From: <[email-masked]>
Date: Wed, 15 Sep 2004 12:41:33 -0400

> Sent: Wednesday, September 15, 2004 12:13 PM
> representsaflagday.
> work adequately (in the case of /pra) or

Agreed, I don't like PRA, it seems dumb perform tests on something that can be forged anyway.

> are problematic (in the case of
> /mailfrom).

Problematic does not mean without resolution.  I have heard solutions (although have not implemented
any yet).

> The point of using a forwarding address is to have a stable

Agreed, I have many email addresses, and I too will have to ensure the forwarding is done by
compliant servers (or move the forwarding elsewhere).

> everyone's address books every year or two.

I know.  It's also a pain to be flooded with emails with forged from domain.

> Backscatter is part of the problem not part of the solution.

Agreed.  I am already flooded with bounces and crap from failed delivery, viruses etc.  PRA may
cause some backscatter, but it has the potential to block a whole bunch (viruses usually include an
SMTP engine so they don't need to relay through a real MTA, hence 1 hop, hence no backscatter on
rejection before DATA).

BTW I don't endorse PRA because (amongst other things) the backscatter issue.

But I am voting for Classic SPF which does not have a backscatter issue (please correct me if I am
wrong).

Terry

---

From: Chuck Mead <[email-masked]>
Date: Wed, 15 Sep 2004 12:33:08 -0400

>mail, we would promote discord and harm interoperability. 
Uhm... I object to the implication that -all should, or should not, be 
allowed. It is situationally dependent and the spec
should bow to that possibility.

Ex: moongroup.com uses -all right now and has for some time without any 
difficulties.

I also recognize that other domains have different situations and for 
them -all would not be an efficacious choice.

I think we should "allow" the use of -all or ~all as the domain 
administrators prefer based upon their
own particular situation.

-- 
Chuck Mead <[email-masked]>
Instructor II (and resident Postfix bigot), GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"

---

From: David Woodhouse <[email-masked]>
Date: Wed, 15 Sep 2004 18:00:15 +0100

On Wed, 2004-09-15 at 11:20 -0400, [email-masked] wrote:
> [ Tony Finch wrote: ]
> > sites that publish Sender-ID records. If you use -all you
> > must never send email to an alias-fowarding address -- 
> > but you have no way of knowing which addresses these are.
> 
> Valid point. 

Good. Some are rather disingenuously still claiming not even to see
that.

> Another way of looking at it is, if the receiver wants to forward
> other (valid) email address(es) to his/her actual email address, the
> onus is on the recipient to ensure that the MTA doing the forward
> on his/her behalf has the necessary mechanisms.

Even assuming that the deployment of such mechanisms is acceptable, it
will take _time_ for them to be deployed after the publication of the
RFC which mandates them.

It is the responsibility of this working group to enable
interoperability between sites; we must not _simultaneously_ publish a
requirement for such new mechanisms and permit sites to assume that the
same mechanisms are _already_ deployed. That would be extremely
irresponsible and foolish.

For this reason, I believe that use of the '-all' record on domains
which actually send mail could be described, but must be _temporarily_
prohibited, until such time as it is determined that a large enough
proportion of the world has implemented these mechanisms of which you
speak.

-- 
dwmw2

---

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

> [email-masked] wrote:

No he did not. Please attribute quotes correctly.

> Worth quoting is this one:
>

Hey, why don't we just reject all email with a null return path? That'll
solve the backscatter problem! Who cares about reliability anyway?

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SHETLAND ISLES: NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4 THEN SOUTHEAST 6 OR
7, PERHAPS GALE 8 LATER. RAIN LATER. GOOD BECOMING MODERATE OR POOR. MODERATE
OR ROUGH, OCCASIONALLY VERY ROUGH LATER.

---

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

On Wed, 15 Sep 2004 [email-masked] wrote:
>
> I am already flooded with bounces and crap from failed delivery, viruses etc.

Then what you want is BATV. Sender-ID and SPF will neither solve your
problem completely nor quickly, whereas BATV will.

Tony.

---

From: Kevin Peuhkurinen <[email-masked]>
Date: Wed, 15 Sep 2004 13:11:24 -0400

>mail, we would promote discord and harm interoperability. 
To be brutally honest, unless you are an executive or member of our 
board of directors or an extremely important customer, I just don't care 
that much from a business perspective if you don't get my email.   I'm 
not trying to put down your perspective any more than you are mine, but 
looking at it from a purely business rather than a techie point of view, 
it's just not my concern that you want to forward your mail AND have 
your end receiver do SPF checks as well.  I'm just telling the world 
which servers are authorized to send email on behalf of my domains.  
It's your receiver that's dropping the email and if you are unhappy 
about not getting your mail, you should take it up with them.

Now, if you could convince me that a large portion of our business 
contacts would have trouble with this, then I'd reconsider.

>end-to-end verification of identity. You could start by PGP-signing your
PGP signing my output would do next to nothing to stop phishing style 
forgeries.

---

From: Matthew Elvey <[email-masked]>
Date: Wed, 15 Sep 2004 10:15:36 -0700

This isn't a problem, because Tony's statement:

>If you use -all you must never send email to an alias-fowarding
>address
>
only applies in the mailfrom and pra scopes, and we're going to be 
checking HELO.
If the HELO check (+ A&R check) passes, the forwarding problem GOES AWAY.

BTW, apropos William Leibzon's post:  I think an atomic scoring system, 
i.e. a system where a bunch of atomic tests are done and results of each 
assigned a score and the score summed is not optimal.      This kind of 
issue is why I've been pushing for a BCP in this area.
I'm thinking that instead, conditional logic is better, but I'm not sure.
The SA rules that handle habeas are informative here; they have 
conditional logic:
HABEAS_USER means "Has Habeas warrant mark and on User List" (This is 
conditional logic - it means: if H and U then score=score-8; else nothing.)

HABEAS_INFRINGER means "Has Habeas warrant mark and on Infringer List"  (which is conditional logic too)

These are assigned the scores -8 and +16, respectively, by default, if 
they hit.
No score is assigned for <Has Habeas warrant mark but not on either list>. 
No score is assigned for <Has no Habeas warrant mark but IS on a list>. 
This is the case in recent SA releases (2.6, 3.0).
In 2.4, the tests were atomic, and it seems the conditional logic was a 
needed enhancement added later. 2.4:

|score HABEAS_SWE                     -4.0
|score HABEAS_HIL                     4.0
In 2.4 there was also
|score HABEAS_VIOLATOR                8.0

|meta HABEAS_VIOLATOR		(HABEAS_SWE && HABEAS_HIL)  
(Err. This is conditional logic too. My bad. Anyway, clearly it's important)

If the HELO check (+ A&R check) passes, but the A&R check provides 
something other than a yes/no answer, then things get more complicated.  
Perhaps we should assume this is the case for the BCP.  E.g. if the HELO 
A&R check results in what I'll call a 'weak pass', then further MARID 
checks would be useful, but if there's a strong pass, then don't do 
further tests, which would cause false positives, e.g. due to forwarders 
that don't do SRS or SUBMITTER.  Is this complicated logic necesary, or 
would simple logic and HELO check (+ A&R check) test passes having a 
relatively large positive score be good enough?  I'm pretty sure that 
the HELO check + A&R check should not be scored separately.

http://old.spamassassin.org/full/3.0.x/dist/rules/50_scores.cf has 
sensible text for SPF followed by scores that are at odds with the text 
and are unreasonable:

#
# SPF                                              
# Note that the benefit for a valid SPF record is deliberately minimal; it's
# likely that more spammers would quickly move to setting valid SPF records
# otherwise.  The penalties for an *incorrect* record, however, are large.  ;)
#
ifplugin Mail::SpamAssassin::Plugin::SPF
score SPF_PASS -0.001
score SPF_FAIL 0 0.974 0 0.875
score SPF_SOFTFAIL 0.500
score SPF_HELO_PASS -0.001
score SPF_HELO_FAIL 0 0.001 0 0.001
score SPF_HELO_SOFTFAIL 0 0.907 0 3.140
endif # Mail::SpamAssassin::Plugin::SPF

---

From: Mark <[email-masked]>
Date: Wed, 15 Sep 2004 17:11:11 GMT

> No he did not. Please attribute quotes correctly.

Please, interpret posts correctly; the text I quoted had a double ">>", 
indicating I was quoting the poster Terry quoted. So, relative to 
"[email-masked] wrote:", the ">>" was correct.

> Hey, why don't we just reject all email with a null return path?
> That'll solve the backscatter problem! Who cares about reliability
> anyway?

Very silly remark, in otherwise very silly post.

- Mark

---

---

From: "Chuck Mead" <[email-masked]>
Date: Wed, 15 Sep 2004 13:28:49 -0400 (EDT)

> accounts out there to ever have a scheme like SPF work right.

Again I say... this is situationally dependent. Using "MUST NOT" in the
spec is sending the wrong message. The right message is that the domain
admin "MAY USE" -all if they chose based on their individual domain
situation.

--
[email-masked]
Chief Tech and Bottle Washer

---

From: Matthew Elvey <[email-masked]>
Date: Wed, 15 Sep 2004 10:30:02 -0700

-all is perfectly OK now.  The spec should make clear the issue David 
raised, to the extent it remains an issue, given pending changes. That's 
all.

>> "|/usr/sbin/sendmail -oi -f [email-masked] [email-masked]"
Yuck.  A lame solution like this should be fixed or removed from the site. 

>But I am voting for Classic SPF which does not have a backscatter issue (please correct me if I am
It does; the spec doesn't even say not to bounce in case of 'fail'.  The 
authors were too timid to make ANY concrete statements about what to do 
with the result of the SPF checks.  It does mandate SRS, so it MIGHT 
cause a net reduction in backscatter.

PS Folks, please email me if you think I'm posting too often; I'd like 
to know.

---

From: David Woodhouse <[email-masked]>
Date: Wed, 15 Sep 2004 18:40:08 +0100

On Wed, 2004-09-15 at 10:15 -0700, Matthew Elvey wrote:
> David Woodhouse wrote:
> > Each of the mailfrom and pra scopes make flawed assumptions...

> This isn't a problem, because Tony's statement [...] only applies in 
> the mailfrom and pra scopes, and we're going to be checking HELO.

Er, OK -- I agree with the logic of that statement as it stands: the
flawedness of the mailfrom and pra scopes isn't a problem if we don't
actually _use_ them. 

That's fine by me. So let's not define them, and let's banish them
entirely from our minds. But I don't quite understand what you're saying
-- can you confirm precisely whom you mean by 'we' in your statement
above?

-- 
dwmw2

---

From: David Woodhouse <[email-masked]>
Date: Wed, 15 Sep 2004 18:47:21 +0100

On Wed, 2004-09-15 at 12:33 -0400, Chuck Mead wrote:
Ex: moongroup.com uses -all right now and has for some time without any 
difficulties.
> administrators prefer based upon their own particular situation.

-- 
dwmw2

---

From: David Woodhouse <[email-masked]>
Date: Wed, 15 Sep 2004 18:50:45 +0100

Apologies for the previous empty post. I slipped while editing my
quotation. At least I _do_ edit my quotations ;)

> administrators prefer based upon their own particular situation.

My situation is that I am on the Earth, in 2004. In my situation, I can
neither publish nor obey a record ending in ' -all' with a reasonable
expectation that I would not be causing valid email to be rejected. 

I know not how the situation is different for you.

-- 
dwmw2

---

From: David Woodhouse <[email-masked]>
Date: Wed, 15 Sep 2004 18:46:05 +0100

On Wed, 2004-09-15 at 13:11 -0400, Kevin Peuhkurinen wrote:
> that much from a business perspective if you don't get my email. 

That's perfectly reasonable. I understand your perspective. But that is
not an acceptable perspective for this working group, which must concern
itself with interoperability of the system as a worldwide whole.

Without meaning disrespect by the precise choice of words in my
paraphrasing of your sentiment -- it is not acceptable for this working
group to codify a scheme whereby everyone can retreat into a corner and
say "I don't care if you don't get my mail, and I don't care that I
don't get yours".

-- 
dwmw2

---

From: David Woodhouse <[email-masked]>
Date: Wed, 15 Sep 2004 18:58:43 +0100

> "[email-masked] wrote:", the ">>" was correct.

Strictly speaking, I suppose Terry did indeed write that, and the
original fault is indeed with him for not attributing correctly, and not
including an attribution line which you in turn could include.

But perhaps Mark you could have cleaned it up when you replied? It would
have helped. I really do wish people would behave a little better in
their use of email -- if we can't manage a little bit of decorum even in
a forum where we discuss technical matters related to email, surely we
might as well all just give up on netiquette entirely?

> Very silly remark, in otherwise very silly post.

You _do_ understand that this idea was the logical conclusion of your
suggestion to use '-f nobody@...', and hence prevent the sender of the
mail from getting any resulting bounces -- right? 

-- 
dwmw2

---

From: Kevin Peuhkurinen <[email-masked]>
Date: Wed, 15 Sep 2004 14:00:37 -0400

>say "I don't care if you don't get my mail, and I don't care that I
Agreed, but I also don't think it acceptable to say that nobody is 
allowed to make that choice either.   A RECOMMENDED wording, in my mind, 
would be much more fitting.

If you were to use a MUST NOT, what sort of limitation on it would you 
propose?   "Implementors MUST NOT use '-all' until the IETF has 
determined that 80% of all forwarders are compatible with the 
specification"?   How would you make that determination?

---

From: Mark <[email-masked]>
Date: Wed, 15 Sep 2004 17:56:16 GMT

> Good. Some are rather disingenuously still claiming not even to see

If on the eve of global SPF adoption you suddenly want to 'reinvent' the 
forwarding problem, which has existed and has been well documented from day 
one, then be my guest; but please do not ask me to play along.

> requirement for such new mechanisms and permit sites to assume that
> the same mechanisms are _already_ deployed. That would be extremely

A solid argument. But it is also putting the cart before the horse: you 
cannot wait for the world to improve until you jump aboard yourself. You 
must be the change you want to be in the world, as the Mahatma would say. 
And I can tell you this much: with everyone publishing ~all policies, and no 
forwarding ever breaking anywhere as a result (nor ever have any fake mail 
"fail" anywhere), no one, anywhere, will ever implement the necessary 
rewriting schemes, either. There must, at some point, be an incentive to 
change, lest you be dealt out of the game. What you propose, is taking away 
that incentive. And I propose to decline.

- Mark

---

---

From: Mark <[email-masked]>
Date: Wed, 15 Sep 2004 18:15:59 GMT

David Woodhouse wrote:

>> Please, interpret posts correctly; the text I quoted had a double
>> ">>", indicating I was quoting the poster Terry quoted. So, relative
>> to "[email-masked] wrote:", the ">>" was correct.
>
> original fault is indeed with him for not attributing correctly, and
> not including an attribution line which you in turn could include.
>
> But perhaps Mark you could have cleaned it up when you replied?

Yes, I could have. Will do.

> mail from getting any resulting bounces -- right?

I quoted that suggestion from the spf.pobox FAQ. :) I said I quoted it, but 
had not put additional quotation marks around it.

N.B. I do not think Meng really meant to litterally use "nobody@" in his 
example. He was, I believe, just demonstrating how one can easily change a 
..forward file, to achieve the necessary rewriting, without having to 
implement SRS.

P.S. I apologize for my somwhat crabby tone in my earlier posts today. Since 
you have been with SPF from a very early date too, I believe, I failed to 
see why the topic suddenly needed rehashing. But I had my say; I will step 
back a bit now, and let others have theirs.

Cheers,

- Mark

---

---

From: <[email-masked]>
Date: Wed, 15 Sep 2004 14:13:21 -0400

> Sent: Wednesday, September 15, 2004 1:51 PM
> To: Chuck Mead
> Cc: [email-masked]

I have many "pointer" domains, used for marketing (websites and advertising) but for which emails
are never actually sent from.  It is *very* valid to use -all for those domains, as any email from
anywhere claiming to be from someone at one of those domains is definitely forged.

Publishing -all for those domains alone will save me some forgeries and bounce crap and virused
messages.

Terry Fielder

---

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

> ..forward file, to achieve the necessary rewriting, without having to

Whatever local part at the forwarding site is chosen, it will be wrong.
Changing the return path to some address at a site that the recipient
doesn't use is not a solution. Either the sender or the recipient needs to
be informed of any problems with email delivery; if the recipient's
address doesn't work the sender must be informed.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LOUGH FOYLE TO CARLINGFORD LOUGH: SOUTH 4 INCREASING 5 TO 7, PERHAPS GALE 8
LATER. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR LATER. SLIGHT OR
MODERATE BECOMING ROUGH.

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 15 Sep 2004 20:39:30 +0200

> date of publication would in effect be a 'flag day'. 

Why all the hassle. Let the people/market decide.

- if someone publishes -all and gets important mail bounced s/he can
  still decide to remove/change -all
- if someone uses forwards and doesn't receive emails any longer, s/he can 
  o  remove the forward
  o  ask the next next hop/destination to switch of SPF checks
  o  implement something as clumsy as SRS

This is something the users must decide and it will influence the
success of SPF, SRS or any other method like them. They break the
Internet mail infrastructure as it existed for more than 20 years,
we'll see how it will work out.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: Chuck Mead <[email-masked]>
Date: Wed, 15 Sep 2004 14:49:15 -0400

Kevin Peuhkurinen wrote:
>>> board of directors or an extremely important customer, I just don't 
>>> care that much from a business perspective if you don't get my email.   
>>
>>

Exactly... and since many domains could safely use -all right now how 
would saying "MUST NOT" advance the use of the protocol towards an 
eventual "flag day"? I expect that answer would be short. It won't.

For this reason I respectfully encourage the group to not choose the 
wording "MUST NOT" and "MAY NOT" with respect to implementation of -all. 
There has to be another way to make it clear that this *could* cause 
problems for domains choosing it as an option and yet still suggesting 
that once those problems are solved -all is suggested!

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 15 Sep 2004 21:26:22 +0200

> ..forward file, to achieve the necessary rewriting, without having to 

s/easily/brokenly/

I seen hundreds of mail loops where customers configure their Exchange
to pop3 their Mailboxes and then users have forwards to other domains.
Exchange rewrites to 2921.MAILFROM to the address of the user and
forwards the email through a outgoing relay (well behaved, use the
mailserver of your provider)
Funny things happen as soon as the destination host encounters an error
(mailbox full, message too large, ...) and a bounce is generated.
Yeah, this can be fixed by adding bounce Mailboxes for each and every
user and changing all existing software and have users query the double
number of mailboxes and then they will automate it and we'll start from
the beginning.
We could also just write a completely new mail system, maybe it would be
lesser hassle and deploy faster and be less broken ...

	\Maex

---

From: Rik van Riel <[email-masked]>
Date: Wed, 15 Sep 2004 16:35:36 -0400 (EDT)

> admin "MAY USE" -all if they chose based on their individual domain

Would a SHOULD NOT be acceptable, with an appropriate note
explaining the pitfalls and why people need to be extremely
careful with the use of -all ?

Rik

---

From: David Woodhouse <[email-masked]>
Date: Wed, 15 Sep 2004 21:41:03 +0100

> Yes, I could have. Will do.

Thank you. I appreciate it's hard to maintain a coherent conversation in
a forum where people insist on top-posting, omitting and mangling
attributions, and omitting References: headers. But we can only do our
best maintain an element of sanity.

-- 
dwmw2

---

From: "Chuck Mead" <[email-masked]>
Date: Wed, 15 Sep 2004 16:46:21 -0400 (EDT)

> careful with the use of -all ?

I see no reason why not. That sounds reasonable. In fact it's *MUCH* more
reasonable a statement than "MUST NOT" when the "MUST NOT" is so dependent
on a domain's individual technical situation.

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 15 Sep 2004 18:18:49 -0400

> > behalf has the necessary mechanisms.

  That sounds reasonable to me.

> not have the necessary mechanisms.

  It's probably easier to deploy fixes to forwarding sites than to
deploy SPF/Sender-Id to the whole net.  In all the discussion about
multi-hop message forwarding, I never understood why it was a good
thing for the final recipient to bypass all of the intermediate hops
for any bounce.

  I would say that deploying fixes to forwarding sites, so that they
properly forward messages, is outside of the scope of MARID, but none
the less is a topic which should be explored.  Once those sites are
fixed, many current objections to MARID protocols & deployment would
disappear.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Sep 2004 15:36:28 -0700

> that once those problems are solved -all is suggested!

Review the marid-mpr draft.
http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt

With MPR, not asserting a restrictive list (exclusive source) does not
invite spoofing as a means of usurping a domain's reputation, as would
be a problem with such lists in either Sender-ID or SPF.  MPR depends
upon the initial step of using CSV to establish a truly authenticated
MTA name.  From this point, it becomes a simple matter of creating a
name list of EHLO names which normally send mail for mailbox.dom. (This 
takes advantage of built-in name compression and does not need to double
enter addresses or perform added queries to obtain an address.)
  
   _mp.smtp.mailbox.dom.  IN PTR mailbox.dom.
   _mp.smtp.mailbox.dom.  IN PTR our-access-provider.com.
   _mp.smtp.mailbox.dom.  IN PTR ads-r-us.com.
 
This would need a single DNS lookup to obtain the EHLO name list and NO
MTA addresses are required!  A message sent from the MTA
EHLO=mx003.bulkmail.ads-r-us.com would be seen as authorized to send
mail for mailbox.dom.

By using the CSV authenticated MTA name for reputation services and
assertions, this does not burden the mailbox domain MTA send control
lists with a danger of being exploited.  It also does not require an
indeterminate number of DNS queries to resolve.

MPR however allows big-bank.com to constrain their list of EHLO names
for RFC2822 From: [email-masked] to be the exclusive source of their
mail.  The receiving MTA or MUA could use this information to either
"color" the mail, or in the case of the exclusivity assertion, then
these agents may even reject the message.  I would expect this rejection
behavior would need to a user based option.

This reintroduces protection once only somewhat available with Sender-ID
and the PRA algorithm.  The major different between MPR and the PRA
algorithm is that the field selection is both better authenticated and
better defined.  In the case of MPR, the authenticated EHLO should be
visible to the user within the MUA to avoid phishing and spoofing as an
additional precaution in newer MUAs.

(If only Outlook would forward mail without stripping the headers, and
then there would also be a simple means to report spam.)

Instead of using BATV, the EHLO name list could be defined as the
exclusive source for RFC2821 MAIL FROM.  I feel BATV remains a better
solution, but offered this to show how the SPF type of operation could
be implemented using this approach.

-Doug

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Sep 2004 15:51:08 +0200

On Wed, Sep 15, 2004 at 08:39:30PM +0200,
 Markus Stumpf <[email-masked]> wrote 

>   still decide to remove/change -all

I agree. This is a local policy issue. The second paragraph in the
section 2.2 of draft-ietf-marid-mailfrom-00.txt ("SHOULD publish SPF
records that end in "-all") should be deleted or moved to "Security
considerations" with a less demanding wording.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Sep 2004 12:25:24 -0700

> considerations" with a less demanding wording.

Publishing "open" records using "?all" or "+all" is not without risk and
is the reason for indicating a SHOULD USE "-all".  Unless there is a
restructuring of the methods to authorize the MTA separately from the
association of the MTA to mailbox domains, an "open" list will invite
spoofing in a quest to falsely claim to be "authorized" by this mailbox
domain.  While such an "open" list is vital to ensuring mail is not
lost, it also invites the problem SPF attempted to address in the first
place.  It is not reasonable to expect a near-term solution for this
problem.

This creates a quandary.  The list can not be closed without causing
mail to be lost, yet leaving the list open invites the problem that was
supposedly being solved.  It is also hazardous to allow unknown entities
to dictate various DNS records of differing domains be looked up
sequentially within a process that grants authorization.  The many
varied record types that SPF allows to be arbitrarily referenced
dramatically increases the risk.  This also opens up other security
concerns as the message may reference a website using poisoned records.

The means of delegation to other domains could be done by name and not
by address to avoid this problem.  By using a two step approach, the
mailbox domain and MTA relationships can be name based.  A list of names
can be obtained in a single DNS query and does not require a script. 
This allows dropping use of TXT records as no amount of script changes
or warnings offers a solution for the many fundamental design flaws:

 a) Prone to DNS record poisoning
 b) High overhead prone to DoS attack
 c) UDP exponential back-off ignored
 d) Allows phishing and spoofing
 e) Invites spoofing MAIL FROM!
 f) Identity easily spoofed to receive "Pass" or "Neutral"
 g) Identity does not locate source of abuse
 h) Identity does not accurately authorize the MTA
 i) Weak identity unsuitable for reputation assessment
 j) Script macros make SPF records unsuitable for white-listing
 k) Script macros allows spammers to hide their full address list
 l) Closed list will break mail
 m) Closed list may force use of provider's mailbox domain
 n) Process does not indicate records as "open" or "closed"
 o) MTAs not indicated as "shared"
 p) Can be used to falsely gain credibility by passing checks

If this was a medicine, it would only make the patient sicker.  Clearly
the risks do not out weight the benefits.  There is a viable solution
however.
 
-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 20 Sep 2004 22:27:47 +0200

Stephane Bortzmeyer wrote:

>> if someone publishes -all and gets important mail bounced
>> s/he can still decide to remove/change -all

> I agree. This is a local policy issue.

Yes and no.  Yes, s/he can still decide to do something.  But
I'd never remove or change a -all, there are better options.
Like using an alias of my address not covered by the sender
policy.  But so far I never had this problem.  But I got about
180,000 bounces and other side effects of forged MAIL FROMs in
six months (03-08).

I'd never remove the -all voluntarily.  And apparently no other
user of claranet.de vanity hosts had any problem (the wildcard
was added in May IIRC).

> "SHOULD publish SPF records that end in "-all"
> should be deleted or moved to "Security considerations" with
> a less demanding wording.

It's perfectly okay.  SPF without -all is about as efficient as
the new FUSSP RfC 3865 [some remarks about RfC 3865 censored,
because this would cost me the write access to MARID].  So add
whatever CAVEATs and warnings you want, but don't touch this
SHOULD.  SPF without -all is a complete waste of bandwidth and
time.  Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Sep 2004 16:40:04 -0700

On Mon, 2004-09-20 at 13:27, Frank Ellermann wrote:
> policy.

You would not know which alias to use to overcome a problem that can not
be known in advance. : ( 

>   But so far I never had this problem.  But I got about

I would expect BATV will be a good solution for this problem.

> user of claranet.de vanity hosts had any problem (the wildcard

It is often difficult to know when a message simply goes missing.  There
would be no way of knowing which recipients are forwarding their
messages.  You are suggesting when a message does go missing, (perhaps
without notice) that there be an alternative address to recover from the
problem.  It could be this assumption of acceptable losses holds because
far fewer use SPF to reject mail than publish records. 

> SHOULD.  SPF without -all is a complete waste of bandwidth and

Although changing the structure of Sender-ID slightly does allow goals
of the MARID charter to be safely achieved, I recognize this has not
been the shared concept that brought the group together.  I hope a few
see such efforts as an earnest endeavor to achieve the goals of the
MARID charter and not as an effort to thwart progress.

By using a two step process, the recipients can be notified when a
message is outside the nominal mail channel, and a name based list can
be used to safely establish the MTA/Mailbox-domain relationship.  An
open SPF/Sender-ID list would be worse than a waste of bandwidth, but
closing the list would make mail delivery unreliable.  By having the MTA
authorization separate from the mailbox domain association, there would
much less motivation for spammers to utilize these open records.

In the jabber session, there was a discussion looking for an a header to
be inserted into the message associated with the sending MTA.  I
suggested the EHLO/Received: header, if validated using CSV, establishes
an equally strong relationship as would adding a new header or
redefining other existing headers.  The advantage would be that these
headers already exists and, once validated, would be suitable to
associate the message with the sending MTA.

Fix what we know to be broken first.  Not authenticating the EHLO name
is broken. Once the EHLO name is reliable, then this becomes an
inflection point.  With this long broken aspect of SMTP repaired, then
the information needed to associate mailbox domains becomes dead simple
and very safe. Such a solution allows the needed identity strength for
asserting a reputation where much of the abuse will be abated.  A
validated EHLO alone would be extremely helpful in preventing spoofing
and phishing.

Sender-ID could simply build upon a foundation of "strengthened"
existing structures.  Sender-ID then becomes a simple name list to
associate the mailbox-domain to MTAs.  The goal of the MARID charter
does not require that a script be used nor does the goal require an
address list be used to define the Mailbox-domain/MTA relationship.  As
can be discerned by the potential downsides using addresses instead of
names, the slight change being suggested is to use names rather than
addresses.  Fix what we know to be broken, and then add Sender-ID using
names.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 21 Sep 2004 04:53:11 +0200

Douglas Otis wrote:

> You would not know which alias to use to overcome a problem
> that can not be known in advance. : (

Not sure what you're talking about.  Let's say that I send a
mail to somebody AT infradead mentioned here in other threads.

The receiver forwards this to a 3rd party without changing my
MAIL FROM.  The 3rd party says "you are not allowed to forge
xyzzy addreses" and refuses to accept the mail.  Infradead's
MTA returns the mail to me.  That's IMHO working as designed.

I could fix this problem by using a MAIL FROM de.clara.net or
another mailer (today with all these BLs around we all have
at least one backup MSA, or at least I found that this is a
MUST HAVE).

But I wouldn't authorize the ill-behaved MTA to use my address,
neither directly by adding this MTA to "my" sender policy, nor
indirectly by modifying "-all" to something else.

That's not how I understand SMTP, for me the MX is meant as the
gateway to the receiver.  It can forward, and relay, and do
whatever it wishes, but it _must not_ say MAIL FROM xyzzy while
talking with the MX of a 3rd party.  If I'd wanted to send my
mail to this 3rd MX, then I'd do it directly.

Okay, it may change common practice for some systems, and it's
obviously different from what Dave said, but OTOH we're here in
MARID because there _is_ a problem with SMTP.  Or rather more
than one problem, spf2.0/mfrom fixes only one of the problems.

> I would expect BATV will be a good solution for this problem.

In theory it could be, but spf2.0/mfrom is something working
today with my MUA and my ISP.  They didn't have to do anything,
only publish a sender policy with "-all".  No new MTA.

Spf2.0/mfrom also offers something for the receiver, the MX can
reject all FAILs.  That's also the reason why there SHOULD be a
"-all" in sender policies:  Without "-all" or similar without
any FAIL mechanism at all, why should the receiver bother to
evaluate the sender policy ?  SPF is a voluntary cooperation
between the (author of the) sender (policy) and the receiver,
and without a chance to get a FAIL the receiver has no reason
to cooperate.

Maybe I'd even implement it this way, if a sender policy has no
word starting with a "-" or a "redirect" stop the evaluation as
waste of time (yes, that violates several MUST in protocol-03,
but I could do it before calling check_host()).

> It could be this assumption of acceptable losses holds
> because far fewer use SPF to reject mail than publish
> records.

That's of course possible, but in my infradead scenario there
are no losses.  Hadmut published RMX in December 2002, RMX and
SPF were discussed over and over again, SPF started in January
2004, and so far the number of unexpected side-effects appears
to be minimal.

Forwarders and mail forgers have to adjust, yes.  But that's a
feature and not a bug.  I like it.  Now please let's be done
with it, get the two RfCs out a.s.a.p., and then start to work
on other ideas like CSV, MTAMARK, or more SPF scopes.

As long as SPF isn't ready I don't trust other ideas, because
I'm not sure if that's only meant to derail SPF or create FUD.

                            Bye, Frank

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Sep 2004 09:38:07 +0200

On Mon, Sep 20, 2004 at 04:40:04PM -0700,
 Douglas Otis <[email-masked]> wrote 

> I would expect BATV will be a good solution for this problem.

Speaking of BATV, any implementation on the radar screen? Or a
concrete syntax? At the present time, I only see
draft-levine-mass-batv-00.txt.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Sep 2004 09:48:55 +0200

On Tue, Sep 21, 2004 at 04:53:11AM +0200,
 Frank Ellermann <[email-masked]> wrote 
 a message of 73 lines which said:

> Maybe I'd even implement it this way, if a sender policy has no word
> starting with a "-" or a "redirect" stop the evaluation as waste of
> time (yes, that violates several MUST in protocol-03, but I could do
> it before calling check_host()).

Anyone can implement stupid policies on his own site. One can add an
implicit -all at the end, he can assume a "a/24 mx/24 -all" if there
is no SPF record, he can reject SPF records that are too lax
(ip4:0.0.0.0/0), he can use a badly-managed blacklist, he can have
frivolous requirments (like asking for a PTR record), etc. That's the
freedom you have on the Internet. You are never forced to accept mail,
you can require any criteria you want.

But it is one thing to have this freedom and it is another thing to
ask for a sanctification of these stupid policies in a RFC on the
standards track.
 
> SPF started in January 2004, and so far the number of unexpected
> side-effects appears to be minimal.

Because very few domains publish SPF and even less test it (and it is
often for information only, without rejections). And the current users
are quite knowledgeable about email. When SPF will become widely
deployed, you will see the "unexpected side-effects".

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Sep 2004 09:34:35 +0200

On Mon, Sep 20, 2004 at 10:27:47PM +0200,
 Frank Ellermann <[email-masked]> wrote 
 a message of 29 lines which said:

> But I'd never remove or change a -all, there are better options.

Do what you want. My idea was not to constrain you but to free the
others :-)

> SPF without -all is a complete waste of bandwidth and time.

With ?all, you never have FAIL but you still have the PASS, which are
important for my whitelists.

If -all becomes mandatory, I will certainly *not* deploy SPF. I do not
want my "~/.forward" to break suddenly (and if you say that I should
switch from forwarding to remailing right now, I would reply they have
different semantics, specially when the mail cannot be
delivered. Without any real deployment of SRS or BATV - which are only
proofs of concept at this time - I will *not* use -all.)

The rest is a bit off-topic:

> [some remarks about RfC 3865 censored, because this would cost me
> the write access to MARID].

I cannot speak for the MARID Police but, since RFC 3865 "A No
Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension"
talks about a related issue, informed opinions on RFC 3685 may be
useful to MARID, specially if you talk about how it combines with
MARID.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Sep 2004 02:36:40 -0700

> MTA returns the mail to me.  That's IMHO working as designed.

The MTA may check the MAIL FROM prior to use and not always as a
condition of receipt.  There could easily be MTAs within the path that
do not implement this scheme.  An MTA administrator wishing to reduce
bounce traffic could drop messages that appear spoofed, and get it right
fairly often at the cost of reliability.  The alternative alias solution
you suggest was to leave the record open for reliable delivery, but this
record will attract those wishing to spoof in this brave new world. 
When there is also a reputation service using this identity, then even
the "reliable" method may not work. : (

To overcome this problem, make the MTA authorization a separate
operation from the mailbox domain/mail channel association.  Then the
use an open association record would not invite spoofing and retain the
reputation of such an open record.  This record can remain reliable in
all cases.  The recipient could be notified when the message was outside
the mail channel without needing to reject the message.  The recipient
would also know where the message originated by way of a validated MTA
name.  These identity relationships should not take an intelligent
filter long to recognize (or a human for that matter).

> at least one backup MSA, or at least I found that this is a

But with SPF, there are now two new reasons for needing a backup email
address.  Neither of these reasons are necessary to achieve the goal of
indicating which messages are within the nominal mail channel.  I would
expect only financial institutions would close their records and cause
some mail to either be rejected or go missing in an effort to fight
phishing.  I would also expect this painful mode would be a temporary
fix pending a widely deployed signature solution. 

> indirectly by modifying "-all" to something else.

If your network provider protected their address space and transparently
intercepted port 25 traffic, then you may not have a choice which MTA is
used.  Depending upon your location, there may not be many
alternatives.  The problem SPF creates by using addresses is your
reputation is on the line, and not the provider's.  If your domain gets
blocked as a result, even going to a new provider will not overcome the
problem.  If you were using two providers, as you say you do, then
knowing which of these providers caused your dilemma may not be obvious
to you.  

> mail to this 3rd MX, then I'd do it directly.

Again, you may not be allowed that option for good reasons.

> than one problem, spf2.0/mfrom fixes only one of the problems.

"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."  As not everything will change overnight, closed
records are not practical for describing the mail channel relationship
with a mailbox domain.  Providers will not want to retrain customers,
they will not want to deal with rejected messages or a slew of lost
messages.  The mail channel association with mailbox domain should be
seen as informational for a long time to come.

A closed record is practical immediately for describing the addresses
used by a specific MTA referenced by the MTA name.  To then describe
either a restrictive or informational mailbox domain to mail channel
relationship only requires a safe and simple name list.  The scope of
this list can easily include both the From and MAIL FROM (even the PRA
if the application tanks).    

> only publish a sender policy with "-all".  No new MTA.

Does that not run the risk of adding credibility to those that manage to
spoof this check?  Not checking within the channel makes spoofing
relatively simple in many cases.  

> and without a chance to get a FAIL the receiver has no reason

But the use of "-all" is not without a cost.  When the goal defined by
the charter is taken seriously, then using a closed record is vital. 
The question is which record can be safely closed, and which record
should be expected to remain open.  The mail channel can not be closed
by many providers for practical reasons.  These are systems that make it
simple for the average user to send messages and where the provider can
detect and block a spammer but does not offer mailboxes.  The return
path can not be expected to hold a relationship with with the sending
MTA in every case without making wrenching changes to the way mail is
used. 

> I'm not sure if that's only meant to derail SPF or create FUD.

I have listed the security and reputation problems that will exist with
the SPF approach.  This is not to dismiss the goals of MARID with FUD. 
The goals of MARID can be achieved.  The mailbox domain/mail channel
relationship can not be described using addresses safely.  It can be
done using MTA names however.  Let's achieve the goal with the safest
and simplest solutions.  Above all, let's achieve the goal safely.

-Doug

---

From: David Woodhouse <[email-masked]>
Date: Tue, 21 Sep 2004 11:59:10 +0100

> draft-levine-mass-batv-00.txt.

Largely the point is it's unilateral so you don't _have_ to have an
agreed syntax. I've had an implementation purely in Exim configuration
since February -- http://david.woodhou.se/eximconf/include/routers-ses

Currently that stops the backscatter, and it stops fakes being delivered
to anyone who actually does SMTP sender verification callouts. It's been
suggested that we could implement a stunt DNS server and publish an SPF
record using 'exists' to get potential recipients to verify the
localpart that way, but I haven't bothered yet.

-- 
dwmw2