Hi again, On 14/10/2019 16:04, Andrew McGlashan wrote: > Hi, > > On 14/10/19 9:42 pm, 황병희 wrote: >> Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> writes: > >> There was related discussion: it's very seriosus... >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754809 > > Okay, well, I have p=quarantine for my setup, not p=reject, but that > doesn't seem to be enough. A notification that SPF failed says nothing about delivery. > I get reports from all over the place; the SPF failures may well be > due to the list emails not having an SPF policy and I'm not going to > give credentials to Debian to sent emails as me from my server for the > list as that would be a security risk that is too great. SPF is (not) verified against helo=bendel.debian.org and mfrom=lists.debian.org Then the report is sent to you because of the From: address. > DMARC needs to work, not be broken at all; it is supposed to help with > legitimate mail delivery, not hinder it. Yes, that's what reports supposedly do. They tell you how your DMARC authentication goes. In theory, you should be able to decide how to set your policy based on them... > SPF should be checked properly as well and emails rejected when they > don't comply with the domain name's specified "rules". Right. > So many domain names have multiple SPF records (which results in permerror > as you can only have one SPF record). Debian has no SPF record. My MTA reports "unknown", which gets translated to permerror, possibly not perfectly well. > It's not as if SPF is new, it has been a > thing for quite long enough to treat it's rules appropriately. It > also annoys me when people use "~all" .... to me that simply means, > "screw it, we don't really care or we don't have a clue how to make > this work"; it should be "-all" only, unless you are in a testing > phase and are not yet committed to using SPF properly. Of course > using "~all" will help when servers don't otherwise play ball > correctly, but it's still very wrong to me. Agreed. > It might be better if real mail servers could freely register > themselves as proper mail servers, they get a signed assertion to use > from some shared authority, everyone should register and then the > spammers and fraudsters should be left out in the cold. There are whitelists, e.g. dnswl.org... > It would be important that legitimate servers be able to fix problems > easily without extorting funds from them to fix things. If you run a mail > server, your reputation is at stake, and your rep should count for > something; if you abuse your assertion, then you should be subject to losing > it. A failed SPF authentication doesn't mine reputation. > Sure, there will be errors with setups as humans are involved; those > should be found and fixed, then properly observed. > > There is another level of problems when emails are forwarded on to the > rotten mass public mail services; ordinary forwarding brings all sorts > of other problems (forward as attachment mitigates these problems, but > it is less easy unless manually done from client email program). Appendix D.3 of [RFC7208] is the best cure I found. > I can blacklist bad IP address of mail servers that are found to be > doing the wrong thing (just like RBLs do), but I can't block out a > whole bunch of providers that allow their users to send spam through > them, such as Microsoft, Google, Yahoo and even Apple and that's > before even thinking about sendgrid, mandrill and other mass mailing > services -- we can't easily stop rubbish from those servers without > blocking good users whom use those services. It would be so much > better if the big guys would shut up shop or otherwise crack down on > bad users and stop the problems that require SPF, DMARC and the like. Email authentication is an attempt at discerning mail flows. Being authenticated doesn't imply good or bad. DMARC added feedback, which should be useful. Personally, I check DMARC reports (their XSLT htmlized version) after rotating DKIM keys, and in some other rather uncommon circumstances. Some people pile them up in a database and run queries on it. Others outsource their interpretation. They are strictly OPT-IN, so if you don't want them you can just not ask for them. Best Ale
Attachment:
signature.asc
Description: OpenPGP digital signature