On Sun 25/May/2014 02:55:45 +0200 Sam Varshavchik wrote:
> Lindsay Haisley writes:
>> On Sat, 2014-05-24 at 09:00 -0400, Sam Varshavchik wrote:
>>> kb2...@kb2ear.net writes:
>>>
>>>> With the recent DMARC implementation from AOL and Yahoo I
>>>> have a very broken mailing list. Is there any way using MLM
>>>> to rewrite the From: line to the list address and the
>>>> Reply-To: line to the actual sender?
>>>
>>> Reply-Tos should go back to the mailing list, not the sender.
>>
>> This isn't an appropriate choice for most lists, which are
>> configured for reply-to-sender. Munging the Reply-To header for
>> this purpose is a broken way of dealing with the problem.
>
> I hear that often; but it does not add up for me. The whole purpose
> of a discussion-oriented mailing list is to hold public discussions
> on various topics; and I'd expect the replies to go back to the
> list too.
Nowadays most client have a distinguished reply-to-list button.
Reply-To could be left to authors for messages that are slightly
off-topic, or cross-posted, so as to direct replies appropriately.
>>> In the .courier-list file you could put something that adds or
>>> replaces the Reply-To: header. Then, use the headerdel and
>>> headeradd configuration settings, as documented in the
>>> couriermlm man page, to remove the existing From: header, and
>>> replace it with a new one.
>>>
>>> But, after doing that, you'll probably discover that it doesn't
>>> work, for some reason, or something else is broken.
>>
>> Sam, would you please disambiguate this. What else would break?
>> Why would it not work.
>
> Anyone's guess. SPF and Dmarc are hacks. And I say that even though
> I use SPF. I wouldn't be surprised to hear that someone's also
> checking the Reply-To addresses, so those will bounce too.
That would be a really freaky behavior, inconsistent with both DMARC
and SMTP.
An alternative solution is to replace:
From: John Doe <j...@yahoo.com>
with:
From: List <l...@example.com>, John Doe <j...@yahoo.com.INVALID>
I didn't try it myself, as I currently run no list. That was
suggested by John Levine on the IETF discussion list. The added List
address is needed for those few DMARC implementations that discard
invalid domains; reply-to-author needs manual adjustment anyway.
>>> The correct fix is to tell your Yahoo and AOL subscribers to
>>> switch providers.
>>
>> Telling Yahoo and AOL subscribers to change ESPs is NOT a
>> solution, nor is it an option for many working mailing lists.
>> Actually getting Yahoo and AOL, and other ESPs which honor it, to
>> fix their broken DMARC p=reject implementation _would_ be a
>> solution.
DMARC says a receiver should whitelist forwarders an mailing lists,
but fails to suggest a practical method for doing so.
> If Yahoo and AOL are saying that the only valid email with their
> domains on it are those that are coming from their servers, it may
> be dumb or stupid, but it's certainly their prerogative to do so.
> It's their domain. They own it. They are free to choose to run it
> however they like.
I don't think they like it, but they have to do so because of the
surge of abuse that has been occurring during the last months.
> If that's what they're saying, then honoring that request would be
> the correct thing to do, and bouncing mail with their domain on it,
> that's not coming from their servers, is the reasonable thing to
> do.
Yes.
> If someone's mail bounces because of that, or if someone gets
> booted off the mailing list, because of that, well, that's that.
> They'll just have to stop using Dmarc or SPF.
That depends on the point of view. From a global perspective, mailing
lists are a negligible niche. Then, it's on the mailing list
operators the burden to find a solution to allow mailing lists to
continue to operate in the face of DMARC.
Alternatively, since mailing lists users include so many influential
people, they can manage to undermine DMARC. However, that may imply
an anti-spam defeat, similar to the one experienced with SPF. BTW,
the IETF stance toward DMARC is that it is not an IETF protocol, so
they wash their hands.
>> The DMARC problem implies information loss, contrary to the
>> spirit and in some cases the letter of applicable mail RFCs.
>> When and how this information loss occurs is up to ML software
>> designers and list administrators.
No, DMARC policy provides for "reject" or "quarantine". Perhaps
you're confusing with ADSP, which provided for "all" and
"discardable"? Let me recall ADSP was demoted to historical.
> SPF's implementation in Courier is designed specifically to avoid
> this problem. Although the actual config settings can be twiddled
> any number of ways, the recommended default settings will
> SPF-validate the MAIL FROM: first, and if the validation passes,
> the email From: does not get SPF-checked. So, if a message from
> @aol.com goes through the mailing list, the MAIL FROM: gets checked
> first, and if the mailing list domain's SPF validates, the mail
> gets accepted. An SPF check on @aol.com in From: would obviously
> fail, but that never happens.
>
> I haven't looked much at Dmarc, but I'd expect that a reasonable
> implementation of Dmarc should take an analogous approach, to
> accomodate mailing list traffic. The onus on supporting Dmarc
> should fall on the end-recipient, not a mailing list intermediary.
> If someone's usage of Dmarc gets them bounced off a mailing list,
> it's their problem, not the mailing list's.
I'll wait to implement DMARC in zdkimfilter --since I already got
burned with ADSP[1]-- until this point is settled. Besides
whitelisting, there are two possible solutions on the author domain
side, Third-Party Authorizations[2][3] and weak signatures[4][5], none
of which seems likely to fly. I try and attach a picture summarizing
weak signatures and whitelisting.
In order to whitelist, as well as to implement the other two, a mail
server needs to know what mailing lists its users are subscribed to.
A ML operator should seek subscribers' consent before letting a server
know that data, and then there is no programmatic way to send, verify,
and update it. This is the "manual process" in the picture.
Ale
--
[1] http://lists.opendkim.org/archive/opendkim/users/2010/08/0443.html
[2] http://dotis.bungi.com/draft-otis-tpa-label-00.html
[3] http://tools.ietf.org/html/rfc6541
[4] http://datatracker.ietf.org/doc/draft-levine-may-forward/
[5] http://datatracker.ietf.org/doc/draft-vesely-dkim-joint-sigs/
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
