Subject: RE: DOC-BUG: permitted use of PRA/submitter address

From: "Harry Katz" <[email-masked]>
Date: Mon, 30 Aug 2004 17:56:18 -0700

On Monday, August 30, 2004 1:15 PM, [email-masked]
[mailto:[email-masked]] wrote:

> On Mon, 30 Aug 2004 11:43:20 -0700, Harry Katz 
> <[email-masked]> wrote:
> > 
> > 
> > On Sunday, August 29, 2004 4:34 PM, [email-masked] wrote:
> > 
> > > It's hard from the current drafts to figure out when 
> exactly it is 
> > > appropriate to send mail to the PRA of a received mail message...
> > > ...
> > 
> > The PRA doesn't replace or over-ride any of the semantics 
> around mail 
> > replies or notifications.  It is intended only as a mechanism to 
> > identify the entity most recently responsible for injecting the 
> > message into the mail system.  If you normally send a bounce to the 
> > 2821 MAIL FROM address, you would continue to do so.  If 
> you normally 
> > send a reply to the 2822 From or Reply-To address, you 
> would continue to do so.
> > 
> > Section 4.2 of the submitter-03 draft has the following paragraph 
> > which addresses, at least in part, this very issue.
> > 
> >    Note that the presence of the SUBMITTER parameter on the 
> MAIL command
> >    MUST NOT change the effective reverse-path of a message.  Any
> >    delivery status notifications must be sent to the 
> reverse-path, if
> >    one exists, as per section 3.7 of [SMTP] regardless of 
> the presence
> >    of a SUBMITTER parameter.  If the reverse-path is null, delivery
> >    status notifications MUST NOT be sent to the SUBMITTER address.
> 
> One problem may be that when I read the words "delivery 
> status notification", to me that has a very specific meaning 
> (in the sense of RFC1891).  Is that paragraph also supposed 
> to cover auto-generated messages of the form "I'm on vacation 
> and will read your message next week," or "Your attachment 
> contained a virus and has been removed"?

The above paragraph deals with DSNs.  It could perhaps be amended to
also include replies and auto-responder messages.  I think this
clarification isn't significant enough to warrant a rev of the spec, but
I'd certainly be willing to bundle it up with other changes if a future
rev is required.  

> 
> It also still doesn't address the question of whether the PRA 
> must be a valid email address.  I'm assuming that if the 
> email address does exist, then the domain in the PRA is 
> considered to offer mail service and must have RFC2142 
> mailbox names like abuse and postmaster.  I don't see 
> anything in the drafts that prevents someone from using the 
> PRA simply as a non-functioning syntactic placeholder or 
> level of indirection for authentication.  (And of course, if 
> I were a spammer, I certainly wouldn't be interested in 
> setting up a working PRA.)

Correct. The PRA is derived from 2822 headers so the validity of the PRA
address is likewise derived from the validity of those addresses.  I
expect the PRA to be a valid delivery address in the vast majority of
(legitimate) cases, however, I do not believe this can or should be a
requirement in the spec.  See below for examples.  

> 
> I guess I'm particularly curious what people think about 
> virus notifications.  (I care a lot about this question 
> because at times I get thousands of messages a day telling me 
> my mail has been infected with a virus, when of course I 
> didn't send the virus, but rather the virus forged my email 
> address.)  It seems to me that if you get mail with a virus, 
> the person whose machine is infected is most likely the PRA, 
> not the MAIL-FROM address.  Therefore, I would be tempted to 
> configure my mail filter to send automatic notifications to 
> the PRA, instead of the MAIL-FROM address.  So the questions are:
> 
> 1. Is there anything in the drafts to prevent me from sending 
> such notifications to the PRA?

No.  However the PRA is neither a bounce address, nor a reply-to
address.  And since the PRA only identifies the responsible sender of
the most recent "hop" I think you cannot assume the virus originates
from the PRA address.  

> 
> 2. Is the PRA required to exist/accept such notifications.  
> Should the PRA be a human rather than an autoresponder?

No.  The PRA could easily be the address of an application that sends
but does not read mail.  In fact, example 5.4 of the SUBMITTER spec
contemplates exactly this in it's use of a generic service account on
the SUBMITTER parameter. 

> 
> 3. Is the PRA required to accept mail from the empty envelope 
> sender, even through any RFC1891-type DSNs/bounce messages 
> should still be sent to the MAIL-FROM address?

Not sure I understand this question.  However, when an MTA sends a DSN
with MAIL FROM <>, the PRA would typically be something like
[email-masked] or [email-masked].  See example 5.5 of
the SUBMITTER spec.

---

From: <[email-masked]>
Date: Mon, 30 Aug 2004 22:06:48 -0400

> the most recent "hop" I think you cannot assume the virus originates

