On 8/26/16 5:37 PM, li...@wrant.com wrote: > Fri, 26 Aug 2016 15:36:16 -0400 Daniel Ouellet <dan...@presscom.net> >> On 2016-08-26, Peter N. M. Hansteen <pe...@bsdly.net> wrote: >> >>> The only downside is, the traditional forwarding that mailing lists do >>> *also* triggers the DMARC dark magic, and there is a significant risk >>> that messages sent with senders in DMARC domains via the mailing list >>> to recipients with a somewhat DMARC-aware setup will be discarded. >> >> I still have question on this subject that is not 100% clear to me. > [...] >> Am I missing something so far? > > Hi Daniel, > > Yes, these are all incomplete semi-solutions designed to do one thing, > and only one thing well: deliver you commercial email that you'd trust > is coming from the paying sender and not others that have not paid up. > What I'm saying is that they address corporate, not very public needs.
I kind of disagree with this statement. I fell actually it is less efficient for commercial providers simply because of the number of users and the easy way to create an account and then assuming someone else identify in forge emails. Even based on your link below it sustain that point. Look in your link a bit lower: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Arbitrary_forwarding Some someone having access to your mail server to send emails will get it signed and then can miss use it. If your a commercial provider the volume of users you have are way bigger then if you control your own server(s) and you need each users limited n scale and hopefully only for your company, or your own personal mail server and domain, will not allow this process. So, your DKin signature will be valid and hopefully unless your mail servers get compromise or allow relay to users that shouldn't relay through it, will be good to use. Now if you also control your SPF records, that add to it as well and if you add on top the DMARC, it will possibly enforce it if you choose to do so at the recipient that support it. Nothing is absolute regardless, I wish there was a solution, but trying to work around the problem doing rewrite doesn't help I think, but I am more then welling to see the other side. > https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Weaknesses > https://en.wikipedia.org/wiki/DMARC#Compatibility But my question for sure that I am not sure of the answer is if you have emails that happened to have multiple DKIM signature added to the header along the way. Will the DKIM actually process the one from the original sender form the FROM: field and look for the DKIM signature if available for that sender domain or not? Or will it process only the more recent one received? The answer to that question is not clear to me. Why does that make a difference, well if you run your own server and you control it pretty close and absolutely ONLY allow senders to use it by authenticate to it, then the chance of forgery are reduce as much as you control it to be nil if you use it just for you and are the only one using it, or very limited trusted friends and all. Then the signature can be trusted, the SPF records can be trusted and then the DMARC can be enforce. The part that break it some was my suggestion to add the server(s) of lists you use to your SPF records allow to send emails on your domain behalf, but I am not sure it is a good idea. It is a way around the problem for now, but is it a good one that I am not sure! Other input on the subject may be welcome. I guess the validity of your DKIM signature is ONLY as valid as the users trust you put on them to relay through your server that add the DKIM signature. I guess if you can demonstrate that they are all trusted, then I guess all your emails signed with DKIM should be authentic? Add proper SPF records to enforce that a but more and put a very strict DMARC to tell domains recipient that support DMARC to reject all others may help protect your domains from forgery some. But as this is not widely used, it has it's limitation too. Now unless I miss understand something that how I see it... So, if what I said above is true in the process of DKIM and SPF, if you add the lists you use to your SPF records and that the proper DKIM is process, then it should be fine for the domain that actually use DMARC. It will see the from field as you. If process properly it will see your DKIM signature for it. It will see your SPF entry for that list. So, DMARC should accept it. Draw back, if a site doesn't use DMARC and doesn't check for SPF either, then you just added a wide possibility of abuse from the lists. But the choice is yours to make. I am really NOT in favor to rewrite any header what so ever. Or I am definitely not convince of the benefit it may add yet! > Had to cut some text, sorry for the intrusion in your message body ;-) > If the above links have inaccuracies, please help fix their accuracy.. As for this, there isn't any intrusion, I am more then happy to see a better way to do things as fighting spam and forgery is a constant batter that no one can win yet in an absolute way, only reduce it some. Thanks Daniel
