Subject: RE: TECH-OMISSION: Legal liability for creating bounces fromforgedmessages

From: "Jim Lyon" <[email-masked]>
Date: Fri, 27 Aug 2004 14:48:21 -0700

On Thursday, August 26, 2004 at 4:20 PM, Mark Shewmaker wrote (regarding
the need to generate a DSN if 7 conditions hold): 

> Perhaps it's a corner case in legitimate mail, but legitimate mail is
> not my main concern; I'm more worried about from the standpoint of it
> opening up an exploitable vulnerability, and two problems that can
> result from spammers exploiting that vulnerability:
> 
> 1.  Spammers will get their bounce message spams to a bunch of
victims,
>     using the exploited machine.  (Any individual victim's machine
could
>     of course avoid this threat by implementing SES.)
>
> 2.  The exploited machine will become known as a source of bounce
spam,
>     and be added to domain-based blocklists.
>
> (1) is bad in and of itself, but (2) means that if someone doesn't
like
> you or your machine, that they'll be able to get you black-listed.

I think that the Internet community (not just the MARID group) needs to
hold a larger discussion on exactly when one should or should not
generate a DSN, and on what culpability one incurs by generating a DSN
for a forged message.

Unless and until that discussion occurs, I would suggest:

1. Employ SES or equivalent at your own site, to avoid suffer from
received bogus bounces.
2. Reputation systems are probably on shaky ground black-listing sites
because of generated DSNs.
3. Sites should use their own judgment in whether to generate a DSN or
silently discard messages
   that they believe are forged.

Each of these is (at least arguably) in the self-interest of the party
that makes the decision.

> The only way to solve this problem would be to allow for an override
of
> the must-accept-100-recipients requirement in RFC 2821.

True. This would help, and is probably a good idea. But it's outside the
scope of MARID.

> You can't completely avoid this problem through the addition of
> classic-SPF test, and you can't completely avoid it with SES, (though
> the recipients could.)

Agreed.

> And that was the point of my email that you responded to:  The only
way
> to completely avoid this blow back vulnerability that shows up in the
> no-SUBMITTER case, (other than silently dropping the email), is to
give
> a transient "too many recipients" error upon the first recipient with
a
> differing PRA white-list, if you haven't verified that the Return Path
> is legitimate.

Yes, I understand now.  And it demonstrates that SUBMITTER has some
usefulness other than just as an optimization.

-- Jim Lyon

---

From: Mark Shewmaker <[email-masked]>
Date: Fri, 27 Aug 2004 19:45:03 -0400

On Fri, 2004-08-27 at 17:48, Jim Lyon wrote: 
> > of the must-accept-100-recipients requirement in RFC 2821.
> 

If we can't solve the problem within the scope of MARID, that would
leave us with requiring complying implementations to open themselves to
what I consider a security hole.

However, I just realized that I made a mistake that's caused me to frame
the issue incorrectly, and this leads to a solution that I hope is
within the scope of MARID.

Here is my original objection, shortened considerably, written such that
it includes my mistake:

    1.  RFC 2821 says we must accept-and-deliver, reject, or send DSNs.
    2.  RFC 2821 also says we need to accept at least 100 recipients.

    But if we accept recipients with differing white lists, and we obey
    (1) and (2) above, we expose ourselves to a vulnerability in the
    7-conditions case 

    The only solutions to that are to violate either (1) or (2).

    I don't like the notion of violating (1), as I consider it
    lying/deceitful behavior, so I would prefer to violate (2).

    So I would like something in SenderID that says it's okay
    to violate (2) in this case.

My error was that requirement (2) isn't what I thought and stated
above.  Quoting RFC2821:

   |recipients buffer 
   |   The minimum total number of recipients that must be buffered is
   |   100 recipients.  Rejection of messages (for excessive recipients)
   |   with fewer than 100 RCPT commands is a violation of this
   |   specification.

