On 6/10/2014 9:55 AM, Stephen J. Turnbull wrote:
Hector Santos writes:
> Are you oppose to any other domain using strong policies or just
> certain ones?
Domains where users have until now felt free to use their mailboxes as
they see fit (posting to mailing lists, as From: in on-behalf-of
services, etc) should not suddenly impose "p=reject" IMO.
Right and so has the world of no-authentication required port 25,
local recipient transactions where massive abuse has occurred world
wide.
The LSP, the bulk mailers, was among the tools used by the "bad guys."
Millions of aged domains have been spam polluted, including
Yahoo.com, etc. It is everyone's problem. I hope you agree.
It was time for a change, and it started in 2003 with SPF and soon
with DKIM+ADSP. Forward into time, ADSP was replaced with DMARC.
LSP were warned.
I have stated several times that I have no quarrel with DMARC as is,
that I think it is a good protocol overall, and that in particular
"p=reject" is useful in "transactional" contexts. It is a logical
consequence that I support the idea of a lookup to discover policy.
Will you implement it? You need to implement it as part of the LSP
integration. Because if you are not, I need to stop writing to you
trying to convince you. :)
It is more easier, more feasible, more safe, to just reject/discard
the failed message (due to policy) at the backend and be done with it.
In your opinion.
It is the expert opinion of million of IETF-MAN-HOURS and SMTP systems
that have long implemented and deployed 4yz/5yz client/server response
system and state machine. That includes my expert opinion. Its the
expert opinion of systems that have deployed strong system level
rejection methods, among them SPF, DNSRBL and now DMARC. I
understand you are a LSP. DMARC effects you differently, but we can't
throw out the proverbial baby.
In my experience, many postmasters resist that policy.
Software developers provide the postmasters the option to
reject/accept mail. So whether it is many or not, it is pointless.
The demand is high to deploy system level rejections for older and
newer policy reasons.
Do you realize how many different MUAs exist? and the different forms
of MUAs?
I haven't counted. How many are there?
Lots, too long to list. Its not about my stuff but everyones you have
to work with. I have number of MUAs of my own for our own system. For
tech support, we have different mail access portals:
web: http://www.winserver.com
telnet: telnet://bbs.winserver.com
nntp: news://publicnews.winserver.com
smtp/pop3: mail.winserver.com
GUI: http://www.winserver.com/public/wcnavigator.wct
plus a few internal Sysop Editor/Management/Watchdog tools.
How can I single source your ideas for each of these MUA? The web side
is a big concentration these days. So do we just deal with that? Do
I forget the rest? I can apply the single source logic at the backend
and it applies to all MUAs, the user using his favorite mail portal is
secured against abuse.
Is this practical business expert "opinion" acceptable?
> Why pass the buck to the user when the backend can deal with this
> and its works for all MUAs!!
Because the backend can't deal with it,
But it does and it works very well. If the backend software can't,
then who? The user software?
Software is software, why not the software at the backend? Do you
wish to make this a USER defined policy where he can teach the backend
because his frontend software is not capable of doing this?
I'm cool with that, so what are the defaults? Maybe you can add user
options like:
[X] I want to reject mail from unauthorized DMARC sites.
Will you provide it to them or is it too "Draconian" for them to have
available?
except by imposing draconian
policies that I know many sysadmins really want to avoid.
Well, it pointless to say "many" because what the "many" is really
suffering from is the lack of options with the DMARC protocol. It is
missing LSP provisions and once that happens then you will have your
tools to adjust gracefully. But you have to agree the LSP needs to
do the lookup or its frontend receiver has to do the lookup and be
aware of the ML part, i.e. acceptable list addresses.
Stephen, I do believe that it is "Bad Policy" to be promoting a
concept of ignoring new growing policy protocols. It isn't going to
help in the long run. DMARC is here. It isn't going to go away. Sure,
its my opinion and I like to think I am more right than wrong. :)
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
