[dmarc-discuss] multiple from

Douglas Otis doug.mtview at gmail.com
Fri Jul 19 14:08:33 PDT 2013

On Jul 19, 2013, at 12:39 AM, Roland Turner <roland.turner at trustsphere.com> wrote:

> Doug,
> On 07/17/2013 07:57 PM, Douglas Otis wrote:
>> On Jul 16, 2013, at 8:46 PM, Roland Turner <roland.turner at trustsphere.com> wrote:
>>> An SMTP server (or the host that it runs on) is the property of a receiver. When a sender offers a message for delivery, the sender is asking the receiver to extend a delivery privilege, a privilege that the receiver is free to decline for any reason or for no reason.
> ...
>> Respect the rights of receivers over that of senders? Absolutely!
>> There remains a need to defend receivers, and that is a clear reality.
> This is easy to say, but somewhat harder to think:

Dear Roland,

Keep overhead low and ensure initiating domains are authenticated.   XMPP offers an example able to also defend IPv6.  Combined authenticated servers  with ATPS/DMARC like policy can end worries about message structure and signed message fragments.  Authenticated servers also safely permit effective protections by third-party rating services.  Such services MUST be able to defend conclusions reached.  DKIM completely lacks assurances a signing domain initiated the sending of a message to any given recipient or be held responsible for not ensuring against inclusion of invalidly prefixed header fields since this is rarely ever done with DKIM. 

Even RFC5322 does not mandate structural compliance.  This RFC defines a constantly changing structural definition that can not be reasonably enforced by the transport due to insurmountable deployment issues.  Such checks can only be adopted as required checks in something like an authentications-results header likely only needed when DKIM is used.  The easiest solution is to declare any DKIM signature accompanied by invalidly prefixed header fields itself invalid.  Unfortunately, that approach was rejected and replaced with non-normative language stating message structure should be checked.  In addition to communicating the fact a DKIM signature is valid, a way to communicate message structure checking is needed since this is not the function of SMTP!

>> SPF macros are a rarely used option, when combined with DMARC, becomes an obligatory role for receivers on behalf of senders.
> Nothing is obligatory upon receivers. Indeed, any assumption that an RFC has this effect is invalidated by the actual behaviour of receivers above a certain size with respect to this particular feature, exactly to avoid the consequences of this error in the RFC.

Since DMARC is related to improving policy enforcement of sensitive domains, it is reasonable to anticipate resulting bureaucratic obligations that expect RFC compliance.  You are right about large providers already ignoring SPF macro provisions which can destroy interchange.  Justifications for non-compliance might be inabilities to cache results, or potential vulnerabilities in macro processing lacking normal safeguards ensuring against the compromise of SMTP servers.  Nevertheless, DMARC is building its foundation on shifting sand that means receivers are not easily defended.

Douglas Otis


More information about the dmarc-discuss mailing list