But we wouldn't be rejecting messages because there are excessive
recipients, we'd really be rejecting them because they are, well,
incompatible recipients.

A fine distinction, perhaps, but I take it to mean that we can reject at
the first recipient with a differing white list, and not only would we
not be in violation of RFC 2821, we'd not have to have Sender ID
overrule this section of RFC 2821 either.

Just instead of claiming the reason being a "too many recipients" error,
claim something more appropriate to for a recipient filtering
incompatibility problem, maybe a 4.7.0 perhaps.  (I'm not sure what
would be the most appropriate response code.)

So, is that suggestion something that could be included within SenderID,
perhaps in a security-considerations section?  Or perhaps a
best-current-practices document?

Otherwise we're effectively suggesting that folks open themselves up to
an avoidable vulnerability without pointing out how it's avoidable.

-- 
Mark Shewmaker
[email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Sat, 28 Aug 2004 21:26:27 -0400

On Aug 27, 2004, at 7:45 PM, Mark Shewmaker wrote:

> perhaps in a security-considerations section?

For clarity, can you give the text you would like included in the 
security section?  I think this would better help in understanding the 
problem and better help people formulate an opinion.

-andy

---

From: Mark Shewmaker <[email-masked]>
Date: Mon, 30 Aug 2004 18:51:53 -0400

On Sat, 2004-08-28 at 21:26, Andrew Newton wrote: 
> > So, is that suggestion something that could be included within 
> > SenderID, perhaps in a security-considerations section?
> 

Sure.

=====================================================================

6.5 Vulnerability to unintended participation in Forged DSN attacks.

This vulnerability exists if local policy settings allow for a situation
in which all of the following are true:

  -  An incoming message was sent to multiple recipients,
  -  The message will ultimately be considered deliverable to some
     subset of its intended recipients,
  -  The message will also be ultimately be considered undeliverable
     to some other subset of the initial recipients, and
  -  The ultimate determination as to per-recipient deliverability
     cannot be made until after the SMTP transaction accepts the
     message for delivery.

Normally a delivery status notification would be sent to the given MAIL
FROM address, notifying it of the undeliverability of the message for
its specific intended recipients.

However, if the MAIL FROM address is forged, an innocent third party
will be the recipient of this delivery service notification.

A clever attacker can take advantage of this vulnerability by using any
machine with detectably differing local policy settings as an apparent
source of the attacker's forged DSNs.

Not only does this mean the ultimate victims will receive forged DSNs,
but the machine the attacker used to accomplish the forgery may become
known as a source of forged DSNs.

An MTA can completely avoid becoming a participant in a DSN attack in
all cases by:

  Whenever all of the following is true:

  -  An incoming message is addressed to multiple participants.

  -  Those participants have local policy settings that,
     given the context of the specifics of the MTA transaction,
     mean that a per-recipient final determination of delivery
     cannot be made until after the message has been fully accepted.

  -  The MTA has not positively validated the MAIL FROM address,

  Then:

  -  The MTA should give temporary rejections at "RCPT TO:" time
     to all recipients with differing local policy settings and where
     the recipients have not already been temporarily or permanently
     rejected for other reasons, (and where the local policy setting
     difference can cause differing determinations of ultimate
     deliverability), thus accepting only a compatible subset of
     recipients and avoiding the need to create DSNs at all.

     It is suggested that the MTA reject these recipients with a
     return code of 4.7.6.

     (Note that the MTA is not rejecting on the basis of too many
     recipients, rather it is rejecting on the basis of a
     security-related incompatibility in the requested recipient list.)

Given special-case conditions, there are simpler, alternative ways an
MTA can completely avoid becoming a participant in a DSN attack:

-  If the client MTA sends a "SUBMITTER" parameter to the MAIL command,
   then no per-recipient policy that addresses functionality related to
   this standard can trigger this vulnerability.  If per-recipient
   policy settings only extend to functionality related to this 
   standard, then the above recipient-rejection workaround need not be 
   used for that SMTP transaction.

-  If the server MTA obtains positive validation of the MAIL FROM
   address for a particular SMTP transaction, then for that SMTP
   transaction the server MTA need not use the recipient-rejection
   workaround given above.

-  If a future SMTP extension allows for per-recipient after-DATA
   rejects, and an SMTP session makes use of such an extension, then
   the above workaround is not needed for that session.

Avoiding the receipt of forged DSNs is generally outside the scope of
this document, however a domain that signs outgoing messages in a
recognizable way can avoid at least some types of forged DSN attacks.

=====================================================================

After writing all that, (and after seeing Chris Hayne's similar proposal
which he sent earlier today), I'm actually starting to rethink my position
as to whether this workaround should be listed within core at all.  (!)

The reason is that in addition to affecting Sender ID, the above vulnerability
affects the general case of content-based filtering, so I'm wondering if something
like the above would be better placed in a more general BCP as opposed to just
being included within Sender ID.

For the moment I'm not sure how to answer the above question.

I think the warning/workaround needs to be *somewhere*, but whether it should
be in core or in a more BCP, or both, I'm not sure:

  o  If it should be in core, then I want to push for something like
     the above.

  o  If it should be in a BCP, well, then I'll push for it there,
     (although I'm not clear on how to go about that.)

As the above question doesn't much change the existence of the vulnerability 
and the necessity of the workaround though, I still submit my wording above
for discussion, dissection, and joyful mutilation.

-- 
Mark Shewmaker
[email-masked]

---

From: <[email-masked]>
Date: Mon, 30 Aug 2004 20:35:21 -0400

I strongly support including something along the lines of what you
wrote, either in core or in some BCP document accepted at the same
time.  (Though I have to say the complexity of the explanation makes
me appreciate plain-old SPF-classic a lot more, but I'll stick to
issues that are in scope...)

I just have a couple of comments.

>      cannot be made until after the SMTP transaction accepts the

The last condition is not quite correct, because you can make the
determination before replying to the "." at the end of the DATA
command.  Thus, I would recommend some wording along the lines of,
"The ultimate determination as to per-recipient deliverability cannot
be made before the SMTP DATA command."

> source of the attacker's forged DSNs.

How about dropping the word "clever."  From the point of view of a
standards document, the attacker's intellect is irrelevant.  (Plus, I
would argue this attack isn't really all that clever, particularly
once it's already been described in a standards document.)

>   -  The MTA has not positively validated the MAIL FROM address,

What exactly does positively validated the MAIL FROM address mean,
unless you have something like SPF classic?

Also, I would argue that you don't need to positively validate the
MAIL FROM address.  All you really need to know is that whoever would
get a DSN is somehow involved in the sending of the message.

Thus, one valid test would be to run a tentative check under the
assumption that the MAIL FROM address is actually the PRA.  If the
test returns anything other than Pass or None, of course you don't
reject the mail, but instead, proceed as you outlined below, including
returning a 4.7.6 for multiple recipients.

In the case that the MAIL FROM address does Pass the Sender ID check,
then it is probably okay to go ahead and accept the mail, generating
DSNs later on.  Yes, it's still possible for an attacker to mount a
joe job attack and flood you with bounces.  But the attacker would
need to control IP addresses from which he could use your address as a
PRA, which is a lot harder than mounting the generic attack.

In fact, while I don't fully understand the motivation for having
different PRA and MAIL-FROM addresses, I gather from previous messages
that the people who want this the most are large banks that send out
bulk mail.  Bulk mailers would probably benefit the most from being
able to reach multiple recipients in a single SMTP transaction.

David

---

From: Mark Shewmaker <[email-masked]>
Date: Mon, 30 Aug 2004 23:38:01 -0400

> I just have a couple of comments.

Great!

> command.

Not an ultimate per-recipient determination, unless the answer is
reject-for-everyone.

> Thus, I would recommend some wording along the lines of,

I'm under the impression that those two wordings are currently
equivalent, in that giving a 250 response to the end of SMTP data means
that you've accepted the message for delivery.

The reason I went with more convoluted wording that probably comes to
the same thing at the moment was merely to be compatible with any future
SMTP extension that allows for something I've long wanted--a way to do
post-DATA per-recipient rejects.

So it's sort of a personal bias that was at the root of the convoluted
wording.

Begin Minor rant:  (I hope I'm not stepping too far out of bounds
-----------------  by posting this skim-able rant here.)

If there had been a requirement back in RFC821 for both the client and
server MTAs to support pre- and post-DATA per-recipient rejects, then
we'd not have this vulnerability at all, as MTAs could do separate and
incompatible body checks that differ per recipient, and yet still reject
for individual recipients depending on their individual settings of
acceptable body content.

Unfortunately, not only do we not currently have such an extension at
all, we especially don't have one that can be considered from a
practical point of view as fundamental requirement for SMTP servers.

So for the time being, in order to avoid this security vulnerability,
IMHO MTA's will need to implement this sort of bothersome, burdensome
workaround.

But were an extension supporting post-data per-recipient rejects to come
into being, I would imagine that the larger volume MTAs would put it in
deployment within a couple years, meaning that from a practical point of
view the workaround would become much less burdensome, only needing to
be used when communicating with MTAs that have not (yet) been upgraded,
or MTAs that are trying to perform an active attack, the latter
presumably learning to give up upon getting an EHLO response showing
support of such an extension.

End minor rant:
---------------

So while the implementation of such an extension is beyond the scope of
Sender ID, (though perhaps there are interested parties here that would
want to more appropriately push for such an extension), I was wanting to
use wording that was generic enough to still "fit" were such an
extension ever to come about and be put into use.

Although I don't see much talk of such an extension anywhere, I tend to
think it will come about at some point, and so I wanted to workaround's
wording to be compatible with the sort of thing I expect to later exist.

But a less convoluted way of wording it would be great, or, if folks
think I'm being overly picky by wanting compatibility with something
that doesn't yet exist, your wording is fine too.

> once it's already been described in a standards document.)

Absolutely agreed.

Thanks.

> unless you have something like SPF classic?

It means whatever the admin of the MTA wants it to mean.  :-)

Or even more vaguely, it means whatever that admin wants to use as a
"good enough" algorithm for bouncability.  :-)

