Thank you for the useful and practical advice. On 2018-01-07 03:57 AM, Dominic Raferd wrote: > On 07/01/2018 06:29, Mike Guelfi wrote: >> Our alternative was always to just set relays for "poorly behaved" >> domains > > Example (using sendgrid for relaying): > > /etc/postfix/main.cf: > ... > transport_maps = hash:/etc/postfix/transport > ... > > /etc/postfix/transport: > onedrive.com smtp:smtp.sendgrid.com
I have two main issues with the specific example above. (1) It is a significant degradation to me if the MTA that receives the email from my MTA is not operated by the same entity that operates the MDA. (2) I have looked at sendgrid.com and to me it looks like a service to increase the reach of unwanted ads. I want less ads, not more. The mere sentence "Email Marketing Campaign" sends negative shivers down my spine, and I find it objectionable to reward a third party that improves the delivery of spam with additional revenue. In my view, the only legit payment flow in addition to paying for ISP would be some sort of stamp whose value flows automatically and directly from the writer's pocket to the reader's pocket with no reward to any intermediary or other third party. The intermediary should stay neutral. Spam is in the eyes of the reader and if an entity sends you a message that wastes your time, you should have a right to be compensated for the pollution. Ideally the compensation should be designed to dissuade spam. Different subject. > Otherwise, the formatting of your DKIM record in DNS seems weird (try: > dig +short 201605sfinacom._domainkey.sfina.com TXT); even if technically > valid the intermediate quotes may be influencing 'SmartScreen'. The intermediate quotes are a result of key length. When I use 2048 bit length, there are intermediate quotes. When I use 1024 bit length, there are not: SELECTOR=<YYYYMM> DOMAIN=<domain.com> opendkim-genkey -b 2048 -r -s $SELECTOR$DOMAIN_2 -d $DOMAIN opendkim-genkey -b 1024 -r -s $SELECTOR$DOMAIN_1 -d $DOMAIN When I implemented DKIM, I have merely adapted the tutorial at <https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy> to my needs, checked the DKIM Key at <https://protodave.com/tools/dkim-key-checker/> and verified that my set-up is full operational with an email to check-a...@verifier.port25.com and one to <https://www.mail-tester.com/>. Never had any problem with this. Since it worked, so I did not bother digging deeper into the detail. I am familiar enough with encryption to know the bit length trade-off with the longer key imposing a computing cost on the receiving end in exchange for longevity. What is the experience of the experts on this list? Do server ignore DKIM when its key length is too long, and how long is the ideal key length? I am interested to learn more. My choice of the longest keys is because I am a self-supporting one man show and the further out in the future I can postpone the regeneration of encryption keys, the less time I need to spend on this. My next planned reset of my infrastructure is sometimes in the Spring/Summer, on Ubuntu 18.04LTS, and I hope that the set up will hum along for four years with minimal intervention. Yuv
