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

On Mon, 2004-09-20 at 13:27, Frank Ellermann wrote:
> Stephane Bortzmeyer wrote:
> 
> >> if someone publishes -all and gets important mail bounced
> >> s/he can still decide to remove/change -all
> 
> > I agree. This is a local policy issue.
> 
> Yes and no.  Yes, s/he can still decide to do something.  But
> I'd never remove or change a -all, there are better options.
> Like using an alias of my address not covered by the sender
> policy.

You would not know which alias to use to overcome a problem that can not
be known in advance. : ( 

>   But so far I never had this problem.  But I got about
> 180,000 bounces and other side effects of forged MAIL FROMs in
> six months (03-08).

I would expect BATV will be a good solution for this problem.

> I'd never remove the -all voluntarily.  And apparently no other
> user of claranet.de vanity hosts had any problem (the wildcard
> was added in May IIRC).

It is often difficult to know when a message simply goes missing.  There
would be no way of knowing which recipients are forwarding their
messages.  You are suggesting when a message does go missing, (perhaps
without notice) that there be an alternative address to recover from the
problem.  It could be this assumption of acceptable losses holds because
far fewer use SPF to reject mail than publish records. 

> > "SHOULD publish SPF records that end in "-all"
> > should be deleted or moved to "Security considerations" with
> > a less demanding wording.
> 
> It's perfectly okay.  SPF without -all is about as efficient as
> the new FUSSP RfC 3865 [some remarks about RfC 3865 censored,
> because this would cost me the write access to MARID].  So add
> whatever CAVEATs and warnings you want, but don't touch this
> SHOULD.  SPF without -all is a complete waste of bandwidth and
> time.  Bye, Frank

Although changing the structure of Sender-ID slightly does allow goals
of the MARID charter to be safely achieved, I recognize this has not
been the shared concept that brought the group together.  I hope a few
see such efforts as an earnest endeavor to achieve the goals of the
MARID charter and not as an effort to thwart progress.

By using a two step process, the recipients can be notified when a
message is outside the nominal mail channel, and a name based list can
be used to safely establish the MTA/Mailbox-domain relationship.  An
open SPF/Sender-ID list would be worse than a waste of bandwidth, but
closing the list would make mail delivery unreliable.  By having the MTA
authorization separate from the mailbox domain association, there would
much less motivation for spammers to utilize these open records.

In the jabber session, there was a discussion looking for an a header to
be inserted into the message associated with the sending MTA.  I
suggested the EHLO/Received: header, if validated using CSV, establishes
an equally strong relationship as would adding a new header or
redefining other existing headers.  The advantage would be that these
headers already exists and, once validated, would be suitable to
associate the message with the sending MTA.

Fix what we know to be broken first.  Not authenticating the EHLO name
is broken. Once the EHLO name is reliable, then this becomes an
inflection point.  With this long broken aspect of SMTP repaired, then
the information needed to associate mailbox domains becomes dead simple
and very safe. Such a solution allows the needed identity strength for
asserting a reputation where much of the abuse will be abated.  A
validated EHLO alone would be extremely helpful in preventing spoofing
and phishing.

Sender-ID could simply build upon a foundation of "strengthened"
existing structures.  Sender-ID then becomes a simple name list to
associate the mailbox-domain to MTAs.  The goal of the MARID charter
does not require that a script be used nor does the goal require an
address list be used to define the Mailbox-domain/MTA relationship.  As
can be discerned by the potential downsides using addresses instead of
names, the slight change being suggested is to use names rather than
addresses.  Fix what we know to be broken, and then add Sender-ID using
names.

-Doug