I don't think it's a good idea to specify any particular algorithm.

While an SPF pass, an SES CBV verification, and a BATV CBV verification
would presumably all work well, as would a full set of Unified-SPF tests
that included MAIL FROM tests, and as would your excellent idea of a
close-enough test of SenderID testing the MAIL FROM, I'd still rather
not suggest any specific test--we don't now know what the "winning"
methods of bouncability verification will turn out to be, and there's no
need to tie anything down to something that may well become obsolete in
six months.

Testing the validity of a bounce address is a problem that's
theoretically uncoupled with the problem of testing the validity of the
PRA, so I don't want a document that's concerned with PRA tests to have
a security workaround to reference or require specific bounce address
tests.

It's a separate issue that the admin will have to handle, well,
separately.  I just want to mention that for any SMTP transaction where
they think they've validated the bounce address, that this workaround
isn't necessary.

> returning a 4.7.6 for multiple recipients.

That's an excellent idea.

Even though I'm personally biased towards Unified SPF, thinking the PRA
tests and MAIL FROM tests should be able to be scoped differently if the
domain wants, etc., and even though this wouldn't be using the records
quite as intended, from a practical point of view I'd be fine with doing
that test as a "good enough" test myself.

I'm just still not sure if the warning/workaround mentioned should refer
to any specific way of testing the MAIL FROM address.

