RE: The open relay problem.

Hi,

 I've been thinking a lot about the "universal-SRS" idea and am
 definitely warming to it.

 However I just noticed something else that it could break.

 Suppose I have an address like [email protected] (which I do), and
 suppose I forward mail from there to [email protected] (which I
 also do).

 Now suppose I chose to send mail so that it appeared to be "From"
 [email protected] (which I do very occasionally), and suppose that I
 sent this through an MTA which is authorised for "brown.name" in what
 ever way is appropriate (e.g. SPF) (which I don't think I can for
 brown.name, but I definitely can for some other forwarders),

 And suppose that this mail I send results in a DSN that I really want
 to see.
 It will get to the authorised MTA address for [email protected]
 (possible wrapped up in SRS if the MTA does that) and the MTA will
 forward it to [email protected].  But obviously that MTA cannot
 wrap the to address in an SRS that we will accept, so my (cse) MTA
 will get Mail From:<>, Rcpt to:<[email protected]> and my MTA
 might feel inclined to reject it. Which I would rather it didn't.

 Now, for myself, I can just always send mail from my primary email
 address.  I don't have a problem with that.  But I don't think I can
 enforce that on all my customers.
 And that means that even if I use SRS on all outgoing mail, I cannot
 require it on all incoming DSN mail.

 One way around this that I can see is to encourage forwarders to
 rewrite <> addresses as (say) [email protected] when forwarding.
 Then the mail would be accepted.  

 And given that avoiding the requirement that forwarders rewrite the
 return address was one of the motivations for universal SRS, this
 doesn't seem helpful.

 The only alternative that occurs to me is to require local addressees
 to register any forwarders that forward to them, so that mail from
 those forwarders gets white-listed.  This alternative has the benefit
 of being completely local (I don't depend on the behaviour of other
 sites), and handles both sides of the forwarding problem (forwarded
 originals and forwarded bounces).  It is hardly low-impact though.

 Comments?

NeilBrown