On Nov 30, 2014, at 7:42 AM, Hector Santos <hsan...@isdg.net> wrote:
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.
Dear Hector,
DMARC is throwing out three decades of defined header field roles for Author
and Sender and is not compatible with email. This happens when the From MUST
have the same domain as that of the Sender to achieve the DMARC required
alignment. This is not possible when dealing with various third-party
services, such as mailing-lists or even offering the disrupted services DSNs.
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!
Strongly disagree. DMARC does not permit legitimate and valid email to be
accepted from a third-party service which disrupts valid email uses.
These include:
-- forwarding of email to a different domain (as might be done with alumni
accounts)
-- use of third-party services where the From header field properly retains the
role of the Author as stipulated by RFC5322
DMARC assumes users are unable to understand message sources based on the
Sender header field, where the source agent role has been defined. In fact,
the Sender should not be placed into the From header field. Once that dubious
practice becomes required, even guessing who authored a message becomes
doubtful.
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.
Is it really overly complex to make Sender header fields visible to users?
This should remove justifications for rejecting otherwise valid and legitimate
messages. If so, no changes would be needed when Sender header fields comply
with either SPF or DKIM. It seems DMARC needs a fallback mode for policies
imposed by DMARC domains to override miss-applying DMARC policy against normal
email accounts. As it is now, the best that can be done is to downgrade
p=reject to p=quarantine. Users are then expected to find valid messages being
placed into their spam folders, which defeats stronger protections otherwise
afforded when users are informed acceptance is based on a strict policy of
either From or the Sender header field alignment. It only makes sense for
transactional sources to exclude otherwise legitimate forms of email that
includes the Sender header field. As such, DMARC should have a setting to
explicitly include use of the Sender header field alignment. Otherwise, DMARC
remains incompatible with email.
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.
If policies are to be strictly enforced, they should offer a mode that permits
valid and legitimate email. As currently defined, DMARC can't.
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.
DMARC is attempting to satisfy a narrow range of services where the From and
the Sender header fields must be within the same domain. When domains such as
AOL and Yahoo decide their users' messages must be strictly enforced in this
manner, this non-compliant policy disrupts many normal, expected, and
legitimate email. This disrupts email's agility at meeting a broad range of
uses and has the effect of balkanizing these services.
It is DMARC that is being unrealistic.