> bulk mail.

Somewhat off-topic, but here's one reason:  There are some legal
requirements to send some EFT notifications, (and things like those
yearly account-rules-and-conditions-and-information things), that can be
satisfied by emails if you then send paper documents if the email
bounces.  I can see where companies might want to outsource the sending
of notifications like this, trusting the outsourced sender to notify
them of rejects, but yet possibly wanting to handle the bounce
processing separately.  (Or perhaps the outsourced company might want to
do that--having a bounce-handling machine that is set up to handle
bounces for a week after the mail is sent, which might be long after the
originating machine knows anything about the bulk mail sending session.)

-- 
Mark Shewmaker
[email-masked]

---

From: <[email-masked]>
Date: Tue, 31 Aug 2004 00:49:54 -0400

> Not an ultimate per-recipient determination, unless the answer is

Ah, I see the confusion.  By "make the determination", I read decide
whether or not each recipient wants to accept the mail.  I think what
you meant is notify the client of whatever that decision is. 
Basically imagine the following session:

  ==> rcpt to:<[email-masked]>
  <== 250 ok
  ==> rcpt to:<[email-masked]>
  <== 250 ok
  ==> data
  <== 354
  ==> [mail message]
  ==> .

Now the MTA has to decide what to reply to the "." at the end of the
data command.  At this point, even though the SMTP transaction is not
yet complete (still awaiting a reply from the MTA), the MTA has the
entire message body, and thus can certainly determine that user a
wants the mail, and user b doesn't want the mail.  The determination
is made before the end of the SMTP transaction.  The problem is there
is no way to notify the client.

