ietf-mxcomp
[Top] [All Lists]

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

2004-08-30 19:06:46

On Mon, 30 Aug 2004 17:56:18 -0700, Harry Katz
<hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> wrote:
On Monday, August 30, 2004 1:15 PM, mazieres(_at_)gmail(_dot_)com
[mailto:mazieres(_at_)gmail(_dot_)com] wrote:

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.

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

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.

Okay, from the example, I didn't know what
guest(_dot_)services(_at_)email(_dot_)hotel(_dot_)com 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."

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.

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

me(_at_)myschool(_dot_)edu
me-bounces-2004(_at_)myschool(_dot_)edu

Because of the number of bounces I get from viruses, the address
me(_at_)myschool(_dot_)edu does not accept DSNs.  Therefore, I always use
me-bounces-2004(_at_)myschool(_dot_)edu 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 me(_at_)myschool(_dot_)edu,
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