Re: [mailop] Why is mail forwarding such a mess?
You have a good point in that the first and main problem is that the forwarder cannot be trusted to not mangle or fake the original message. Nothing else can be sorted out until this gets out of the way, including OOB communication between originator and final receiver. Which is in effect message authentication. For which we already have DKIM (among others). We could mandate DKIM for all originating SMTP servers and "forward as attachment" forwarding+DKIM for all forwarding servers. Thus, any seemingly forwarded message without its own DKIM signature and fully-wrapped DKIM-passing original is a lie (like the pie). So, my take is: lean much more on DKIM and by extension DMARC until nobody can send unauthenticated emails effectively, at all. Any $20 web/mail host has cpanel, etc that does this automatically. In the user UI nothing much will change, nor what we are currently doing at a basic level. To me this seems "fairer" than wrapping the message alone, because the forwarding server now takes on the burden of the reputation hit for that message. Eventually, enough viagra messages will be forwarded that the forwarder can't get any mail delivered anywhere. I would simply disallow forwarding rather than risk everything on the content of my user's incoming mail. They can't help it if their email has been harvested by spammers/phishers so it's an inevitability. Best Regards, George Miliotis [of the decimated small/tiny mail server brigade] ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] BIMI boycott?
Greetings. What I believe will happen is most non-big mail client apps will support BIMI if they support avatars, otherwise, they won't, cause the arguments on the receiver side are the same for both features. I don't buy the "promoting authentication" argument. There would be a marginal benefit in spreading DMARC via a UI good-to-have feature as a carrot, thus combating phishing, but DMARC doesn't need help spreading, it's become a requirement by the big mail receivers. So BIMI only becomes useful if VMCs are used. Yay, another bureaucracy on top of the certificate issuer and domain registration ones. Even more hassle and expense for small senders. The big mail players will adopt BIMI cause their clients (the marketers) are proposing it. So eventually anyone without a logo next to their mail will be met with suspicion by the users. Have an e-shop but don't have VMC-backed BIMI? You get your logo shown but no blue checkmark on it, uh-oh, now you're in the spam folder, oops. Tough to be you. Eventually, no BIMI = +5% spam chance and life will go on as usual: small mail operators and SMBs will be even less in control of the deliverability of their mailings while the big senders get even more closely coupled to big mail providers. BIMI is trying to do identity. IMO identity will not be solved in mail inbox UIs. It'll come from concerted efforts elsewhere and mail will integrate into that. Regards, G. Miliotis ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
On 2022-11-24 14:01, Tobias Fiebig via mailop wrote: And to circle back to on-topic: The result of that is what then pops up in /var/log/maillog. So it isn't about 'should VT change [something]'; It is more 'shouldn't society change the incentive structure and general setup around academia as a whole'? I have quite some opinions there, boiling down to the answers 'yes' (and suspect most here will agree with that). But that is not really in my power; So I try to do what I can instead (channeling results of the system into a more manageable frame, while trying to teach those students I directly work with at the institution I am at). At the risk of being frowned down upon for this for being arguably off topic or mean-spirited, I feel I must venture an opinion, even as a tiny operator, because I have had extensive experience with how academia works and have dealt with this repeatedly. This "oh what can I do, woe is me" responsibility-diffusing rhetoric belongs with junior, recently hired teaching assistants, not professors with tenure. Isn't it professors who, after all, in fact run the universities? Who provides and sets the academic standards and practices, if not they? Who populates the commitees? Or do we further diffuse responsibility for bad research practices up to the govenment, another academic trope? Who is this "academia"? How about a more honest: "This is how the questionnaire is and will remain, we have no time to change it now, feel free to not fill it in. We'll do better next time" and be done with it? Because I didn't see any willingness to change something in the questionnaire in light of the criticism in this forum. * How about adding info to/changing the upfront consent statement? * Making questions optional is not really confidence-inspiring, feels like a quick fix solution to "get on with it", a practice I've seen used when there is no time to go over and redo a questionnaire due to having to get it through committees again. * You claimed GDPR work was done. Is surveymonkey more GDPR-compliant than Google forms? How about using your own self-hosted platform, for example? They're zero cost, secure and easy to set up and I would trust something you self-manage more. Surely you have the know-how. All that said, I am all for research on the subject of mail protocols and practice and sincerely hope this work produces useful results, hopefully also truly representative of practice in the field. Good luck to you. Best Regards, G. Miliotis ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Musings on Mail Service Operators
On 3/2/22 13:59, Andrew C Aitchison via mailop wrote: To me any system that aims to replace email must be based on pushing messages and have a distributed nature. This means that deliverability issues are an inherent risk, in a way that pulling messages from a central/unified service can avoid. Sounds like the fediverse. OStatus (diaspora) and ActivityPub (mastodon) being the relevant protocols. Activitypub is a promising protocol built to do what you describe, albeit aimed at social networking. The problem with that is that they stumbled onto the difficulties email is facing, too: spamming, spoofing, access control and tendency to centralize. They're now trying to get groups implemented but there is no formal protocol oversight so it's the wild wild west. The initial protocol design has some flaws that don't help, either. Seems like there are unavoidable issues in the task itself, not the technology or governance used to implement the task. IMHO if someone wanted to decentralize messaging the "email way" but be a more modern alternative, it would be via an improved ActivityPub-like protocol. --GM ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Barriers to Entry / Governance (was: What a drag it is sending DMARC reports)
On 2021-12-31 13:42, Alessandro Vesely via mailop wrote: The difference between them is that, although HTTP provides for put and post verbs, the web evolved around clients downloading data from the servers, while email dealed the opposite direction. The implication with respect to spam is evident. Web spam can only occur for sites which accept data from (authenticated) clients. The store and forward nature of SMTP precludes client authentication at each hop. Had I to register and log in at your mail server in order to send you a message, spam wouldn't be so ubiquitous. Precisely, we all know how well HTTP and family handles contact form spam, even when it doesn't send email in the backend. What "governance" does the W3C have for those? --GM ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Roundcube client IPs → dovecot, postfix
On 2021-12-28 17:55, Nicolas JEAN via mailop wrote: My conclusion is that today, there's no technical way to forward client IPs from roundcube to dovecot/postfix. Doesn't the XFORWARD feature work for postfix? I thought that's how amavis for example talks to postfix. Usually via a dedicated master.cf entry. http://www.postfix.org/XFORWARD_README.html I would expect an additional issue to be that if one uses an imap proxy, the connections can't be "chunked" for all users, as you would need to re-auth everytime. So you may get reduced benefit from your proxy. Best regards, GM ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So uh... Zoom/Sendgrid... How's that webinar spam investigation coming? - the MEME
On 2021-08-05 21:51, Brielle via mailop wrote: Looks like some of the topics of the spam is starting to gravitate towards current events... ESP to spamming customer: "improve the quality of your mailings, stop sending people mail they don't want or we will have to ask you again to stop, repeatedly - btw your invoice is due" spamming customer: goes through queue, deletes old spam mailings. Sends new spam dealing with current events, considers it "relevant" and therefore desirable. Sees nothing wrong with this. The Internet: still doesn't block ESP Users: Maybe I should buy one of those Vietnamese coronavirus masks - some die of coronavirus Mail admins: FML E-mail as a whole: In the ICU Enjoy your summer everyone! --GM ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Seeking advice for warming up IPs with Microsoft
On 2021-07-30 11:30, mailop--- via mailop wrote: I'm not sure that anyone can offer me anything other than sympathy but I'm open to any advice or suggestions. These huge freemail providers are killing email. Mail was never supposed to be so centralized. We're just managing our misery here. It's totally arbitrary. The limit could be anywhere for any IP range and may change at any time. Fix it now, it breaks tomorrow, no feedback because of the operational imperatives of having millions of mailboxes. I had a customer renting villas and they just kept getting junked in hotmail and gmail when replying to mails from customers (website mail forms are useless nowadays). So I sent them to Rackspace. Thought a bigger service would be better handled by the freemail services. Now they're on the phone all the time because of outright IP blocks. I think in the last month they've been on rackspace support 3 times due to outright hotmail blocks. At least at my tiny MX they could get their mail sent to the junk box. Now they're just not sending at all. Whatever, at least I got that headache away from me. There's no point selling MX services below a certain threshold nowadays. I'd try to get everyone in your group totally out of freemail services and install a decent webmail interface, or just use a relay. Also teach them to add everyone else to their safe sender lists / filters as a minimum. Or use a different channel you can control and build a community with, like a forum or a mastodon/pleroma server or something. Groups are now in the featureset, I read. If that fits your use case, of course. Good luck --GM ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"
On 26/8/2020 20:36, flo via mailop wrote: I prefer not to put my private address unprotected on the internet. Well duh. Not everyone is a business with already-public information. I run my own server and host some domains on that. What assurances do I have that my personal information is protected by T-Mobile / DT after I send it to them? Why should I be forced to make this information public on a website? What's the point if I can just take it down the next day? When I had a whois record for my IP range with information and it was public, I was not happy but at least it made some sense. Now that WHOIS is considered a privacy leak, DT's scheme makes even less sense. My guess is they're just throwing cheap labor at a problem instead of actually thinking it through. I guess an army of interns is better on the finances than actual spam fighting experts and scalable infrastructure. Also, this is another walled garden and I can't believe their business customers (if the same method is used on them) would stay with them long. --GM ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Google and Spam detection
On 24/7/2020 8:12 μ.μ., Luis E. Muñoz via mailop wrote: On 24 Jul 2020, at 7:48, Jaroslaw Rafa via mailop wrote: Not true, I was (and am) always delivering mail via IPv4 and had mentioned problems (and also other people whose complaints I have read don't use IPv6 as well). I see no difference in IPv4 vs IPv6. You do need to have rDNS properly setup and we use SPF and DKIM, no DMARC. IPs from a cloud provider to boot. Good deliverability. When I tried IPV6 from Hetzner some time ago, gmail dropped everything outright until I set up DKIM. --GM ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Google and Spam detection
On 24/7/2020 7:13 μ.μ., John Levine via mailop wrote: In article <20200724160354.gg9...@ikki.ethgen.ch> you write: I think it might happen that in past hetzner (my hosting provider) ... Oh, there's your problem. Hetzner's network spews garbage. I don't accept any mail from it at all. That's up to you. I guess this email would never reach any of your users, then. Soon it will become less and less effective to block providers, you see the rising spam volumes from all providers, including the big boys. The whole argument seems to me to be a Hetzner netblock issue for the OP. I faced the same issue, adding dkim/dmarc helped. --GM ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"
On 17/2/2020 22:39, Luis E. Muñoz via mailop wrote: One could state facts – i.e., pointing out that SPF will break straight forwarding and mailing lists that do not rewrite – without introducing judgement. How about a small section in the FAQ about decisions that the mail admin must make? Such as factors to consider with SPF (in this case), DMARC, quarantine, RBLs and so on. Let the new guy know what he's getting into, probably early on in the documentation. If it's too much material, just a mention to get them started. Best regards, --GM ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Microsoft fragmented abuse reporting
On 17/10/2019 22:05, Jay Hennigan via mailop wrote: Why doesn't Microsoft handle this internally instead of forcing the reporter to jump through another flaming hoop? They got the report to their whois-listed abuse contact based on originating IP. They know what internal department should be handling it. This should automatically get sent internally to the correct department for handling, not bounced back to the sender after a delay of several hours. Probably testing your resolve ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Microsoft blacklisting a /16
On 5/6/2019 20:23, Michael Peddemors via mailop wrote: That hasn't been determined as of yet. Comments and thoughts on that subject welcome. A good start would be VM/VPS/server provisioners actually putting default firewall rules in their images. Especially outgoing rules to a certain port we are all interested in. --GM ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
