ietf-mxcomp
[Top] [All Lists]

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

2004-08-30 11:43:20

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.  I'm guessing this is because the authors are 
relying on previous RFCs for this.  However, given that a lot 
of people are already confused by the distinction between 
envelope and From: address, there is a danger that the 
introduction of a third address would lead to an even larger 
number of broken vacation-type programs.

I'd like to suggest that the Sender ID (or maybe the PRA or 
SUBMITTER) document have somewhere a non-normative paragraph 
that clues people in to how they can learn about appropriate 
uses of the PRA.  As an example, here are a bunch of 
questions whose answers are not immediately obvious from 
reading Sender ID and associated drafts:

* Is it ever actually required that the PRA be a valid mailbox?  Is it
  legal to construct some mailbox whose domain has an SPF2 record but
  not an MX or A record?  I presume the answer is no, but that the
  logic involves some other RFC I'm just not looking at.  How would
  you go about convincing an administrator this is wrong.

* I am on vacation, and receive mail which lists my own address in the
  To: or CC: fields, and does not have any indications such as
  "Precedence: list/bulk/junk" that it is from a mailing list.  I wish
  for my filter to notify the sender that I will not be responding for
  a week.  Should I send the notification to the MAIL-FROM address, as
  I currently do, or to the PRA?

* I receive mail with an attachment that contains a virus.  I wish to
  configure my MUA or spam filter automatically to notify the sender
  that his/her machine has a virus and the attachment has been
  deleted.  Should I send mail to the PRA?  Can/should that mail come
  from the empty envelope sender, or should/must it come from my real
  email address?

* I have been erroneously subscribed to a mailing list.  Should I
  complain directly to the PRA?  Should I attempt to form a new
  address by appending "-owner" or "-request" to the local part of the
  PRA?  Or should I complain to an address based on the envelope
  sender, as I currently would.

* I receive offensive and/or threatening mail from someone, and wish
  to complain to their administrator.  Should I complain to
  postmaster/abuse at the domain name in the PRA, as opposed to the
  domain in the From or envelope sender address?

* In order to reduce spam, I currently perform an SMTP callback on the
  envelope sender of mail, ensuring that any mail I accept could have
  been bounced.  (This is highly effective against spam from
  virus-infected machines, because many machines infected by viruses
  can make outgoing TCP connections but not accept incoming ones, and
  thus are forced to use other people's often invalid envelope
  senders.)  In case of forgery, people can block these callbacks by
  using SPFv1 records.  Once we have Sender ID, should I instead
  perform SMTP callbacks to validate the SUBMITTER or PRA address
  rather than MAIL-FROM, so as to avoid wasting bandwidth of sites
  whose addresses are being forged?

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.