Re: Language too strict in draft-ietf-marid-mailfrom-00

On Mon, 2004-09-20 at 19:53, Frank Ellermann wrote:
> Douglas Otis wrote:
> 
> > You would not know which alias to use to overcome a problem
> > that can not be known in advance. : (
> 
> Not sure what you're talking about.  Let's say that I send a
> mail to somebody AT infradead mentioned here in other threads.
> 
> The receiver forwards this to a 3rd party without changing my
> MAIL FROM.  The 3rd party says "you are not allowed to forge
> xyzzy addreses" and refuses to accept the mail.  Infradead's
> MTA returns the mail to me.  That's IMHO working as designed.

The MTA may check the MAIL FROM prior to use and not always as a
condition of receipt.  There could easily be MTAs within the path that
do not implement this scheme.  An MTA administrator wishing to reduce
bounce traffic could drop messages that appear spoofed, and get it right
fairly often at the cost of reliability.  The alternative alias solution
you suggest was to leave the record open for reliable delivery, but this
record will attract those wishing to spoof in this brave new world. 
When there is also a reputation service using this identity, then even
the "reliable" method may not work. : (

To overcome this problem, make the MTA authorization a separate
operation from the mailbox domain/mail channel association.  Then the
use an open association record would not invite spoofing and retain the
reputation of such an open record.  This record can remain reliable in
all cases.  The recipient could be notified when the message was outside
the mail channel without needing to reject the message.  The recipient
would also know where the message originated by way of a validated MTA
name.  These identity relationships should not take an intelligent
filter long to recognize (or a human for that matter).

> I could fix this problem by using a MAIL FROM de.clara.net or
> another mailer (today with all these BLs around we all have
> at least one backup MSA, or at least I found that this is a
> MUST HAVE).

But with SPF, there are now two new reasons for needing a backup email
address.  Neither of these reasons are necessary to achieve the goal of
indicating which messages are within the nominal mail channel.  I would
expect only financial institutions would close their records and cause
some mail to either be rejected or go missing in an effort to fight
phishing.  I would also expect this painful mode would be a temporary
fix pending a widely deployed signature solution. 

> But I wouldn't authorize the ill-behaved MTA to use my address,
> neither directly by adding this MTA to "my" sender policy, nor
> indirectly by modifying "-all" to something else.

If your network provider protected their address space and transparently
intercepted port 25 traffic, then you may not have a choice which MTA is
used.  Depending upon your location, there may not be many
alternatives.  The problem SPF creates by using addresses is your
reputation is on the line, and not the provider's.  If your domain gets
blocked as a result, even going to a new provider will not overcome the
problem.  If you were using two providers, as you say you do, then
knowing which of these providers caused your dilemma may not be obvious
to you.  

> That's not how I understand SMTP, for me the MX is meant as the
> gateway to the receiver.  It can forward, and relay, and do
> whatever it wishes, but it _must not_ say MAIL FROM xyzzy while
> talking with the MX of a 3rd party.  If I'd wanted to send my
> mail to this 3rd MX, then I'd do it directly.

Again, you may not be allowed that option for good reasons.

> Okay, it may change common practice for some systems, and it's
> obviously different from what Dave said, but OTOH we're here in
> MARID because there _is_ a problem with SMTP.  Or rather more
> than one problem, spf2.0/mfrom fixes only one of the problems.

"The primary current use case for this facility is to allow recipient
MTAs to confirm that peer MTAs' actions are authorized by specific
domains or networks."  As not everything will change overnight, closed
records are not practical for describing the mail channel relationship
with a mailbox domain.  Providers will not want to retrain customers,
they will not want to deal with rejected messages or a slew of lost
messages.  The mail channel association with mailbox domain should be
seen as informational for a long time to come.

A closed record is practical immediately for describing the addresses
used by a specific MTA referenced by the MTA name.  To then describe
either a restrictive or informational mailbox domain to mail channel
relationship only requires a safe and simple name list.  The scope of
this list can easily include both the From and MAIL FROM (even the PRA
if the application tanks).    

> > I would expect BATV will be a good solution for this problem.
> 
> In theory it could be, but spf2.0/mfrom is something working
> today with my MUA and my ISP.  They didn't have to do anything,
> only publish a sender policy with "-all".  No new MTA.

Does that not run the risk of adding credibility to those that manage to
spoof this check?  Not checking within the channel makes spoofing
relatively simple in many cases.  

> Spf2.0/mfrom also offers something for the receiver, the MX can
> reject all FAILs.  That's also the reason why there SHOULD be a
> "-all" in sender policies:  Without "-all" or similar without
> any FAIL mechanism at all, why should the receiver bother to
> evaluate the sender policy ?  SPF is a voluntary cooperation
> between the (author of the) sender (policy) and the receiver,
> and without a chance to get a FAIL the receiver has no reason
> to cooperate.

But the use of "-all" is not without a cost.  When the goal defined by
the charter is taken seriously, then using a closed record is vital. 
The question is which record can be safely closed, and which record
should be expected to remain open.  The mail channel can not be closed
by many providers for practical reasons.  These are systems that make it
simple for the average user to send messages and where the provider can
detect and block a spammer but does not offer mailboxes.  The return
path can not be expected to hold a relationship with with the sending
MTA in every case without making wrenching changes to the way mail is
used. 

> Maybe I'd even implement it this way, if a sender policy has no
> word starting with a "-" or a "redirect" stop the evaluation as
> waste of time (yes, that violates several MUST in protocol-03,
> but I could do it before calling check_host()).
> 
> > It could be this assumption of acceptable losses holds
> > because far fewer use SPF to reject mail than publish
> > records.
> 
> That's of course possible, but in my infradead scenario there
> are no losses.  Hadmut published RMX in December 2002, RMX and
> SPF were discussed over and over again, SPF started in January
> 2004, and so far the number of unexpected side-effects appears
> to be minimal.
> 
> Forwarders and mail forgers have to adjust, yes.  But that's a
> feature and not a bug.  I like it.  Now please let's be done
> with it, get the two RfCs out a.s.a.p., and then start to work
> on other ideas like CSV, MTAMARK, or more SPF scopes.
> 
> As long as SPF isn't ready I don't trust other ideas, because
> I'm not sure if that's only meant to derail SPF or create FUD.

I have listed the security and reputation problems that will exist with
the SPF approach.  This is not to dismiss the goals of MARID with FUD. 
The goals of MARID can be achieved.  The mailbox domain/mail channel
relationship can not be described using addresses safely.  It can be
done using MTA names however.  Let's achieve the goal with the safest
and simplest solutions.  Above all, let's achieve the goal safely.

-Doug