Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled
On 13.03.24 18:55, Slavko via mailop wrote: > Dňa 13. marca 2024 16:32:42 UTC používateľ Andrew C Aitchison via mailop > napísal: > >> Has anyone checked what traffic is still using TLS 1.0 or TLS 1.1 ? > > Yes, some infected machines from DZ, BR, AR, ID and so :-) So we are removing a perfectly good marker to increase spam scores? Just saying... :-) Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
On 12.02.24 21:21, Bill Cole via mailop wrote: The mail server providing the redirection may not be doing what the original address owner OR the owner of the address to which they are redirecting actually wants. Redirection could allow malicious server operators to direct 3rd parties to send unwanted mail to an unrelated victim or to send wanted mail which should be private to those from which it is meant to be kept secret. There is no standard way to record such a redirection in a Received header or any other header which would document why a message was routed in a particular way and no way for the sending system to validate that the redirection is benign. As a sender I do have to trust all servers in the chain to the recipient anyway? Any of those could be run by a malicous server operator. Even without redirection anything you describe could be done to those mails already. A Received line might look like: Received: from server.it.tried.to.send.to by redirecting.server (Postfix) with ESMTPS id 12345 for ; Mon, 12 Feb 2024 21:33:50 +0100 (CET) Ah well, it's a theoretical discussion anyway. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
Hey Bill, On 12.02.24 17:31, Bill Cole via mailop wrote: On 2024-02-12 at 07:13:13 UTC-0500 (Mon, 12 Feb 2024 13:13:13 +0100) Thomas Walter via mailop is rumored to have said: There are other issues with this though. For example you are exposing information you might not want to. Beyond that, it would enable both malicious reflection attacks and improper diversion of mail with very little visibility. I am not sure I understand your concerns, how would those work? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
On 12.02.24 11:59, Jaroslaw Rafa via mailop wrote: Dnia 11.02.2024 o godz. 00:10:54 Thomas Walter via mailop pisze: Remember when we had an SMTP status code 551? 551 User not local; please try Would be an ideal solution if sending SMTP servers would actually react to it like web browsers react to HTTP 301 or 302 status code, ie. automatically resend mail to specified . I do think that was the idea. If they don't, at least the user would be informed, but no user reads those error messages... There are other issues with this though. For example you are exposing information you might not want to. But then, so would bounces in case of currently used forwarding methods (plus backscatter...) Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
Remember when we had an SMTP status code 551? 551 User not local; please try Pepperidge Farm remembers. SCNR, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Hello Sebastian, On 10.02.24 05:02, Sebastian Nielsen via mailop wrote: just because SPF and DMARC are so badly designed that they can't handle it doesnt make it "forging" anything. It isn't badly designed. Forwarding a email, is the equvalient of, when you receive a signed envelope from me containing a letter, you forge my signature on the new envelope. It's actually the equivalent of striking through the recipient, writing a new one on the envelope and putting it back into the mailbox. This is a quite common behavior if people have moved for example. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] 2600 Magazine podcast about Gmail issues
Just a quick FYI: 2600 Magazine just did a podcast about the issue that they can't reach most of their subscribers because they're on Gmail and Google seems to not like hacking related content and either blocks it or pushes it to the spam folder: "We've gotten to the point where we've trusted Google with all of this information [...] making our decisions for us that we find ourselves now in a state [...] analogous to censorship on a state level". https://2600.com/offthehook/mp3files/2024/off_the_hook__20240207.mp3 They claim to have set up SPF, DKIM, DMARC, ... yet they get blocked by the Google wall if they include text about a hacker's conference. Regards Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] problem setting up open-dmarc
On 07.02.24 14:20, Jaroslaw Rafa via mailop wrote: For outgoing, Google requires that you have DMARC record set up. So if you are sending anything to Google, you need that. "If you send 5,000 messages a day or more..." Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Three word alliterations
Moin, we've been seeing a lot of mails since the weekend with three word alliterations as their only content. Examples: Subject: Agreda Body: Aleff Alick Alwood Subject: Decator Body: Dedomenico Degro Deiterman This looks to me like someone is testing addresses using a system like https://what3words.com as identifiers? But then a few of them have multiple recipients with different domains. I am not sure what to make of them. Does anyone else get these? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ OpenPGP_0x27A04D4FB37FD4F6.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamfolder mini rant (Was: Contact Google Postmaster)
On 28.01.24 20:02, Jaroslaw Rafa via mailop wrote: There are "edge cases" when the mail couldn't be reliably classified as spam or non-spam. Even with best tuned spam filtering systems false positives will happen. So why not just deliver these to the Inbox then - and add a tag/label instead if you have to? In 95% of the cases, I can just identify the bad emails by subject. A quick press on DEL and it's gone. I don't see any advantage of a Spam folder if I have to regularly check it anyway. In fact it can even be more difficult to identify a false positive between the Junk that collected in there. Plus there are still customers that use POP3 for different reasons (connectors that collect mails for internal Exchange systems for example). Those never get to see the content of a spam folder. Just having a binary distinction - reject or deliver to inbox - would be a much bigger obstacle to communication than delivering to spam folder, because it's still easier to reach the recipient in some different way and tell them to check the spam folder, than to make the recipient's provider fine-tune their email filtering to exempt you from rejection. It should be just as easy to contact the recipient and tell him his provider is blocking the email - and for the recipient itself to lift the block in some way instead of having to convince the provider. Of course, the users should be aware that they *should* check the spam folder, which means, the provider should inform them about this with a very clear and prominently visible message. Sadly, most providers don't do it, therefore the users are convinced that they don't need to check the spam folder at all, since it's clearly labelled "spam" or "junk", so "by definition" it cannot contain anything useful to them. We've done this in the past and sent out daily mails with a list of subjects that got sorted as Spam. After a week or so nobody read that email anymore. And after we had some issues with important documents and deadlines that got missed, because nobody checked their Spam folder, we just leave them in the Inbox. Yes, I do see my share of Spam this way, but I also do see the Spam if I have to check the Spam folder regularly… Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamfolder mini rant (Was: Contact Google Postmaster)
Hello, On 27.01.24 12:47, Laura Atkins via mailop wrote: There is remediation available. What there isn’t is some imprimatur that ensures that every email is delivered to the inbox every time unless the sender considers it spam and agrees with the decision. That’s just not how it works. Well, there could be if providers would stop delivering what they think is spam into spamfolders and reject it instead. To me it just doesn't make a lot of sense to basically have two inboxes to check - the regular one and the spamfolder. Also having to tell people to check their spamfolders every time they are missing an email is annoying too. I'd rather know that my email was considered spam than trying to figure out why someone did not reply after a few days. At least that would give me a chance to use a different contact method or try to resolve the issue in the first place. Yes, I know, spamfolders are used for training, but perhaps there should be other ways? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is Google jumping the gun for SPF / DKIM requirement?
Moin, On 25.01.24 04:48, Grant Taylor via mailop wrote: I knew that Google was going to start requiring SPF or DKIM (in addition to other sender guidelines [1]. But I thought they were starting February 1st, per their own sender guidelines. Just to clarify, because some of our customers were irritated by marketing emails from newsletter services. It's SPF or DKIM for < 5000 emails per day, but it's SPF AND DKIM AND DMARC for >=5000 emails per day. That said: Does anyone know if Google identifies "senders" by From:-Domain or IP? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP smuggling
Hello everyone, On 19.12.23 13:31, Mark Alley via mailop wrote: Hey all, recently saw this mail server SMTP vulnerability that popped up on a blog yesterday. Sharing here for those interested. https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/ <https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/> just for reference, here is the talk Timo gave at 37C3: https://youtu.be/V8KPV96g1To Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hotmail complains about their own mail
Hello Richard, On 16.12.23 18:12, Richard via mailop wrote: Your approach is generating backscatter spam (to hotmail, where the mail may not even have originated - the "From:" address is likely forged so your assumption that it originated from hotmail could well be wrong), which (being polite) is not considered a good thing. You need to reject the mail on the originating connection, rather than bouncing after acceptance. [you could consider tossing non-deliverable messages rather than bouncing them, but you could end up junking "legit" non-deliverables.] I wouldn't have mailed here if I hadn't checked the source first. Dec 15 20:46:06 speedy postfix/smtpd[64567]: ACC2D1FF9B: client=mail-westus2azolkn19012032.outbound.protection.outlook.com[52.103.10.32] Dec 15 20:46:06 speedy postfix/cleanup[64616]: ACC2D1FF9B: message-id= Dec 15 20:46:08 speedy postfix/qmgr[6907]: ACC2D1FF9B: from=, size=9557, nrcpt=1 (queue active) Backscatter spam *will* get you on blocklists. It was used as fallback for domains that have not been active for more than 5 years. We advise customers against using catchall and forwarding addresses, but… We've also set up recipient address verification in Postfix - which I know comes with its own problems - to try to keep these low. I am actually not sure why Postfix didn't catch this one which is completely handled locally. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hotmail complains about their own mail
On 16.12.23 12:11, ml+mailop--- via mailop wrote: On Sat, Dec 16, 2023, Thomas Walter via mailop wrote: 2. Our server bounces with 550 5.1.1 User doesn't exist. Does your server generate a DSN? If the "User doesn't exist" then it seems you should be able to determine that fact when RCPT is given -- or is this just a bogus reply? It's a catchall forwarded domain "@olddomain -> @newdomain", so Postfix accepted it before checking the final recipient. Now that you said it, I'm going to suggest to the user to just alias individual addresses instead of the catchall. I still think Microsoft should not complain about NDRs, especially if the original was from them. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Hotmail complains about their own mail
Hey guys, this was new: 1. Hotmail user sends delivery service phishing email. 2. Our server bounces with 550 5.1.1 User doesn't exist. 3. User marks non-delivery mail as Junk? 4. Hotmail sends complaint about the bounce message to our abuse. I'm not sure how to react to that. Would it be possible for Microsoft to not send complaints if the offending mail is a bounce message? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Outlook.com losing eMail messages and SNDS reporting failures
On 02.12.23 04:36, Randolf Richardson, Postmaster via mailop wrote: Some of my users have been reporting that eMail messages are getting lost intermittently when they're sent to users at any internet domain name that relies on OUTLOOK.COM for its MX. In German universities Microsoft's mail services had the reputation of randomly swallowing individual emails like a black hole - never to be found again. I haven't heard about issues like these for a while, but it was also difficult to recognize them in the past. Unless people expected an email, they didn't report them as lost. Most mailops I talked to expected it to be a spamfilter issue: E-Mails that got too bad of a score for random reasons were just not delivered, not even into the spamfolder. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
Hey Michael, On 13.07.23 00:53, Michael Peddemors via mailop wrote: And yes, email forwarding will break.. but email forwarding remotely should be killed off anyways.. everyone can log into two accounts. Everyone has always been able to log into two accounts. There are other reasons why this functionality was created. I have sold one of my personal domains. The buyer agreed to forward the personal address I had used to a new mailbox for a while. So I can switch over wherever it is still in use, have access to "2FA confirmations" or "password recovery" functions where needed, etc. I am not supposed to be able to send emails using their servers anymore, so I didn't get my own account. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] SMTP disconnect… (Was: Hosteurope contact?)
Hello, according to replies from Hosteurope it turns out our server with 212.201.120.206 is listed on csi.cloudmark.com. I can't find an RBL check to confirm that. The following two say, it is not: https://tinycp.com/page/show/rbl-check https://whois.smartweb.cz/en/blacklist/check/212.201.120.206/ And it is not listed anywhere else either https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a212.201.120.206=toolpage I just tried to have it removed anyway, since it seems to be the only way to fix this. Either way, I was irritated, why we don't get a proper 5xx status code in our logs, but just May 6 23:53:54 mx-out-02 postfix/smtp[14561]: 36119E0288: to=, relay=mx0.webpack.hosteurope.de[80.237.138.5]:25, delay=306795, delays=306794/0.17/0.18/0, dsn=4.4.2, status=deferred (lost connection with mx0.webpack.hosteurope.de[80.237.138.5] while performing the HELO handshake) Turns out mx-out-02:~$ nc mx0.webpack.hosteurope.de 25 220 mx0.webpack.hosteurope.de ESMTP (mi005.mc1.hosteurope.de) (even more power) Sun, 07 May 2023 00:03:13 +0200 ehlo mx-out-02.fh-muenster.de 550-REJECT: 212.201.120.206 is in csi.cloudmark.com : 550-Listed as Poor Reputation Sender. Cloudmark Sender Intelligence Reputation 550 Remediation Portal https://csi.cloudmark.com/en/reset (ID:550:3:0) mx-out-02:~$ All this trying to figure out what's going wrong, contacting support, etc. could've been avoided if they followed the RFC? https://www.rfc-editor.org/rfc/rfc5321#section-4.1.1.10 4.1.1.10. QUIT (QUIT) This command specifies that the receiver MUST send a "221 OK" reply, and then close the transmission channel. The receiver MUST NOT intentionally close the transmission channel until it receives and replies to a QUIT command (even if there was an error). Or is there a new version to the standards that allows this? Regards Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ OpenPGP_0x27A04D4FB37FD4F6.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hosteurope contact?
Hello, On 04.05.23 10:43, Ken Peng via mailop wrote: May 4, 2023 at 4:09 PM, "Thomas Walter via mailop" wrote: I am trying to get in contact with someone at Hosteurope to resolve delivery issues. I tried contacting their postmaster about a week ago, but did not receive a reply. It seems they have enough info (either tel or email) to be contacted: https://www.hosteurope.de/en/Host-Europe/Contact/ I've tried that and got the following reply: - Unfortunately, we cannot assign a customer number to your request. Please provide us with it so that we can process your request as quickly as possible. - Since we are not their customer, we don't have a customer number, so they can't process our request. I've explained that, but did not received a reply yet. That's why I hoped their postmasters are around on this list. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ OpenPGP_0x27A04D4FB37FD4F6.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Hosteurope contact?
Hello everyone, I am trying to get in contact with someone at Hosteurope to resolve delivery issues. I tried contacting their postmaster about a week ago, but did not receive a reply. May 3 10:40:39 mx-out-02 postfix/smtp[30657]: 67402E099E: to=<[censored]>, relay=mx0.webpack.hosteurope.de[80.237.138.5]:25, delay=0.17, delays=0.01/0/0.16/0, dsn=4.4.2, status=deferred (lost connection with mx0.webpack.hosteurope.de[80.237.138.5] while performing the HELO handshake) As far as I can check our mx-out-02.fh-muenster.de is not on blocklists. mx-out-01 has an identical setup and can send emails to the above server just fine. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ OpenPGP_0x27A04D4FB37FD4F6.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders
Hey Heiko, On 19.10.22 13:33, Heiko Schlittermann via mailop wrote: A given mailhost (ran privately for smaller entities) can't send messages to T-Online anymore. 554 IP=168.119.159.241 - A problem occurred. … The sending IP belongs to a rented host (rented from a major German hoster). The answer he (the owner of that host) got was about like this: (translation by me): Sorry, we only accept messages from proven commercial or similiar servers. Please use the SMTP relay of your hoster or your ISP. Did you contact T-Online postmasters about this issue or was this just the SMTP error message? I've been blocked by T-Online in the past, but after discussing things with them assuring that it is a regular mail system, it was unblocked again. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Certificate Question
Hey John, On 16.10.22 00:28, John Levine via mailop wrote: It appears that Mary via mailop said: I've never heard of SmarterMail server, I use dovecot. Dovecot allows me to setup 100+ domains on the same server, each with its own certificate, thus always giving a valid TLS connection without any certificate warnings. I've just learned that postfix 3.4 allows SNI based certificates… Does your IMAP server really have 100+ different names? That seems like a lot of effort for little benefit. imap.customer1.example imap.customer2.example imap.customer3.example imap.customer4.example ... Some day you don't want to explain "please use imap.provider.example to avoid certificate warnings" to each customer anymore. Also they usually want to use their own domain for everything. Regards, Thomas -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The oligopoly has won.
On 15.09.22 03:04, Brandon Long via mailop wrote: FWIW in Germany it's against the law to not deliver an email after you have accepted it. (Not sure if it made it to EU law yet…) Even spamfolders are a grey area unless you make sure your user is not only using POP3 to access the mailbox. This is an extraordinary claim. References? I am not a lawyer and it's difficult to discuss laws in a different language, but according to the definitions of the Telecommunications Act, anyone who provides e-mail services to others is obliged to maintain the secrecy of telecommunications. For this reason, they may not evaluate or disclose the data and, according to newer laws, may not suppress it either after they have accepted responsibility for delivery. There have been discussions that if a user does not know about a spam folder because he is using POP3 to access mails, the folder is not subscribed to in an IMAP environment, only INBOX emails are forwarded, etc. it can be seen as suppression by law. I am not aware of any principle decisions, but I'd rather not - using a German saying - have one foot in jail. What users to with their email (filters, automated deletion, etc) after you have delivered an email is their responsibility. It's also ok to reject an email at the gates, because then you are not taking responsibility for delivery. But post-queue filters for example are also problematic in that regard, because you can't ensure a bounce is received. As you can imageine, I do not want to discuss the usefulness of these specifications. As a German I just have to follow them - as us Germans do ;-) -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The oligopoly has won.
On 14.09.22 18:12, William Kern via mailop wrote: On 9/14/2022 7:49 AM, Thomas Walter via mailop wrote: Your users opinion may also change if they can't get that automated 'forgot my password' reset link from a service they want to use. No, they'll contact support and tell them they don't get the password reset link which we can then whitelist. In that case there is no one at the sender to know if it bounced (or worse, the sender may see the bounce and lock the account) Locking an account because an email bounced is wrong for multiple reasons. A middle ground is a tag quarantine policy. You tag the 'probably is spam' with a subject header that they can use to put in the Client spambox. You quarantine the definately is spam. That will cut down on the false positives and always gives them a recourse if they still got caught. Changing the subject of an email can create issues with signed/encrypted emails. According to German law it's also illegal to change email content (let's not start a discussion on feasibility please)… We do add X- headers for "possible spam" people can use to filter themselves, but it becomes their responsibility then. -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The oligopoly has won.
Moin, On 14.09.22 17:52, Slavko via mailop wrote: In my case, the false-positives are really rarely. Mostly when user meets new eshop (or so) with broken email system (and need to be WL -- but that seems to be improved in last year). The biggest problem, which i meet with false positives was with one new user, which (as only one) communicate in Deutsch, because before he come all Deutsch mails was SPAM, thus we have to (re)learn bayes filter first. He do not need to contact me, all what was needed was to move email from Junk to another folder and after certain count of emails it was solved. I'd love to use Ham/Spam filters, but in a very diverse environment (university campus) with users of all languages that's a difficult task to get right. I've seen "fights" between users where one group kept moving emails to their spam folders while others restored them after the algorithm learned they are "bad". And the complaints I get from Microsoft's mail services make it quite clear that you can't trust users to correctly categorize spam. :) In other words, my users watch Junk folder mostly in cases when they expect some email, which do not arrived. Now i check stats -- 0,7 % of all delivered messages was to Junk folder. I do no gather stats how many of them was false positive, but it is really, really small number. If it's only 0,7%, you should be able to press delete a few times more each day if those land in your inbox. Still better than to miss something important because it hid in a spam folder. Also what about the other 80+% Spam you receive every day? Do you reject those? -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The oligopoly has won.
On 14.09.22 14:16, Dan Malm via mailop wrote: I disagree hard on that one. We used to reject mails flagged as spam by our filters and it was wildly unpopular. Implementing delivery to a spam folder was very much welcomed by most users (though ofc you can't please everyone... We got some complaints, but far less than we got for rejecting) First of all: I am fed up with telling people to look for missing emails in their spamfolders. If I have to check a spamfolder for false positives every day, I can just have them delivered to my inbox. The spamfolder does not have an advantage then. Your user's opinion on that will change as soon as someone missed a bid or contract, because it hid in the spam folder :). If I send someone an email and get a reject, I know they didn't receive it. It's my job to make sure they get the email then or contact them using other means. That's a lot better than Schrödinger's mailbox where you don't know wether an email got delivered, got overlooked in a spamfolder or - even worse - blackholed. -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The oligopoly has won.
On 14.09.22 11:24, Renaud Allard via mailop wrote: On 9/14/22 10:57, Alessandro Vesely via mailop wrote: * Stop blackholing. That one is the absolute worst of the worst of the worst. Blackholing is something that _MUST NOT_ be done, ever, for whatever reason. There is never and has never been a good reason for blackholing. If you don't like a mail, give it a 5XX error, never accept it. When you have accepted a mail you MUST deliver it. FWIW in Germany it's against the law to not deliver an email after you have accepted it. (Not sure if it made it to EU law yet…) Even spamfolders are a grey area unless you make sure your user is not only using POP3 to access the mailbox. -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The oligopoly has won.
On 12.09.22 21:50, Brandon Long via mailop wrote: By their very nature, the personal servers that people are talking about here just don't see the same volume of spam. But this is exactly the other direction from which you might want to look at it? Of course you receive more Spam in numbers, volume and from external sources than a personal server. And even if freemailer's outgoing emails have a pretty small spam/ham ratio, that ratio will be be a lot of bad mails if you look at the overall numbers. At least on my campus machines a lot of the spam that I have to manually block with content rules (because unlike them, I can't just block IP ranges and tell them to live with it) seems to be abused accounts from the big guys. To be clear - I'm not necessarily pointing at you Brandon :) -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The oligopoly has won.
On 12.09.22 12:14, Evert Mouw via mailop wrote: After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won. What bothers me most is that the oligopoly makes it impossible to deliver emails to protect their users from spam, yet it is the biggest source of it… But who am I telling that? -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] mailop charter (Was: SMTP noise from *.bouncer.cloud)
Hello Christopher, On 03.09.22 00:13, Christopher Hawker via mailop wrote: Seems like a whole lot of bitching and whinging is going on here regarding bouncer.cloud. Pretty sure this is a mail operations list, not a “let’s whinge and complain about mail services” list On https://www.mailop.org/ it is written: > Charter: > > * Discussion must focus on operations of mail systems. This includes > technical, policy, and commercial discussion. These kind of discussions are explicitely part of the list. > * Postings that include foul language, character assassination, and > lack of respect for other participants are prohibited. Calling a discussion "bitching and whinging" shows lack of respect for other participants. Please keep this off list It's quite simple. If you don't like or want to take part in it, filter the conversation and mark it read or move it to the Trash folder. -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] USGOabuse.net?
Hello, I have just received an abuse report from USGOabuse.net regarding an incident that happened on July 6th and was resolved immediately: Abuse report for email from: 212.201.120.206. Email was received: Tue, 06 Jul 2021 03:31:52 -0500 (CDT). IP Address 212.201.120.206 is now blacklisted. They want me to acknowledge the report by going to http://m.USGOabuse.net/_AbuseAck and ask for some strings. Otherwise "Repeated reports regarding the same source that are unacknowledged will eventually result in blacklisting" - which it already did according to the summary above? I can't find anything about USGOabuse.net otherwise - they don't seem to have a website, whois points to https://usfamily.net/ which points to a sister company "Velocity Telephone"... Does anyone know anything about them? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why TLS is better without STARTTLS
On 09.08.21 18:18, Grant Taylor via mailop wrote: Did the researchers include protocol vulnerabilities and / or implementation vulnerabilities and / or configuration vulnerabilities? I'm sorry, I don't have more details than I've linked to so far. The page includes a preprint, but I am not sure if it is the full / most up to date version of the paper Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Why TLS is better without STARTTLS
Hey guys, just a quick heads up on a paper that will be published at USENIX Security 21 about "A Security Analysis of STARTTLS in the Email Context". Don't panic! Or as quoted from the document: > How important is this? > [It's not the most important thing you should worry about today.] > (https://www.ipcc.ch/assessment-report/ar6/) Security researchers of our university and an independent researcher examined possible attacks on email clients and servers that use STARTTLS. They have found more than 40 vulnerabilities in STARTTLS implementations. https://nostarttls.secvuln.info/ Their conclusion is that all vulnerabilities rely on the transition of an insecure connection to a secure connection. > Implicit TLS does not have such a transition and is therefore not vulnerable to any of these attacks. We therefore consider implicit TLS a more secure option than STARTTLS. Which I think most of us already knew/expected? While it does not seem to be an urgent issue, it might help if we'd get people to switch to implicit TLS where possible… Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] m-365 still works like a spammer !
Hi, On 23.07.21 19:44, Xavier Beaudouin via mailop wrote: Well had another domain with 10 priority, same bloody behavior... Still don't understand why Microsoft does not implements RFC974 as it should... (well Microsoft and the mail has been a lng way to break all RFCs but... in this case they are not good at all...). Do you greylist or anything similar on the lower preference machine? I have seen servers switch over to a higher preference MX for all kinds of reasons so fast it looked like they were tried first in the logs. Regarding RFC974 If the list of MX RRs is not empty, the mailer SHOULD try to deliver the message to the MXs in order (lowest preference value tried first). The mailer IS REQUIRED to attempt delivery to the lowest valued MX. Implementors are ENCOURAGED to write mailers so that they try the MXs in order until one of the MXs accepts the message, or all the MXs have been tried. It's been a while since I looked at this, but isn't "SHOULD" a recommendation? I understand this collides with the next "IS REQUIRED", but...? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mail.ru broke mailing lists
On 19.07.21 10:56, Tim Bray via mailop wrote: I do this. For a corporate email system is makes a lot of sense. I shouldn't be receiving email externally with a From: domain which is local. As long as your users don't have an external mailbox which gets forwarded to the local one. In that case a local user can send to that external address and it gets forwarded from an external server to the local domain - with the local domain as From. There are other cases, but that is one example which happens with a lot of students here. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] polspam.pl contacts?
Hello guys, does anyone know how to get in contact with the polspam.pl blacklist owners? Their contact form does not work and the website footer lists an email address, but asks to "not send any messages to this address". Regards Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster University of Applied Sciences Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83-64908 Fax: +49 251 83-64910 E-Mail: b...@fh-muenster.de https://www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hen and egg problem with Talos
On 07.07.21 23:12, Jay Hennigan via mailop wrote: >> Encourage transparent 2FA, and options like country auth restrictions, >> blocking AUTH from cloud providers/hosting companies known for being a >> haven for those types of attacks, (should make a blog post on best >> practices for authentication on email servers one day) but.. > > [snip] > > Fail2ban can be very useful here. It's running to protect against brute force attacks, but it doesn't help against phished passwords. We also check against the number of different client addresses, since they often use multiple bot hosts - spread all over the world - after the data was phished. But this time it was just one host. Regards Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster University of Applied Sciences Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83-64908 Fax: +49 251 83-64910 E-Mail: b...@fh-muenster.de https://www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hen and egg problem with Talos
On 07.07.21 22:08, Michael Peddemors via mailop wrote: > Start by including the IP(s) you are discussing ;) mx-out-01.fh-muenster.de [185.149.214.63] mx-out-02.fh-muenster.de [212.201.120.206] > Compromised accounts are indeed the bane of the responsible > administrator, and as you can see.. the rate limiting systems ARE > essential, you are unlikely to suffer a reputation issue, if only a few > escape (unless they have REALLY bad content, your mail server should not > be processing). Absolutely. That's why we had rate limits in place for different markers: mailcounts each by sender address, authenticated user and client in different time frames. So far this had worked fine. So that other can learn from our mistake: Someone whitelisted the internal Exchange systems from the clients, because they kept triggering the limits, believing they'd get caught by the other markers which they did not. > Encourage transparent 2FA, and options like country auth restrictions, > blocking AUTH from cloud providers/hosting companies known for being a > haven for those types of attacks, (should make a blog post on best > practices for authentication on email servers one day) but.. Please do :) - I have actually thought about limiting AUTH to local networks, because we have VPN available for all clients - which would add another level. But that requires some effort from the "customers" and of course was not well received. It could also be circumvented after a user's credentials were phished. > As you correctly noted, yes.. cleaning up your reputation and getting > off blacklists IS the punishment for not being pro-active on issues like > that. It isn't the blacklist operators fault after all ;) I fully agree. And I've added another self-flagellation by posting here ;) > Most blacklists and reputation services are pretty understanding, if you > clearly communicate, and your email server is for the most part > professionally operated. And remember, be kind to them, they aren't your > enemy, and they probably get more than their fair of yelling and > screaming.. I'd never do anything like that. Especially since it's our fault and I have been doing this long enough to appreciate their work - after all they are my own line of defense too. > Now, having said that.. it is ALWAYS best to follow the posted > procedures for asking for removal, but if it does NOT fix things in say > 48 hours (hard to wait when you have screaming customers I know) then > their are good people on this list and others that can help you, as long > as you show that you already following their SOP for removal. I was able to switch over to other outgoing servers for now, so the customers have extinguished their torches (most of them didn't even notice). I am just confused on how to fix the reputation of those two boxes by sending emails without being able to send emails. Regards Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster University of Applied Sciences Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83-64908 Fax: +49 251 83-64910 E-Mail: b...@fh-muenster.de https://www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Hen and egg problem with Talos
Hey guys, I have to take the walk of shame and report a spam outbreak on my systems because of a phished user account and a loophole in the rate limiting we do. As soon as we got notifed, we stopped and cleaned the queues, blocked the user, investigated the cause and fixed the rate limiting before restarting. Of course this put us on multiple blacklists and cleaning those up is the proper punishment I guess. Now two of our outgoing systems are still rated as poor on Talos. If we use them to send emails, those will get rejected by a lot of recipients (public sector). But if we don't use them to send emails, their reputation at Talos will not improve since support tells us "reputation improves as the ratio of legitimate mails increases with respect to the number of complaints". Do you guys have any hints on what is the proper way out of this circle? Regards Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster University of Applied Sciences Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83-64908 Fax: +49 251 83-64910 E-Mail: b...@fh-muenster.de https://www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail's MTA is broken
'llo, On 07.06.21 20:13, Mark Milhollan via mailop wrote: > In general Google's MTA handles SMTP just fine. But an MTA isn't always > run in a way that blindly follows the RFCs. And there's also systems that send a 5xx and immediately disconnect without waiting for the "quit" from the initiating party to properly terminate the SMTP session. In those cases MTAs following the RFCs see this as a failed connection and try again, no matter if the return code specified a permanent or temporary issue. It's been a while since I tracked systems like that, but it happened. Regards, Thomas -- Thomas Walter Datenverarbeitungszentrale FH Münster University of Applied Sciences Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83-64908 Fax: +49 251 83-64910 E-Mail: b...@fh-muenster.de https://www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received
On 11.05.21 19:45, André Peters via mailop wrote: > What is this crap good for when it sends one out of 1000? There was not > a single spam mail that left our system. It was an unwanted mail, not > spam but just a message they did not like. We have hard rate limits and > a no mass mail policy. We also check ridiculously detailed for patterns > of spam. This has been discussed here before. One reason for most of the reports I get is from users that have a language barrier that obscures the difference between Junk and Trash for deleted e-mails. Another issue is that a lot of users think of spam as being "unwanted" email nowadays. I am actually avoiding Bayes filtering, because I don't feel I can trust our users with their decisions. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Haraka status? Exim the only choice? (v Postfix)
On 01.05.21 09:05, Chris via mailop wrote: > Heh. You've never used Qpsmtpd or Haraka, I can tell. Haraka and Nope. Didn't have to. That's why I was curious about use cases that were not possible with the more common MTAs. > qpsmtpd are basically skeletons where you can insert plugins to > do/redefine anything you want pre/during/post any step of SMTP. Want to > extend/redefine SMTP? Sure. Parallelize queries to any kind of > database? Fine. Regexp subjects and programmatically blackhole, nuke, > reject or temp? Fine. Skip steps when you've already decided you don't > want it? Fine. So, like the basic Postfix skeleton that comes fully assembled and is not missing its fingers? ;-) Don't like the smtpd? You can swap it with anything else, can't you? AFAIK the interface between postfix's modules are all well defined? Yes, of course that's not an easy task to do, but it doesn't sound like there is a lot less of coding for Qpsmtpd or Haraka either? I have scripted my own little policy daemon for postfix in PHP to do some basic checks and rate limiting. That doesn't give me access to the raw smtp data, but to a whole lot of data from it Rspamd seems to get enough data from postfix's milter interface to do proper and fast antispam filtering and you can extend that with all kinds of LUA functions. Yes, that's not postfix, but in a way, it's just a plugin like the others need too? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Haraka status? Exim the only choice? (v Postfix)
Hello MRob, On 01.05.21 05:18, MRob via mailop wrote: > I used Postfix along time but my experience is that it is incredible > difficult to implement custom logic especially across the different > binaries/processes it uses to fulfil a mail delivery transaction. Its > designed in the "unix philosophy" and has good performance - great but > Postfix devs normally react hostile if asked for advanced features that > require tracking meta-information about messages across Postfix > processes. Its only the RFC compliant mail message state that persisting > through the entire transaction, nothing more. Milters can be injected > but have limitations and I get headaches from the configuration system. > I shouldn't complain too hard tho, because I'm grateful for how solid > and secure and bulletproof it has been. Thank you team Postfix. While I understand your frustration, I wonder what "advanced feature" you are looking for. In the end you can override each and every single Postfix element or how they interact. It's that flexibility that gives me most of my headaches. Regards Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: Some Days I think that Gmail isn't even trying to stop outbound spam..
Hello, On 05.02.21 17:23, Andrew C Aitchison via mailop wrote: > Would it be useful to include a link in each email header, similar to > List-Unsubscribe: and relatives, but unique to each message sent, > so that recipients could give similar feedback to the sending service ? You can not trust users to identify spam. "I don't want emails from my aunt twice a week.", "I don't want to receive this subscribed newsletter anymore, but I don't bother to unsubscribe", ... all these are "SPAM!" these days. Also receiving multiple abuse emails per week from Microsoft because users can not differentiate between "Junk" and "Trash" (if only because of language issues) really made me mistrust that system. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] RFCs on quoted pairs in From:?
On 28.01.21 12:37, Alessandro Vesely via mailop wrote: > On Thu 28/Jan/2021 11:05:37 +0100 Thomas Walter via mailop wrote: >> swaks --server mx3.fh-muenster.de \ >> --to 'b...@fh-muenster.de' --from 'b...@fh-muenster.de' \ >> --header-From '"Some Person " ' >> >> I am going to report this as an issue with Thunderbird. I just was not >> sure if I did get the RFC wrong and it was a non-problem. > > > TB is replying to the --to field, not the display-name address in > --header-From. No, it does not. And that is exactly the problem. If I reply to the above email, it is sent to 'Some Person ' which is neither the Envelope-From, not the Header-From, but the address in the quoted display-name. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] RFCs on quoted pairs in From:?
On 28.01.21 10:38, Dan Malm via mailop wrote: > On 2021-01-27 13:40, Thomas Walter via mailop wrote: >> While playing with this I noticed that Thunderbird shows the full header >> field without quotes and replies go to the first address - even though I >> thought that is just the "name/description/comment" part? > > Are you sure it's not just that the replies goes to whatever is in the > Reply-to header? Yes. My test emails did not have a reply-to header :) I have generated them with swaks --server mx3.fh-muenster.de \ --to 'b...@fh-muenster.de' --from 'b...@fh-muenster.de' \ --header-From '"Some Person " ' I am going to report this as an issue with Thunderbird. I just was not sure if I did get the RFC wrong and it was a non-problem. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] RFCs on quoted pairs in From:?
Hello, On 28.01.21 07:29, Jay R. Ashworth via mailop wrote: > So you agree with him that an angle-bracketed address *inside quotes* should > be ignored by an MUA -- at least if there's a valid address not inside quotes > in the same header? > > Should the MUA go inside the quotes in the header to find one if there isn't > one that's quoted? Or should it error out as "no address to reply to"? > I would think it should error; the 'protection' of the quoting shouldn't > be conditional. > > Sounds like Thomas thinks Tbird has a bug in its header parsing code, and I > agree with him -- and, I think, you. That's exactly what I am thinking, but was not sure about. Address formatting in mail headers is not exactly simple. It's one reason why I'm always irritated when people are using regexps to match on those. Heck " "@example.com is a proper email address and I am a little tickled to use that and confuse the heck out of people (but most software too I guess). Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] RFCs on quoted pairs in From:?
Hello everyone,
I have a question regarding the standards on mail headers, specifically
quoted-pairs in the From: header line.
My understanding is that a quoted pair can contain characters that
otherwise would be treated differently. Characters like spaces, but also
angle brackets and such.
So in the following header, the address should be the last part in angle
brackets (""), but the first part should be the
"name" part, including the angle-brackets and email - "Some Person
"?
From: "Some Person "
I am asking, because for a while now we have seen lots of phishing
emails hiding their sender address behind an additional email address in
the name. Which works really well in mail clients only showing the name
part otherwise - not pointing fingers, but I hate that...
While playing with this I noticed that Thunderbird shows the full header
field without quotes and replies go to the first address - even though I
thought that is just the "name/description/comment" part?
And I wonder if that is an issue or if I just get the quoted-pairs part
of the RFCs wrong.
Same with comment braces like this:
From: (Some Person )
Thunderbird replies to "(Some Person " in that case.
Is either correct?
Regards,
Thomas Walter
--
Thomas Walter
Datenverarbeitungszentrale
FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster
Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail & SPF=none & Adobe campaign
On 14.01.21 19:08, Pascal HOARAU via mailop wrote: > Extra quotes are OK cf : https://kb.isc.org/docs/aa-00356 > <https://kb.isc.org/docs/aa-00356> > And strings are all no longer than 255 characters. While this is true there are libraries that do not support it. I have seen multiple SPF check sites that got those wrong and reported issues. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: What's the point of secondary MX servers?
On 18.12.20 02:58, John Levine via mailop wrote: > In article <469F9E736EE5DB4A8C04A6F7527268FA01CA03E20B@MACNT35.macro.local> > you write: >> Hi >> >> Where we have multiple internet connections, we setup MX records for both >> connections. If one connection is down, >> email flows through the other one. > > That sounds like two equal priority MX records. No problem with that. > > Personally I'd use two A records for one name, but whatever. That's round robin, not "backup"? Systems will "randomly" connect to both connections and fail if one line is down - which was not the intention here. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 17.12.20 23:07, Mark Fletcher via mailop wrote: > If this is really an issue, why don't we have backup A records as well? > My website is just as important as my MXes, yet I do just fine without A > record priorities... > > I agree with John, MX record priorities are an unneeded relic. You can use MX priorities on the inside too. For example to specify outgoing or nexthop servers in transport maps and the likes. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Looking for possible mailing list hosting
On 16.12.20 18:21, Scott Mutter via mailop wrote: > Honestly, I see mailing lists as a dying breed (said as I post this to a > mailing list). A forum tends to work out better. It's a pull (users > pull content only if they want to receive the content) rather than a > push (users are pushed content - if they are subscribed - whether they > want to or not). And a lot of times push is exactly what is needed. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Current OSS anti-spam software best practice?
Hey, On 16.12.20 10:42, Ralf Schenk via mailop wrote: > we are still on amavisd + SpamAssassin incl. some best-practices > rule-sets but there is a promising alternative: > > https://www.syn-flut.de/rspamd-das-bessere-spamassassin > > https://www.heinlein-support.de/sites/default/files/Rspamd_und_Mailinfrastruktur_Heinlein-Support_2018.pdf we switched over to rspamd quite a while ago and will not look back. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] GMail 550 5.1.1?
On 15.12.20 11:16, Jaroslaw Rafa via mailop wrote: > I wonder why they are returning 5xx and not 4xx when they have a failure. I > think the system should be foolproof enough to return 4xx in such cases. With all the services being down at the same time I am expecting it to be an issue with the central "user database" itself. In that case their mailserver simply didn't know users existed. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] GMail 550 5.1.1?
Hey, On 15.12.20 01:13, Jay Hennigan via mailop wrote: > Many Google services including Gmail, Google Drive, and YouTube have > been having issues today according to Outages mailing list. Though some > are reporting restoration this could be lingering problems. https://www.google.com/appsstatus#hl=en=status GMail is still listed as having issues: "We're investigating reports of an issue with Gmail. We will provide more information shortly." Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Effeciveness (or not) of SPF
Hey Brandon, On 09.12.20 00:55, Brandon Long via mailop wrote: > > On Tue, Dec 8, 2020 at 1:31 AM Paul Smith via mailop <mailto:mailop@mailop.org>> wrote: > If you're forwarding to your own company's mail server, then it should > be easy to have that forwarding work with SPF, and if you're forwarding > to someone like gmail, then, to be honest, it should be relatively > trivial for them to *USE* SPF to allow forwarding to them. I could tell > Google to allow a specific domain to forward to me (the domain of the > forwarder), and they use the SPF record for that domain to validate the > IP addresses that can then forward and override other SPF checks. > > > That feature was on my backlog at Gmail for a long time, but never high > enough priority > to get off it... now it would probably use ARC instead unless that > becomes a pipe dream, > at least theoretically with ARC we could just learn it and not worry > about the user interface > and confusing users. Interested question: Your systems could learn something like that too? If a number of emails come in to the same recipient with "failing" SPF from the same host(s)/domains it is probably a forwarder to that recipient? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Effeciveness (or not) of SPF
On 08.12.20 11:58, Paul Smith via mailop wrote: > Verifying the sender is who they say they are is valuable, even if some > people are fooled by messages from "b...@micr0soft.com". For that it would help _a lot_ if mail clients didn't stop displaying the actual address of the sender. Yes, I am looking at you, Outlook et al. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Effeciveness (or not) of SPF
On 08.12.20 02:02, Grant Taylor via mailop wrote: > Obviously I disagree. Thankfully SPF w/ -all allows second order > receivers to know that I have not authorized the first order receiver to > re-send email on behalf of my domain name. So in that case you are against servers supporting SRS since it breaks your idea of how email should work? This discussion really reminds me why I never liked this broken by design concept and never will. Yet I am forced to support it, because the big fishes decided otherwise. Can someone point me to statistics about how effective SPF is compared to other antispam measures? Spammers using phished/hacked accounts don't care. Spammers with their own domains just add SPF records and can easily include (hacked) third party systems? Phishers just use mail0p.org with correct SPF records to foil targets or just use 'From: "Example " ' since modern MUAs decided it's a good idea to not show mail addresses anymore... Perhaps I should just start looking into botany. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Effeciveness (or not) of SPF
On 07.12.20 22:47, John Levine via mailop wrote: > People do use them as part of a scoring spam filter. But no sensible person > uses SPF alone to do mail filtering. I also thought that no sensible person would discard messages even though the SPF entry owner asks them to do a softfail, but I guess I was wrong. > Uh, no. I have lots of users with role accounts who read their mail at > gmail. Forwarding is as useful as it ever was, even though it is ever > harder to to do successfully. I fully agree, but gmail is a bad example, because they actually support importing remote mailboxes with pop3 which does not require forwarding. We never tried that, but it is an option: https://support.google.com/mail/answer/21289 But yes, please do not bash forwarding, just because someone invented a mechanism that ignored the basics of email traffic. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Effeciveness (or not) of SPF
On 06.12.20 19:27, Mary via mailop wrote: > Now, having a large list of real email bodies, they re-use them for phishing. > They re-send a previously legitimate email but with variations, like > replacing attachments. They can also send mail directly from the inside - without any SPF checks in place and quite often without any antispam or antivirus measures as long as the email stays on the inside? And use the correct user's address? At least that's what happened here in one incident. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] from= to=?
Hello Ops, does anyone know what mail client probes(?) email connections with from= to=? I am preparing to enforce the sender address to match the user account, but I am now seeing warnings with these combinations. According to the helo it seems to be IOS devices likes iPhones and iPads. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New server email being treated as spam by Google
Hello, On 21.11.20 12:54, Jaroslaw Rafa via mailop wrote: > You can configure your MTA to disable IPv6 only for delivery to Google - at > least with Postfix it should be possible. how would one do that? We don't know all domains that sue Google MXs, we don't know all MXs Google uses and they might change. Do we know Google's IPv6 addresses? Do those change? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Maximum message size
On 24.10.20 00:48, Adam Moffett via mailop wrote: > Nail on head Brandon. > > An additional argument is how much support labor is it worth to > guide/force/teach the use of cloud storage compared to the risks of > allowing larger emails? One of these is things is way easier. Someday > I may bow to the needs of ignorance because it's easier. I am pretty sure none of your users sends encrypted emails, do they? Inside of a company perhaps, but between different ones? Usually not. Explaining that is a lot more difficult than having a file exchange system in whatever form. (BTW still the easiest way to get an unencrypted text or unprotected zip file is to just tell them you can't open it.) Then there's the issue of the law defining retention times, audit compliant storage, backups and such for business communication which does get a lot more difficult if big files are involved. Besides email transports not being made for file transfer, the storage mechanisms of MUAs aren't made for big files either. Email is for sending letters, let DHL handle the bigger boxes. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Maximum message size
On 23.10.20 22:51, Jay Hennigan via mailop wrote: > Perhaps someone should come up with a protocol designed to transfer > files. They could name it File Transfer Protocol and abbreviate it FTP. I'd prefer something with "Secure" in it's name though, preferably in the front, so it shows the importance of it. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Delivery problem on Microsoft e-mail (code 250 but does not receive)
Heyho, On 21.10.20 11:38, Laura Atkins via mailop wrote: > Microsoft has always silently dropped mail on the floor when it judges > that to be the right thing to do. It’s an issue and I personally believe > it’s bad practice. But I’m pretty sure that Microsoft have their reasons I've mentioned it before, but that practice is illegal in Germany. Sadly nobody seems to care enough. In layman's terms the law says that every mail (e or not) you accept has to be delivered to the recipient. The proper way is to check the email during delivery and either accept (and then deliver it to the final recipient) or reject it (so that responsibility stays with the sender). But then again, you probably accept it somewhere in an EULA. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] GMX.net
Hey Jeremy, On 14.10.20 02:09, Jeremy Weiss via mailop wrote: > But this customer's PTR records look to be in order. Does anyone have a > GMX.net contact I could reach out to for more information? it would help a lot if we knew the IP in question. That way we could check if it not only "looks to be in order", but if it is. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any chance that Microsoft would tell it's customer that the 'junk' folder creates complaints?
Hey fellow mailmasters, On 24.09.20 10:10, Benoit Panizzon via mailop wrote: > Now the Microsoft customer contacted us, that he had indeed subscribed > to the newsletter of our customer and still wanted to receive it. So we > checked with the recipient WHY he kept reporting those emails as spam > and he told us, that after he reads newsletter he didn't want to keep, > he put them in the 'junk' folder as he considered them 'junk'. He was > NOT aware that this would cause a complaint NOR could he find any such > information. I am having the same issue multiple times a week because users do not understand the difference between Junk and Trash - which might also be a language issue if you are not a native speaker. In our case students move official e-mails to Junk after reading them and are always surprised when I contact them to explain the difference between Junk and Trash. BTW - "Spam" also is a bad name for those folders, because the word now seems to be a catch-all phrase for "E-Mails I do not like". Mit freundlichen Grüßen, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] United Internet X-UI-*Filterresults headers?
Hello wonderful people, one of our clients is forwarding E-Mails from geocaching.com that are sent to GMX to his personal mailbox with us. Some of them are being rejected as SPAM, main reason being that our rspamd feels if United Internet thinks it SPAM, we should do so too. According to the UI headers, GMX thinks these are Schroedingers Spam - they are not, but they are? [...] X-Spam-Flag: NO X-UI-Filterresults: notjunk:1;V03:K0:Vf6iW93DjHQ=:AGDIE9XztBOZ9NwiPnKi2ALoF0 [...] X-Spam-Flag: YES X-UI-Out-Filterresults: junk:10;V03:K0:v3J1PWV5W7c=:sJZq98Urm/hQlOiYxtZTdsBj [...] Does anyone know the difference between the X-UI-Filterresults and the X-UI-Out-Filterresults? Regards from Germany, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Google and Spam detection
Hi, On 24.07.20 18:09, Marcel Becker via mailop wrote: > Not saying that it's the case here (what do I know about Google's spam > filters or your friends...) but sometimes the cause for this is on the > receiving end and quite low tech. Ie: We have quite a few cases where > users mark mail from uncle Bob as spam and then complain that mail from > uncle Bob is in the spam folder. oh how I loathe the more or less daily abuse messages from Microsoft's mail services that are perfectly reasonable e-mails from students or staff. Users either don't understand what it means if they mark an email as spam or they don't understand the difference between trash and junk - which can be a language / translation issue... And they are always really happy when I contact them and tell them everything about the full mail content that got forwarded to abuse. If you ask people about Spam, a lot of them will tell you it is "annoying email they don't want to think about", not bulk unsolicited messages for the purposes of advertising, phishing, malware, etc. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Is DNS-over-HTTPS bad? Sure.
On 07.07.20 06:59, Andrew C Aitchison via mailop wrote: >> Historically, 'choosing' to set your DNS provider at the OS was an end >> user choice, but with D'oh, it opens the door to the application layer >> to bypass firewall rules as well. > > ?? Historically the DNS provider was set by the machine's admin, > not by the user. On any multi-user system that difference mattered. And exactly that will happen on the desktop in enterprise environments with DNS or DOH as with any other setting. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Is DNS-over-HTTPS bad? Sure. (was: Happy Holidays Everyone!)
Hello Jaroslaw, On 06.07.20 12:39, Jaroslaw Rafa via mailop wrote: > But is content filtering - especially in corporations - really based on DNS? yes. That's why systems like https://pi-hole.net/ exist, even for home users. In Germany ISPs were even forced by lawmakers to block specific DNS hostnames from resolving some years ago, because they thought it was an option to block access to unlawful websites. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Abusix Potentially Compromised Account Report
On 19.05.20 13:11, Andrew C Aitchison via mailop wrote: > A bug/issue tracking system or othe5r "help desk" tool > *may* be a better solution here ... That's a little overkill for boss & secretary environments. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Abusix Potentially Compromised Account Report
Hey Jaroslaw, On 19.05.20 12:01, Jaroslaw Rafa via mailop wrote: > A shared account by itself is a security loophole. Why is that? You can perfectly share an account with IMAP4 Access Control Lists. The issue is not the shared account, the issue is a shared password. > There are no practical scenarios that justify the existence and use of > shared accounts. > Use a mailing list instead. And multiply each and every mail to multiple people, making it difficult to see which has been replied to and not having shared drafts or templates? No, thanks. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Abusix Potentially Compromised Account Report
Hey everyone, On 22.03.20 05:11, Ted Cooper via mailop wrote: > Has anyone run into "Abusix" /potentially/ compromised account > notification emails before? I got the same email with some of our local accounts and aliases. Interestingly enough it included the same IP address 185.234.219.89. Checking my logs I have multiple failed logins from the address including the accounts they listed, but some more too. I wonder what kind of "Spamtraps" they use and why the attacker uses our local accounts to fall into those? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Hey.com?
So, this https://hey.com/ has been making it rounds through my filter
bubble.
It seems to be a new concept(?) for an email service ("not client" as
the emphasize) by the Basecamp guys.
They say
> [Mail] deserves a dust off. A renovation. Modernized for the way we
> email today.
>
> With HEY, we’ve done just that. It’s a redo, a rethink, a simplified,
> potent reintroduction of email. A fresh start, the way it should be.
David Heinemeier Hansson (https://twitter.com/dhh) has been mentioning
it on Twitter now and then and there are some rumors, but I haven't
heard much else.
Anyone on here who knows more?
Regards from Germany,
Thomas Walter
--
Thomas Walter
Datenverarbeitungszentrale
FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster
Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [ext] Re: Business justification to use noreply sender addresses?
On 07.02.20 14:53, Jaroslaw Rafa via mailop wrote: >> If you're using a MLM, the "real" bounces go to the bounce processor >> of the MLM. But stuff like Exchange/Outlook will autoreply to the >> "From:"-Header address. > > I don't understand - what does "noreply" address have to do with > autoresponders? > Autoresponders don't send mail from a "noreply" address. They almost always > send mail from the address of the actual recipient of the message. They answer to mails from noreply-Addresses. > MLMs don't use "noreply" address as well - they use their own list-specific > "bounce" address as envelope-from. Yes, but Exchange/Outlook will not reply to the Envelope sender, but to the From: as Ralf stated. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
On 04.02.20 11:31, Jaroslaw Rafa via mailop wrote: > However, for big web-based email providers like Google, who tend to have > less educated users ;), it would be a good idea what Brandon already > mentioned here - some way of signalling in the GUI that a particular message > has not yet been sent, but is waiting in the queue. People don't understand why there are unsent messages in their current outbox if they accidentally switched their MUA to offline mode. They won't understand this either. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] MUA archaeology
Hey John, On 11.12.19 18:07, John Levine via mailop wrote: > I have my mail presorted into IMAP folders (with procmail of course) > and could never figure out how to make mutt scan them for new mail > like Alpine does automatically. http://www.mutt.org/doc/manual/#imap-check-subscribed Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] BIMI
On 05.12.19 02:20, Matt Vernhout via mailop wrote: > Stay tuned for more info on the bimigroup.org website, we are planning to add > more info very soon. But why? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Junk filtering as a tool for unfair competition
Hay Jay, On 24.10.19 01:58, Jay Hennigan via mailop wrote: > It does seem that the user behavior of incorrectly marking mail as spam > has been going on far too long. Large webmail providers, PLEASE update > your UI to label that choice "Report as spam", not simply "Junk". This doesn't help as long as users categorize "emails I don't like right now" as Spam. For example a lot of our students seem to be sorting official university emails that remind them to re-register or important test reminders as "Junk". E-Mails they have explicitely subscribed to and that are important for their academic career. Users can not be trusted to categorize emails. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Junk filtering as a tool for unfair competition
On 23.10.19 10:11, Stefano Bagnara via mailop wrote: > PS: I REALLY don't think Microsoft is doing filtering for "unfair > competition", as I also receive Microsoft own invoices for an Office365 > plan I buy in my office365 junk folder. I simply guess SmartScreen is > somehow "out of control" (or too much a black box) and very few people > are able to check the reasons SmartScreen does something and confirm > it's doing right. I also don't want to blame microsoft for trying to > "hide things" as I've been on the antispam side, too, and I know how > much spammers can learn from few data, but I can tell Smartscreen seems > really weird from the outside and sometimes I feel there's some dice > roll behind the scene ;-) SmartScreen sounds like it's an AI learning what's good and bad. If it is, it is probably affected by the typical machine learning problem: Nobody knows why it does it this way. It taught itself. And if you try to fix that by teaching the rights from wrongs, it usually gets wors or totally out of control. So you don't. I've seen comments about this being another weapon in the "sorry, we can't do anything about it, its automated" arsenal. I myself am pretty sure that Skynet will start just like this. An AI that decides on things and nobody knows why. It's not the "humans are bad, destroy all humans", it's more going to be like: "Kill all humans to see how this affects my decision making". Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Junk filtering as a tool for unfair competition
On 23.10.19 08:51, Sébastien Riccio via mailop wrote: > This will have to change. Do small operators need to start a petition against > this ? I'm going to send thoughts and prayers to help! SCNR :) But yes, what are you going to do? "Block all mails to big players Wednesday" to protest? I don't think that'll work. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Do we need Spam folders?
On 18.10.19 14:56, Michael Rathbun via mailop wrote: > My personal client has rules that send messaged from CBL-listed IPs to the > junk folder and marks them "read". Other than for research purposes, I've not > looked at one of those in well over a decade. If you don't look at them anyway, why don't you reject them at the gate at first sight? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Do we need Spam folders?
On 15.10.19 10:44, Paul Smith via mailop wrote: > Ditto. Yesterday, I got 400 emails. About 200 were spam that was > filtered, about 15 were spam that wasn't filtered, the rest I wanted at > one level or another. No way do I want 200 spam messages shoved into my > Inbox. So instead of rejecting these 200 mails directly and inform the sender that you didn't see them, you rather go through a list (doesn't matter if it's folder content or an email with details) daily and check them? And possibly miss an important one? And provide resources for them to be handled on your site? If you reject them, it's the sending MTAs problem (which might be abused and the postmaster learns about it this way). Even false positives would be handled by the sender who can either contact you in a different way or fix the reason for the false positive and resend the mail? Or you can just whitelist them if you are sure they are not bad guys? Here I thought, us IT guys are lazy and love to have someone else do the work? Why don't you in this case? ;-) Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Do we need Spam folders?
On 15.10.19 00:34, Chris Wedgwood via mailop wrote: >> Doesn't "550 Requested action not taken: We don't like you." apply >> after DATA? > > it does > > most severs honor this but not all > > (i experience this sometimes, my domain somtimes gets a lot of > backscatter) What MTAs do not honor this? How does 550 after DATA result in backscatter? Not returning a 250 OK after DATA is still well within limits of the SMTP dialog. How else are you supposed to reject a mail that could be saved because of its size or because it has a virus? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Do we need Spam folders?
On 14.10.19 23:59, Luis E. Muñoz via mailop wrote: > This is not a pure performance issue. It's more a matter of not having > the data at hand to decide whether the message is ham or spam. To do so, > filters need user feedback. You can still have feedback if you don't move emails to a spam folder and rely on a user checking that regularly. Recipients can still mark email as spam or explicitely allow mails from specific senders. And senders learn if there are problems with their delivery and can either fix that or ask the user to allow them. Either type of mail wouldn't just get lost in a spam folder that way. > Protocol-wise, what is a sender supposed to do with a post-DATA > rejection? Is that rejection associated to one of the RFC-5321 RCPT TOs? > All of them? None, because it's actually a content issue? What if the > policies for each recipient differ? He is supposed to handle it like any other rejection too? Doesn't "550 Requested action not taken: We don't like you." apply after DATA? > MTAs know how to deal with a post-RCPT rejection. A post-DATA is an > entirely different thing. MTAs should be able to handle rejections at all stages. Which doesn't? > There's also the option of sending a NDR after accepting the message, > which is undesirable for a plethora of other reasons. That's why I suggested to not accept an email like that at all. I am also not a fan of "unread mails can still be taken out of the users mailbox". I wouldn't want my postman to fish mail out of my letterbox just because he thinks my neighbour didn't like it, so I won't either. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Do we need Spam folders?
On 14.10.19 20:57, Michael Wise via mailop wrote: > Having the mail bounce at the edge is a VERY useful signal for any spammers > trying to enhance their deliverability. Not bouncing mails at edge is a very useful signal for any spammer too, because he delivered an email and is getting paid? Spammers also enhance their deliverability by all kinds of tracking nonsense you still allow them to use. > This question has different answers depending on if you're guarding 1 > mailbox, 10 - 100,000 or over a million. > The larger the number of mailboxes, the more we need to do filtering > post-DATA. Of course I don't have the experience in the last category, but I'd like to learn. Why can't you reject emails post-DATA? Is it a performance issue? Google or Bing find 935.000.000 search results in 0,60 seconds for the word "spam", but they can't do a spam check in that amount of time? You can still have users mark mails as spam and improve your filters. And you can still learn about false positives - just not by your user, but the sender of an email (or by the user after the sender contacted him in a different way). Or if the user explicitely allows a sender by adding them to their address book or whatever - as you do already. And yes, I am trolling a little or playing devils advocate in this matter. Reason being that I feel that we just rely on a mechanism that has a lot of issues and that might be done better if someone more intelligent and experienced than me did think about it instead of accepting this as given. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Do we need Spam folders?
On 14.10.19 20:39, Philip Paeps via mailop wrote: > While I'm clearly not a representative sample of the average email user, > 3 or 5 spam messages per day is two orders of magnitude short of the > mark on a bad day for me. > > So ... Yes: we need spam folders. But you still have to check these regularly? Why not reject those instead and have the sender deal with it? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Do we need Spam folders?
On 14.10.19 20:17, Jay Hennigan via mailop wrote: > A lot, in my case a good portion is "targeted" B2B spam, more than half > of which is sent via ESPs. If people can handle 3 or 5 spams per day, > can they handle 30 or 50? 300 or 500? How does it scale? Yes, but you still have to handle these by checking the spam folder? You might feel it's easier since it is "pre-sorted", but how often did you miss a FP in that pile of junk or because you didn't check it? If that mail is a huge contract for your company, do you want to even have the slightest chance of missing it? After all you don't want most of these in the first place. So why not block "maybe"s directly during delivery. That way it's the sender's problem and not yours. Since the sender will get informed that his email did not get delivered for whatever reason, he still has a chance to fix it - if he _really_ wants you to read that mail. > Ideally, the vast majority aren't false positives. They are spam. > Filtering algorithms sort into yes - no - maybe. It's the "maybe" group > that's sent to the spam folder for the user to decide. If the user finds > email incorrectly (based on that user's decision) routed there, a good > algorithm will keep track of that for that recipient and route future > similar mail to the inbox for that recipient. Most users are really bad in managing that. I get more or less daily reports that a user doesn't like that he has to be reminded to return a book or that his lecture X got moved. Because to them "Junk" means "stuff I do not want", not "bulk email I received unsolicited". > It may not have just vanished. It may have been delivered, but the > recipient isn't loading remote images or other spyware. Or the recipient > saw the sender's address and subject and deleted it unopened. Maybe it > was routed to spam by an obscure AI that got it right, and the user saw > it in the spam folder and ignored it. Maybe the first one made it to the > inbox and the user marked it as spam, training the AI to route similar > cruft to the same place. There's no tracking stuff in my emails. I send text only and I'd rather prefer to receive that too. Whoever thought HTML in emails might be a good idea needs to get a real good paddling. Either way as a regular sender I'd rather be informed that a user did not receive my email. If he trained whatever AI to do so, I'd still like to know. I can't do anything about him ignoring it, but I'd rather know if someone else decided to not show him in the first place. > Do you open every envelope that arrives in your postal mailbox, or do > you discard some of it unopened and unread as obviously junk mail? The > same thing happens with email. The post office doesn't give me the same > thing that my email client does. With email I get two mailboxes, one for > first class mail, another for "presorted standard". Rarely, the > electronic postman algorithm gets it wrong (in both directions), but at > least I can train it. I do have a "no advertising" sign on my postal mailbox and I sometimes return mails unopened by adding "return to sender" (and optionally a reason). I understand that in some countries it's way worse than over here, but I guess I'd have a stamp then - to have a least some fun while returning them. That way I if I mistook a "your fee has been raised" from my insurance company, they have to figure that out instead of telling me: It Just as I do with emails, I guess. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Do we need Spam folders?
Hello fellow email-enthusiasts, all this discussion about emails being marked as spam or not and why always makes me think about one thing: Do we even need Junk/Spam-Folders? I mean how much mail gets through the first "block directly" level on your site? Every now and then a wave comes through and results in a bad mail or two more, but can't people handle 3 or 5 spams in their inbox per day? Depending on your client you might even just mark or group them in the Inbox, so people can take a quick glance and delete them if they want to. Is it necessary to sort these and lots of false positives into an extra folder that people regularly have to look into anyway so they don't miss an important mail? And where you regularly have to remind them to do so? As a sender I am a little annoyed when someone blocks my mails during delivery, but at least I know about it and can look into it or contact the recipient in a different way. I feel that's a lot better than not knowing if an email just vanished (not calling names this time...), is being ignored or just not seen because some obscure AI thought the recipient might want to be saved from it and he doesn't even know about it? Even more interesting: In Germany, this can be seen as not delivering an email to the recipient which is against the law. The user might be using POP3 or is not subscribed to the IMAP folder and therefore does not see the SPAM folder at all. To him the email never existed in the first place - even worse if it gets deleted automatically after a few days. I am not a lawyer and wouldn't know how to translate the legal text into English, but basically the law states that as soon as you accept a letter to be transported, you have to forward it to the recipient. The only way to avoid that responsibility is to not accept the letter in the first place. Me using the word "letter" in this is a hint on what times the law is based on, but it counts for email nonetheless. This might be a dark grey area and I don't have the resources to fight something like this in court to have it clarified, but it is something us postmasters here have to consider. Perhaps you should too? Regards from Germany, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Hotmail: Moving Email to 'spam' folder generates ISP complaint?
Hey, On 16.08.19 09:47, Benoit Panizzon via mailop wrote: > So I wonder, does the simple act of moving of an email to the hotmail > spam folder generate a spam complaint to the ISP? And possibly impact > the sender IP reputation? Yes. Because people are stupid and do not understand the difference between Spam/Junk and Trash. I am getting these all the time for regular emails for two reasons: 1. People don't understand the difference between Junk and Trash (sometimes I think it's a language / translation issue) 2. People think of email they don't care about as Spam. That's the main reasons why I will not trust customers to train spam filters. > No need to confirm 'yes this is spam I want it reported to the sender > ISP' ? Nope. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Outlook/Hotmail reporting to us that a mail has been declared as SPAM by a recpient, but... ?
On 28.06.19 16:41, Brielle via mailop wrote: > The amount of people who treat the Spam button as a Delete button is > staggering. This is even more difficult with users who speak a different language and don't understand the difference between Trash and Junk... Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] What is the story with QQ.COM?
Hey Brian, On 01.06.19 12:17, Brian Kantor via mailop wrote: > For the past several months, one of the mailboxes on one of my > servers has been getting messages, mostly in Chinese character sets > that I can't decipher, short little messages from various senders > with FROM addresses like 123456...@qq.com. At least a thousand a > day, sometimes as many as 2500 or more in one 24-hour period. "Tencent QQ, also known as QQ, is an instant messaging software service developed by the Chinese tech giant Tencent." In China people prefer digits over letters. To a native English-speaker, remembering a long string of digits might seem harder than memorizing a word - but that’s if you understand the word. So for many Chinese, numbers are easier to remember than Latin characters... Sometimes these are also homophones - similar sounding. Like 1688.com is pronounced “yow-leeyoh-ba-ba" - alibaba.com. I'd guess someone is abusing the system - perhaps similar to all the Skype requests people get / got a while ago? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Is Digital Ocean a spammer safe haven?
On 09.05.19 23:42, Ronald F. Guilmette via mailop wrote: > At the following link, I provide a list of 862 currently live IP addresses, > all located on AS14061 (Digital Ocean) which I have meticulously verified > as all being in use by a single large-scale snowshoe spamming operation > which is controlled by the same individuals who also own and control the > recently-minted RIPE network AS209298 -- Online Marketing Sources Kft -- > ostensibly headquartered in Budapest, Hungary. > > https://pastebin.com/raw/VYx2Yee1 I have just manually checked the first 5 or so IP addresses and they are all listed on at least 10 blacklists. So most of us should be blocking them anyway? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] openspf.org down
On 02.05.19 11:48, lukn via mailop wrote: > Hello mailops > > openspf.org seems to have been down for quite some time now, "the > internet" (as in reddit, twitter and friends) are wondering why - but > nobody knows anything. > > does anyone have some (shareable) insight? speculations? Speculations: https://news.ycombinator.com/item?id=19391851 Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.
On 30.04.19 04:45, Noel Butler via mailop wrote: > On 30/04/2019 05:35, Andreas Klein via mailop wrote: >> so the SPF >> check will fail if the FROM of the original message is retained and an >> SPF record exists for that domain. >> > > ancient FUD > > I was a very, *very* early adopter of SPF, I always hear these claims, > but my mails always get through SPF tests (much to the annoyance of some > LOL), and I use hardfail -all. No FUD at all. You are just relying on some recipients not enforcing your -all. We have a lot of students forwarding their emails to external mailboxes (usually freemailers even though they have more options here). I can show you all kinds of examples where the forwarding is rejected in those cases because the new "sending IPs" are from our machines, not the ones listed in the From's SPF record. And no, I don't do SRS, because I don't want to do workarounds to support a protocol that was broken by design in the first place. It's your decision (-all) that you don't want these mails delivered to the recipients, so I don't really care. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.
On 28.04.19 13:20, Simon Lyall via mailop wrote: > On Sun, 28 Apr 2019, Simon Lyall via mailop wrote: >> Well since that email just triggered another round of bounces I've >> just updated mailop's mailman config to mung all email addresses >> (hopefully, this email is a test). > > Well the good news is that worked. The bad news is that gmail just > bounced the daily digest so all those list members are now suspended. > > Maybe a slack channel would be easier. Or disable IPv6 (I thought Google only filters these for IPv6 addresses)? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] The utility of spam folders
On 21.04.19 22:21, Michael Rathbun wrote: > That's your option, certainly. However, if you run a large "free" mail > system, > > o you discover that up to 80% of the mail you finally accept, filter and > deliver (store) goes to accounts that have been abandoned. You paid to > analyze, transport, and store poop that can't be used as fertilizer. As a "free" mail system provider, I'd disable those abandoned accounts and not rely on the email senders to track their recipients and stop sending mails. Is there anything wrong with telling the sender: "550 Mailbox abandoned for X months" instead of accepting truckloads of poop for them? This is a lot easier than forcing any kind of tracking on the senders, because you actually know if a mailbox is being looked into or not. And it would solve all the other issues you mention. Thomas -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] The utility of spam folders
On 21.04.19 21:15, Michael Rathbun wrote: > Check whether your "non-spam" email is sent only to accounts that have > subscribed, opened or clicked in the last 90 to 180 days. Utterly and > absolutely suppress EVERY record that fails that test. It is becoming more > and more difficult simply to get your stuff to acceptance at the border if you > ignore this stricture. And force people like me to resubscribe every 90 to 180 days, because I don't allow tracking nonsense in emails? This whole discussion is becoming more and more depressing somehow. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
