On 11/29/2014 7:04 AM, José Ferreira wrote:
Like is said, they are rare but important. And some domain owners may not adopt
p=reject for that reason.
Jose Borges Ferreira
Domains that publish a p=reject and don 't understand its possible
outcomes, shouldn't be our (IETF protocol standards development)
problem. It helps to know they exist, but they should not be the
reason for throwing out the proverbial baby out the window.
That is not to say strong, exclusive, restrictive domain policies do
not have their place. I am on the side that more than most (pareto's
principle) do know what they are doing and purposely set these
policies and if there is an indirect flow issue, fortunately, it has
been a minor issue to them.
The approach we (SSI) have taken since 2003 of implementing and
deploying (and selling) strong ANTI-SPAM, SMTP REJECTION methods
(meaning the PACKAGE OPTIONS were made available) is that:
ONLY GOOD GUYS COMPLAIN, NOT BAD GUYS.
The bad guy does not pick up the phone crying to you about your
rejection policies. So if the good guys complain which has been
extremely and seriously rare (for SSI, i.e. low support
cost/overhead), the easiest solution to to LEARN YOUR
PERSONAL/BUSINESS NETWORK and white list them and/or if possible,
technically correct whatever protocol issue their might be. After
all, all these protocols were really designed for the ANONYMOUS,
UNSOLICITED TRANSACTION where A/A (Authentication/Authorization) HAS
NOT been established.
In order to be 100% backward compatible with SMTP Port 25
operations, YOU MUST
STILL support ANONYMOUS, UNSOLICITED TRANSACTIONS at the very least
for NON-OPEN
RELAY operations, i.e. for local users and locally hosted domains.
For Relays,
A/A requirements kick in and that is what we are pretty much
dealing with here.
But for the most part, MOST were bad guys and that is why these strong
SMTP LEVEL rejection protocols do have a very high payoff for those
that CAN deploy them.
We are not going to solve the mailing list problem UNTIL the mailing
list folks (software developers) change their software TO SUPPORT
Policy. We still have people that are trying to avoid it, FOR 10
YEARS, and that avoidance has not worked!
Its really that simple, however, the complete integrated solution is
COMPLEX (and costly) and for the most part, only a total system
integration can handle it. If you (speaking in general) only have a
MAILING LIST package, well, you need to wait for the other parts to
fit in as well and vice versa.
All I reading (and it seems to be subsiding) are ML folks trying to
advocate avoiding domains with strong, restrictive policies. Well,
can't have it both ways. Intentional ignorance and expectation that
things will continue to work and integrate well, is in my strong
technical software engineering opinion, unrealistic.
All parts need to fit together and since its a multi-component
integration problem, there are only a few packages that can do that.
That is what makes this a long time difficult problem to solve. You
have systems people, operations, networks, mailing list people, etc
and most have different goals and agendas.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
