On Monday, August 30, 2004 1:15 PM, mazieres(_at_)gmail(_dot_)com
[mailto:mazieres(_at_)gmail(_dot_)com] wrote:
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"?
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
postmaster(_at_)example(_dot_)com or
mailer-daemon(_at_)example(_dot_)com(_dot_) See example 5.5 of
the SUBMITTER spec.