So I think it's clearer to say you can't determine per-recipient
deliverability at the time of the RCPT command, and even if you can
determine it during the DATA command, without another SMTP extension
it is not possible to reject the message for a subset of recipients.

> originating machine knows anything about the bulk mail sending session.)

Sorry, I know this is a bit off topic, but I really wish I understood
this point better.  I understand that the bank and the sender are two
different institutions.  I also understand that whatever part of the
mail is authenticated should end with "bank.com", so that MUAs can
display a golden padlock or somesuch.  What do you mean by "handling
bounce processing separately"?  Presumably this is the major function
of the outsourced sender, so the sender is getting the bounces.

So in a PRA-based scheme, the bank does something like:

    bank.com IN SPF2 "spf2.0/pra ... include:spf2.sender.com -all"

Then mail would go out with:

    Mail-From: [email-masked]
    From: [email-masked]

In a mail-from based scheme, you would need both an SPF or TXT record,
and an MX record (though a single CNAME would work, too).  Something
like:

    sender.bank.com IN MX 10 bounces.sender.com
    sender.bank.com IN TXT "v=spf1 redirect=spf.sender.com"

Now the mail might go out:

    Mail-From: [email-masked]
    From: [email-masked]

Are these roughly the scenarios you had in mind?  If so, is there
really a huge difference between PRA and mail-from?

Is the big objection just the fact that the mail comes from
"sender.bank.com" instead of just "bank.com"?  In practice, it seems
like you might want to do that anyway if you have multiple outsourced
senders, because a screw-up by sender.com, say if spf2.sender.com
doesn't exist, would throw an exception and mess up SPF processing for
all subsequent mechanisms, possibly interfering with other senders.

Maybe what we need is a global modifier "display=domain" that says
what domain to display in the golden padlock.  Obviously domain must
be a suffix of the current domain, but it could be a strict suffix to
avoid confusing users with extra clutter like the "sender" in
"sender.bank.com."  Something like:

    sender.bank.com IN TXT "v=spf1 display=%{d2} redirect=spf.sender.com"

It just seems like mail-from-based schemes could be hugely more
beneficial to virus filtering and joe-job prevention than PRA-based
schemes, while I don't really see a comparable (or any) advantage to
PRA-based schemes.  Probably I'm just missing the actual "killer"
scenario that really requires PRA.

David

---

From: Mark Shewmaker <[email-masked]>
Date: Tue, 31 Aug 2004 05:39:16 -0400

