On Feb 27, 2014, at 11:22 AM, Matt Simerson <[email protected]> wrote:

> 
> On Feb 27, 2014, at 10:43 AM, Dustin <[email protected]> wrote:
> 
>> Perhaps one example of being wary of p=reject:
> 
> Absolutely.

+1

We always said don't move to p=reject till you have assessed the consequences, 
because receivers will not be complacent. If your email stream goes via a major 
forwarder and you can't live with the issue, don't do p=reject.

> 
>> Matt's message, as evaluated by Gmail, failed alignment, and was 
>> consequently marked as spam.
> 
> Thanks to DMARC reports, the sender is quite aware. Of course I'd prefer that 
> this list didn't invalidate my DKIM signatures. I'd also prefer that Google's 
> SPF recognized that this list server is SPF permitted for @tnpi.net. But 
> that's outside my ability to influence.
> 
> $ spfquery --mfrom [email protected]  --ip-address=`dig medusa.blackops.org 
> +short`
> pass
> Received-SPF: pass (tnpi.net: Sender is authorized to use '[email protected]' in 
> 'mfrom' identity (mechanism 'include:lists._spf.tnpi.net' matched)) 
> receiver=rmbp.local; identity=mailfrom; envelope-from="[email protected]"; 
> client-ip=208.69.40.157
> 
> Until we have a solution that lets DMARC mail securely transit email lists, 
> our two legged DMARC table will wobble. 

The same people will argue that the email eco-system is fine like this and 
should not change: https://en.wikipedia.org/wiki/Who_Moved_My_Cheese%3F

> 

I'm a little baffled by people making generalities, about me, personally, 
testing mailing lists (and especially most of the dmarc related lists) with 
p=reject, and people assuming a generality from this. As many other senders 
have found, the mailing list issue is marginal, for the senders with p=reject, 
for their email streams. Our users which were on mailing lists already used a 
private email address when we moved to p=reject. This is why also we were able 
to do it quickly. It was a non-issue from the start.

It is not expected for the receiver to change the way they receive emails with 
DMARC, but for the senders, only if they care their email to be delivered, and 
if they want users on a domain with p=reject to get these users to use a 
personal free email account to join mailing lists before making the change.

Thanks Matt for setting up the record straight, with your operational 
experience and data.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Reply via email to