ietf-mxcomp
[Top] [All Lists]

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

2004-08-30 22:42:28



--mazieres(_at_)gmail(_dot_)com wrote:


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.


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 gconnor(_at_)pobox(_dot_)com 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).


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


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



> 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


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 <gconnor(_at_)nekodojo(_dot_)org>