> you meant is notify the client of whatever that decision is. 

<slapping forehead with hand>

Yes, that's exactly what I meant, even though I insisted on wording
which communicated something else.

> The determination

Then let me reword:

  -  A message is sent to multiple recipients,

  -  The recipients have differing local policy settings
     with respect to message body requirements,

  -  An ultimate determination of per-recipient nondeliverability
     cannot be communicated within the SMTP session after the receipt
     of message data, and

  -  The Return Path is forged,

An attacker can take advantage of this vulnerability by using any
machine with detectably differing local policy settings as an apparent
source of the attacker's forged DSNs.

An MTA can completely avoid becoming a participant in this type of DSN
attack by preventing any of the above listed requirements from
occuring.  That is, it could do any of the following:

  -  Disallow some message recipients.
  -  Disallow local policy settings which depend on message contents.
  -  Disable sending of DSNs.

Each option has downsides.  The first option would require addition
message transmission attempts, the second option would limit desirable
functionality, and the third would hide email to become less reliable by
hiding legitimate email problems.

However, the first option is the only one which does not actually limit
mail system functionality, making it the only real option to consider.

To expand upon the first option, an MTA can completely avoid becoming a
participant in this type of DSN attack in all cases by:

  -  Those participants have local policy settings that,
     given the context of the specifics of the MTA transaction
     mean that per-recipient final determinations of nondeliverability
     cannot be communicated until after the message has been accepted
     for delivery.

  -  The MTA has not positively validated the MAIL FROM address to
     its satisfaction,

  Then:

  -  The MTA should give temporary rejections at "RCPT TO:" time
     to all recipients with differing message-body-related local policy 
     settings and where the recipients have not already been temporarily
or permanently rejected for other reasons, thus accepting only a
     compatible subset of  recipients and avoiding the need to create 
     DSNs at all.

Note that this workaround will not prevent DSN attacks if your domain
authorizes messages to be received by any other MTA, such as a border or
secondary MTA, and that other MTA does not do the exact set of checks as
the final MTA or checks more stringent than the final MTA.  The reason
is that when the border MTA relays the message to final MTA, even if it
rejects the message, the border MTA will then create a DSN which would
be sent to an inappropriate party if the Return Path is forged.

This second type of forged DSN attack can be avoided by ensuring that
all other MTAs your domain authorizes to receive mail do the same set of
checks.  Border and secondary MTAs can do a more stringent set of checks
than final MTAs, as long as there is never a relay from an MTA with
less-stringent tests to an MTA with more-stringent tests.

> > processing separately.

> What do you mean by "handling

I was thinking more social (almost dilbertish) reasons as opposed to
reasons borne out of utter technical necessity.

For instance, I was imagining a situation in which one machine is
temporarily set up for a day or so to send semi-secure eft
notifications, after which it is wiped of all the secure-ish info
necessary for the bulk sending, (or the capability to access the
secure-ish info), and then set up for another bulk sending session of
another customer, with the bulk sender or bank or what-have-you making a
big deal about secure wipes or deletions.

And then if you don't need as much secure info to handle bounce
processing, the bounce-handling machine might be another machine
entirely, and thus might be allowed the necessary access longer.

So you might have:

   Mail-From: [email-masked]
        From: [email-masked]

So if you're the big bank in question, and you want to prove to federal
regulators that you're performing your due diligence for the regs, even
though technically clued in people will understand that having separate
bounce-handling machines isn't necessary and is quite possibly
counterproductive, (and causing you to be more likely to make mistakes),
I'm guessing that big bank folks would like to be able to jump up and
down, point at a machine that's dedicated to only receiving bounce
messages, has been doing that exclusively for xxx amount of time, etc.,
"prove" it by talking about bounce addresses, and thus completely
(hopefully) avoid any question about their behavior in that respect.