Okay, so basically is it the case that Sender ID (in its present form)
isn't designed to help with these kinds of viruses and virus
notifiers?  At this point, is there any possible action the MARID
group could take that would allow more intelligent virus rejection?  I
care a lot about this problem, and was hoping the outcome of this
working group could help.

If addressing the virus/bounce problem is no longer within scope, I
don't want to dwell on the issue.  However, I hope that at least
people have such extensions in mind for future work.  The fact that
SPF2 records have a ver-ext  field is a good sign.  (However, I wonder
why not make pra a required extension, instead of part of the version
string, so that version strings like "spf2.0/blah,pra" would also be
acceptable.  Not very important, though, just means there will be a
slight asymmetry if extensions become common.)

> contemplates exactly this in it's use of a generic service account on

Okay, from the example, I didn't know what
[email-masked] was supposed to mean.  guest.services
sounds kind of like a help desk address, so it could be interpreted to
mean the help desk is essentially lending their address to guests.

I guess I object to the term "generic account".  If guest.services
isn't a real mailbox, then I would argue it's not an account either.

The reason I think this stuff is worth clarifying is for sites like
rfc-ignorant.org that publish lists of domains that fail to supply
mailboxes for various addresses like abuse and postmaster.   I now
gather that the intent of these drafts is that someone who uses an
invalid mailbox (including a mailbox with an invalid domain) as a
submitter is NOT in fact "RFC-ignorant."

> [email-masked] or [email-masked].  See example 5.5 of

Sorry, my question was about receiving, not sending bounces.  Let me
elaborate.  Suppose I have two email addresses:

[email-masked]
[email-masked]

Because of the number of bounces I get from viruses, the address
[email-masked] does not accept DSNs.  Therefore, I always use
[email-masked] as the envelope sender.

So far so good.  The next question is which address I should use as
the PRA.  If I don't do anything, the PRA will be [email-masked],
which I would probably prefer.  However, given that that address
refuses DSNs, the question is whether there would be grounds for
listing me in the rfc-ignorant RBL:

http://www.rfc-ignorant.org/policy-dsn.php

David

---

From: Greg Connor <[email-masked]>
Date: Mon, 30 Aug 2004 22:42:35 -0700

>> the most recent "hop" I think you cannot assume the virus originates

To add to what Harry is saying, remember that the PRA can often be an 
address affiliated with the receiver's forwarding arrangement, and nothing 
to do with the sender at all.  For example, if all my mail is forwarded via 
pobox.com, then the authenticated PRA will probably be [email-masked] 
for all my mail, even mail that was received without an authenticated PRA 
by pobox.

For this reason (and taking into account what Harry said too) I would not 
want Sender ID to have anything to do with where notifications go (except 
to say "do not send notifications to PRA that should not be used for DSN, 
virus warnings, auto-replies, vacation messages or whatever).

> slight asymmetry if extensions become common.)

I think that Sender ID will be good for detecting and blocking spoofed 
messages (including viruses) but that should not extend to providing 
accurate trace-back. At least not in its current form.

The current rev of Sender ID only identifies one PRA and is focused on a 
single hop.  It doesn't define a way to trace back the chain of hops all 
the way.  However, I could see something like that happening in a future 
extension.

For example,
  if (the PRA is checked and valid)
  *and* (PRA is an entity that the receiver knows and trusts)
  then {
      scan for the Received lines added by the trusted forwarder
        find the previous IP address recorded by that agent
      scan the message from that point down to find/validate 2nd PRA
  }

I am willing to bet that a large chunk of mail I receive could be validated 
this way to verify the From: or Sender: even if the Sender ID would not 
otherwise work this way.  BUT all this hinges on how well you trust your 
agents (such as mailing lists, which are acting as agents for the sender 
*and* the receiver :) so it's probably too much to ask the current rev of 
Sender ID to work this way.

Even if we do all that we probably still don't have enough info to trace 
back a virus to its true owner, especially not a deliberately forged one. 
But hopefully blocking them is added incentive for people to publish their 
Sender ID info so that their domain won't be abused as often...

> http://www.rfc-ignorant.org/policy-dsn.php

I don't have a direct answer to this, but remember that the PRA *always* 
appears in some 2822 header before it is picked out by this algorithm.  So, 
if you use some non-functioning address in your outgoing mail as either 
From:, Sender:, Resent-From: or Resent-Sender: there may already be rules 
that cover those types of uses.

My opinion is that Sender ID should probably not make any attempt to say 
whether this is legal or not, because it would probably be different 
depending on which header was the source of the PRA.  But, if there are 
already some rules in 2822 or 2476 that say stuff about these headers, we 
could make a reference to them.

--
Greg Connor <[email-masked]>

---

From: Greg Connor <[email-masked]>
Date: Mon, 30 Aug 2004 22:42:35 -0700

For example,