ietf-mxcomp
[Top] [All Lists]

Re: DOC-BUG: permitted use of PRA/submitter address

2004-08-30 13:14:42

On Mon, 30 Aug 2004 11:43:20 -0700, Harry Katz
<hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> wrote:


On Sunday, August 29, 2004 4:34 PM, mazieres(_at_)gmail(_dot_)com 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"?

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.)

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?

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

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?

David