It's not really logical, and I admit I'm stretching things, but my guess
is that that's the sort of reason people want that sort of difference.

It's just a guess, and it requires marketing-type interests to override
saner technical decisions.  (Though then again I admit having thought of
doing that sort of separate-domain automated bounce processing myself,
merely out of convenience and, err, laziness.)

In any event, the fact that such requirements are so unusual, in the
only situations I could think of, put me squarely in the "keep spf1
semantics, no spf2 strings" camp.

> "sender.bank.com."

To me sender_agents is a better solution to all that.  :-)

(I still need to write that up again for under a TECH-OMISSION
document.)

-- 
Mark Shewmaker
[email-masked]

---

From: <[email-masked]>
Date: Tue, 31 Aug 2004 14:59:52 -0400

>   -  The Return Path is forged,

Okay, better.  I still think it could be clearer because of the
dependence between some of these things.  Also, that the message has
multiple recipients is less important than emphasizing that the
*transaction* has multiple recipients.  How about saying:

  1. The Return Path is forged.

  2. Per-recipient non-deliverability status cannot be communicated
     to the client during the SMTP transaction because

     A. The transaction has multiple recipients,

     B. The recipients have differing local policy settings, some
	allowing and some rejecting delivery of the message, and

     C. The policies are based on message headers or contents
        transmitted to the server during the SMTP DATA command, and
        the SMTP protocol only allows a single success or failure code
        for all recipients in response to the DATA command.

  3. Local policy requires the sending of a DSN for rejected
     recipients of successful SMTP transactions.

> known as a source of forged DSNs.

The term "forged DSN" may be misleading here, because the DSNs
themselves are in a sense genuine, just the message for which they are
generated are forged.  So maybe substitute "maliciously-induced DSN"
for "forged DSN."

>   -  Disable sending of DSNs.

Instead of "Disallow some message recipients", how about:

   - Disallow combinations of recipients with different local policies
     in the same SMTP transaction

> Each option has downsides.  The first option would require addition

addition -> additional

> hiding legitimate email problems.

How about:  "and the third could make email less reliable by hiding
legitimate problems, and would in any case violate section 4.2.5 of
RFC 2821." (done with appropriate citation)

>      security-related incompatibility in the requested recipient list.)

My only potential quibble here is that it might be clearer to describe
this from the point of view of the MTA receiving the message.  For
example, the fact that the message is addressed to multiple recipients
isn't exactly the concern, because the messages might be in separate
transactions.  (For example, I think qmail always uses a separate
transaction for each recipient.)

Something along the lines of:  A server has already accepted one RCPT
TO: command in the current transaction.  The server receives a
subsequent RCPT TO: command.  The mailbox in the second RCPT command
has a different policy from the mailbox in the first command, and at
least one of the policies cannot be resolved until the server has
received the message contents with the DATA command.

> (hopefully) avoid any question about their behavior in that respect.

But this seems entirely compatible with the MAIL-FROM scenario I
proposed.  If you have:

And you send out mail:

Nothing says that the mail has to come from bounces.sender.com.
sender.com can put whatever they want in spf.sender.com, and
bounces.sender.com should map to the IP address (or addresses) of
machines doing bounce processing.

> is that that's the sort of reason people want that sort of difference.

But I still don't get it.  I understand that people might want to do
what you are describing.  What I don't understand is why PRA-based
authentication is more amenable to the task than MAIL-FROM
authentication.

> semantics, no spf2 strings" camp.

Well, then maybe I'm asking the wrong person.  But at this point I'm
thinking there must be something big I'm missing (or else it was
unfortunate to move from SPF to Sender ID).  On the other hand, since
the big advantage of SPF over Sender ID is virus (and joe job)
prevention, and since Microsoft is both one of the big proponents of
PRA and one of the biggest targets of virus writers, I'm thinking
there's probably a pretty good reason for wanting Sender ID over
SPF-classic.  I'd just like to understand that reason myself...

David