Re: [mailop] Spamhaus Public Mirror Error Return Code Update
On 2021-02-16 4:26 p.m., Vsevolod Stakhov via mailop wrote: On 16/02/2021 21:25, Michael Peddemors via mailop wrote: FYI, you might want to check your outbound spam filter ;) X-Spam: Yes One thing to note, and maybe should be something to actually take up with RFC's, but wonder if flags like this should some how become trace headers.. Eg, which system put that header into the header list.. Especially now that inbound, outbound, and in transit systems and MTA's, may actually be involved.. Or better yet, if a system flags a message as spam, should you allow it out the door? Looking at the headers, have to 'guess' that it was inserted by .. Received: from mail.highsecure.ru Yes, that's because of DBL listing of some of the urls quoted by myself in the reply. I have a mail system configured to mark both inbound and outbound flows mainly for testing purposes. Normally Rspamd removes this header for outbound traffic but it could be useful to keep X-Spam header for the mailing lists traffic (and that's the reason why this is configured so in my mail system, well, apart from my laziness to make it properly via Rspamd settings). Anyway, thank you for pointing that out! I would strongly support any standards around mail trace headers for spam, as they are very common and very different in the email flows. We use several regular expressions to use those headers (https://github.com/rspamd/rspamd/blob/master/rules/regexp/upstream_spam_filters.lua) but this list is very far from being complete. Apparently, any standard would reduce and simplify (likely) this processing, especially if there is a way to check if this header is genuine - e.g. ed25519 signatures are fairly cheap and they are deterministic, meaning that a single signature might be reused for the same input + keypair for both signing and verification so caching might make it even cheaper for popular values and domains. ___ Yeah, we have a pretty long list of 'upstream_spam_filters' as well, maybe it would be worth while to find a location to put a definitive list that everyone can contribute to.. but to reiterate, I don't have a solution, but whatever convention(s) that we come up with, it should be something that can 'show' which mail processing system added the header, and thus by making it a 'trace header' (adding it in order) might make sense. I don't think we have to check if it is genuine, I mean who would forge a 'This is spam' header, let's not make it too complex. But really this work on standards for 'flagging' a message in transit, should probably be taken up in the IETF, or at least M3AAWG could come up with some recommendations to get it start. But one form of 'flag' could be 'I consider this to be spam'. However, I should point out, because of the many different systems that flag a message as spam, some upstream spam filters are more trust worthy than others, eg not all messages flagged as spam, would we reject, some "we" (as in MTA operators) might just filter to the spam folder, or weight more heavily in scoring etc.. If that is beneficial, then maybe standardized on a single naming convention might not be best. And of course, there is the case where a header COULD be forged, eg a 'this is not spam' flag, but I think everyone would ignore that. And then the case where if everyone used the same flag, if I believed my spam filter was more accurate than others, I would have to strip that header, so I could make the decision on whether to add that. Which makes another case for having it a trace header, where each transiting MTA can make their own determination. (Currently of course, we have to strip message header flags incoming that normally only our own systems would insert at delivery time, before we do our own evaluation) -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus Public Mirror Error Return Code Update
On 16/02/2021 21:25, Michael Peddemors via mailop wrote: > FYI, you might want to check your outbound spam filter ;) > > X-Spam: Yes > > One thing to note, and maybe should be something to actually take up > with RFC's, but wonder if flags like this should some how become trace > headers.. > > Eg, which system put that header into the header list.. > > Especially now that inbound, outbound, and in transit systems and MTA's, > may actually be involved.. > > Or better yet, if a system flags a message as spam, should you allow it > out the door? > > Looking at the headers, have to 'guess' that it was inserted by .. > > Received: from mail.highsecure.ru Yes, that's because of DBL listing of some of the urls quoted by myself in the reply. I have a mail system configured to mark both inbound and outbound flows mainly for testing purposes. Normally Rspamd removes this header for outbound traffic but it could be useful to keep X-Spam header for the mailing lists traffic (and that's the reason why this is configured so in my mail system, well, apart from my laziness to make it properly via Rspamd settings). Anyway, thank you for pointing that out! I would strongly support any standards around mail trace headers for spam, as they are very common and very different in the email flows. We use several regular expressions to use those headers (https://github.com/rspamd/rspamd/blob/master/rules/regexp/upstream_spam_filters.lua) but this list is very far from being complete. Apparently, any standard would reduce and simplify (likely) this processing, especially if there is a way to check if this header is genuine - e.g. ed25519 signatures are fairly cheap and they are deterministic, meaning that a single signature might be reused for the same input + keypair for both signing and verification so caching might make it even cheaper for popular values and domains. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Current OSS anti-spam software best practice?
Proxmox Mail Gateway is very good > Le 17 févr. 2021 à 00:12, Tim Bray via mailop a écrit : > > On 16/12/2020 10:50, Thomas Walter via mailop wrote: >> we switched over to rspamd quite a while ago and will not look back. > > I switched on the back your suggestion. rspamd seems way better. > > And switching on the dmarc module sends away the scammers. > > -- > Tim Bray > Huddersfield, GB > t...@kooky.org > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Current OSS anti-spam software best practice?
On 16/12/2020 10:50, Thomas Walter via mailop wrote: we switched over to rspamd quite a while ago and will not look back. I switched on the back your suggestion. rspamd seems way better. And switching on the dmarc module sends away the scammers. -- Tim Bray Huddersfield, GB t...@kooky.org ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus Public Mirror Error Return Code Update
FYI, you might want to check your outbound spam filter ;) X-Spam: Yes One thing to note, and maybe should be something to actually take up with RFC's, but wonder if flags like this should some how become trace headers.. Eg, which system put that header into the header list.. Especially now that inbound, outbound, and in transit systems and MTA's, may actually be involved.. Or better yet, if a system flags a message as spam, should you allow it out the door? Looking at the headers, have to 'guess' that it was inserted by .. Received: from mail.highsecure.ru On 2021-02-16 12:38 p.m., Vsevolod Stakhov via mailop wrote: On 16/02/2021 17:31, Bill Cole via mailop wrote: On 16 Feb 2021, at 3:39, Alessandro Vesely via mailop wrote: On Mon 15/Feb/2021 22:07:20 +0100 John Levine via mailop wrote: In article <463b0950-7b4e-d81d-7abc-0cf5120f6...@tana.it> you write: https://www.spamhaus.org/news/article/807/using-our-public-mirrors-check-your-return-codes-now It would certainly have been less error-prone to return an appropriate rcode[*], such as FORMERR/ REFUSED, possibly followed by a more precise extended error code[†]. Except that REFUSED means something else, 5 Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data. and nobody looks at DNS error codes when interpreting DNSBLs. Just a line in the mail log. If the server is being taken care of, someone will notice repeated errors... Is it that requiring people to install a DNSBL-specific plugin earns Spamhaus something? If you see any of these codes, your setup is broken. What I see is something like this: Feb 16 09:30:44 north courieresmtpd: error,relay=193.188.30.85,port=50761,from=,to=: 550 Rejected - see http://www.spamhaus.org/query/bl?ip=193.188.30.85 I don't see the actual code. Implementation detail. That URL may in your case be synthesized locally, but in some MTAs the TXT record for a listed IP is logged. With modern Postfix using postscreen, the value of matching A records is logged. Also, this is not a new approach for Spamhaus. This is just new values with more specific semantics. The general approach has been around for long enough that some tools (e.g. SpamAssassin) have recognized 127.255.255.255 as a "BLOCKED" since 2019. Rspamd also recognises these codes. Plus Rspamd generally ignores unknown codes (or inserts a special zero-weight symbol for those) and performs regular RBL sanity checks according to RFC 5782 out of the box, automatically disabling broken RBLs or broken resolvers (e.g. capturing resolvers that tries to redirect you somewhere). So while I'm watching this thread closely I see nothing that might be improved in the current RBLs processing logic in Rspamd. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus Public Mirror Error Return Code Update
On 16/02/2021 17:31, Bill Cole via mailop wrote: > On 16 Feb 2021, at 3:39, Alessandro Vesely via mailop wrote: > >> On Mon 15/Feb/2021 22:07:20 +0100 John Levine via mailop wrote: >>> In article <463b0950-7b4e-d81d-7abc-0cf5120f6...@tana.it> you write: > https://www.spamhaus.org/news/article/807/using-our-public-mirrors-check-your-return-codes-now > >>> It would certainly have been less error-prone to return an appropriate rcode[*], such as FORMERR/ REFUSED, possibly followed by a more precise extended error code[†]. >>> >>> Except that REFUSED means something else, >> >> >> 5 Refused - The name server refuses to >> perform the specified operation for >> policy reasons. For example, a name >> server may not wish to provide the >> information to the particular requester, >> or a name server may not wish to perform >> a particular operation (e.g., zone >> transfer) for particular data. >> >> >>> and nobody looks at DNS error codes when interpreting DNSBLs. >> >> >> Just a line in the mail log. If the server is being taken care of, >> someone will notice repeated errors... >> >> Is it that requiring people to install a DNSBL-specific plugin earns Spamhaus something? >>> >>> If you see any of these codes, your setup is broken. >> >> >> What I see is something like this: >> >> Feb 16 09:30:44 north courieresmtpd: >> error,relay=193.188.30.85,port=50761,from=,to=: >> 550 Rejected - see http://www.spamhaus.org/query/bl?ip=193.188.30.85 >> >> I don't see the actual code. > > Implementation detail. That URL may in your case be synthesized locally, > but in some MTAs the TXT record for a listed IP is logged. With modern > Postfix using postscreen, the value of matching A records is logged. > > Also, this is not a new approach for Spamhaus. This is just new values > with more specific semantics. The general approach has been around for > long enough that some tools (e.g. SpamAssassin) have recognized > 127.255.255.255 as a "BLOCKED" since 2019. Rspamd also recognises these codes. Plus Rspamd generally ignores unknown codes (or inserts a special zero-weight symbol for those) and performs regular RBL sanity checks according to RFC 5782 out of the box, automatically disabling broken RBLs or broken resolvers (e.g. capturing resolvers that tries to redirect you somewhere). So while I'm watching this thread closely I see nothing that might be improved in the current RBLs processing logic in Rspamd. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus Public Mirror Error Return Code Update
On 16 Feb 2021, at 3:39, Alessandro Vesely via mailop wrote: On Mon 15/Feb/2021 22:07:20 +0100 John Levine via mailop wrote: In article <463b0950-7b4e-d81d-7abc-0cf5120f6...@tana.it> you write: https://www.spamhaus.org/news/article/807/using-our-public-mirrors-check-your-return-codes-now It would certainly have been less error-prone to return an appropriate rcode[*], such as FORMERR/ REFUSED, possibly followed by a more precise extended error code[†]. Except that REFUSED means something else, 5 Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data. and nobody looks at DNS error codes when interpreting DNSBLs. Just a line in the mail log. If the server is being taken care of, someone will notice repeated errors... Is it that requiring people to install a DNSBL-specific plugin earns Spamhaus something? If you see any of these codes, your setup is broken. What I see is something like this: Feb 16 09:30:44 north courieresmtpd: error,relay=193.188.30.85,port=50761,from=,to=: 550 Rejected - see http://www.spamhaus.org/query/bl?ip=193.188.30.85 I don't see the actual code. Implementation detail. That URL may in your case be synthesized locally, but in some MTAs the TXT record for a listed IP is logged. With modern Postfix using postscreen, the value of matching A records is logged. Also, this is not a new approach for Spamhaus. This is just new values with more specific semantics. The general approach has been around for long enough that some tools (e.g. SpamAssassin) have recognized 127.255.255.255 as a "BLOCKED" since 2019. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus Public Mirror Error Return Code Update
On Tue, 16 Feb 2021, Alessandro Vesely wrote: rcode[*], such as FORMERR/ REFUSED, possibly followed by a more precise extended error code[†]. Except that REFUSED means something else, When Spamhaus sends REFUSED, it means you're trying to query a server than only paying customers can use, but you didn't provide a customer password. Is it that requiring people to install a DNSBL-specific plugin earns Spamhaus something? If you see any of these codes, your setup is broken. What I see is something like this: Feb 16 09:30:44 north courieresmtpd: error,relay=193.188.30.85,port=50761,from=,to=: 550 Rejected - see http://www.spamhaus.org/query/bl?ip=193.188.30.85 I don't see the actual code. The hint will be that every single message appears to be blacklisted. Having been through this a few times with a tiny BL that I run, no matter what you return a lot of clueless people will keep hammering on you year after year. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] When RBLs go bad
Well I am using Hetrix and I am seeing the same exact thing as MXToolbox On Tue, Feb 16, 2021 at 9:19 AM Blake Hudson via mailop wrote: > > On 2/14/2021 10:00 AM, Chris via mailop wrote: > > On 2021-02-14 01:42, André Peters via mailop wrote: > > ... > > > > 2) Securi.net used mxtoolbox. It has problems of its own of > > synthesizing it's own queries, and jumping to conclusions and > > misleading you. For example, if you do a domain lookup, you can end > > up with assertions you're listed in IP-only DNSBLs which have nothing > > to do with you. > > > > I personally prefer to use this for straight and > > uncomplicated/non-misleading results: > > > >> http://multirbl.valli.org/lookup/192.124.249.6.html > > > > Which lists some 9 listings for the IP. Now of course most of the > > DNSBLs listing it are trivial, not used much, or largely ignored (like > > RFC Ignorant), there are at least two that do seem indicate that they > > HAVE seen email traffic from that specific IP. So something seems to > > be awry with their assertion it can't make outbound connections. > > > > - If I had a nickel for everyone who insisted that their IP can't send > > email, when I have spam sample in my hand proving otherwise, I'd have > > retired long ago, or at least be a few dozen cases of beer richer. > > > > Even tho it's Securi.net, I'd prefer to see them at least expending > > the effort to see if anything *is* emitting from that IP rather than > > just asserting it. It wouldn't the first time that network hardware > > got infected, or a network operator got outsmarted. > > This was my first thought. The article's author states that his server > doesn't accept [incoming] connections on port 25 and somehow interprets > this as though the server therefore could not possibly send [outbound] > mail on port 25. This is obviously false. A form on a website, a command > line script, a malicious binary, etc could all certainly send email > messages on a system that's not listening on port 25 (or has incoming > connections to port 25 blocked). While remote, there's also a > possibility of IP hijacking or spoofing - more likely when you're just > talking about port scanning logs, less likely when you're talking about > fully functional TCP connections. > > I'm surprised the author didn't try to do any self-verification (or > state as such) before writing an article defaming another party. > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Reflecting over weekend, large providers problems with volume of abuse complaints
You know.. yes, the 'Too Big to Block' (TBTB) providers say they can't effectively handle the abuse complaints, which of course I have a problem respecting given the amount of revenue they have, they simply don't want to allocate the funds.. and the few guys left to do the job, they have to endure all the criticism. But even worse, the guys who are on the RBL side of things (or at the TBTB delisting side), they have MUCH smaller revenues/budgets. STOP doing automated delisting requests.. If you want to have a good relationship with an RBL operator, you aren't going to have it if you fill their removal request queue, with obviously automated delisting requests. Today's call out is to 'fastweb.it' and 'hostwinds' I mean seriously, please at least LOOK at the IP you are requesting to be removed. And if you provide NO information in your request.. simple 'remove me' WILL be ignored. And if you don't respond to the RBL's email's when they respond to your request, you can expect further requests to be ignored. "hi please remove ip from list" "Removal rquest" Just because your automated MXToolbox or HetrixTools tells you your IP is listed, does not mean trigger an automated removal call. Serious folks, requesting removal of Dynamic IP Addresses is wasting your time.. and if a REAL email server needs to be removed, the RBL might have all your requests routed to dev null, and the legitimate request will fail. And if you don't respond to the abuse team member who TRIED to help you out, don't just second a second request with exactly the same method, if you haven't answered there question. Remember, they bothered to try to help you out, don't ignore them. And don't use a 'td.noc-blacklist@' or 'ip-reputation@' address, use a real person's email address, responsible for the removal request. (If you have to have a dedicated address for this, you probably have a real problem to deal with) At LEAST check the PTR record, does the IP have one? Is it sane? Or is it a throwaway domain? Does it have an accompanying URL? If you can't bother to do even rudimentary checks to see if the IP might be sending spam, why would you think the person you are asking for a delisting from will even bother with your request. Just passing on a Pet Peeve, I am sure that the guys from Google and o365 and any other TBTB abuse guys are also frustated with this problem. The abuse team's over here have been given the green light to start blocking requests from companies that automate removal requests, and I am sure that lots of the TBTB are doing the same.. -- Start of the Week Rant -- -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone from salesforce.com?
Hi Andre, I work for Salesforce -- but only on one of their multiple platforms. Feel free to send me an example header and I'll see if I can figure out who to route it to. Regards, Al Iverson On Tue, Feb 16, 2021 at 5:29 AM Andre van Eyssen via mailop wrote: > > > Mail from salesforce.com is getting scored up here for no DKIM in mail > despite DKIM in DNS. bounces, of course. > > -- > Andre van Eyssen. Phone: +61 417 211 788 > mail: an...@purplecow.org http://andre.purplecow.org > About & Contact: http://www.purplecow.org/andre.html > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson // Wombatmail // Chicago Deliverability: https://spamresource.com DNS Tools: https://xnnd.com ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXTERNAL] Microsoft Support Request Form Broken?
On 2/16/21 1:06 AM, Byron Lunz via mailop wrote: > Support form is still broken. > > [...] > > https://support.microsoft.com/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75 I managed to submit a support request last week, however the support form itself, and the response I got was quite broken. First, the form does not leave any room for me to describe the problem. I can provide a title, and 'copy and paste any error messages' Why my time zone matters is anyone's guess. Later, I received a reply from a scary-looking email address: winlv.edfs.ww.00.en.msf.rmd.ts.t01.spt.00...@css.one.microsoft.com telling me what IP addresses I specified, and that I not bother replying to the message: | Please do not reply to this message as it is from an unattended | mailbox. Any replies to this email will not be responded to or | forwarded. This service is used for outgoing emails only and cannot | respond to inquiries. About half an hour later, I received a real reply - from the same scary-looking address - telling me that a review of the IP(s) i submitted was completed, but that more information was needed as they were unable to identify anything on their side that would prevent mail from reaching Outlook.com customers. Then I was advised to: | please reply to this email with a detailed description | of the problem you are having, including specific error| messages, and an agent will contact you. Yes, that was from the same address where the previous message told me that it was sent from an unattended mailbox. Then the email goes on to tell me about JMRP and SNDS and provides links to where I can join. However, the link for JMRP brings me to MSN Explorer help. I decided to ignore the warning from the first message, and replied to this message with a lot of details, but am still waiting for an agent to contact me. Maybe the first email was correct after all. Daniel K. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] UCEPROTECT and Gmail (was Re: When RBLs go bad)
On 2021-02-16 3:45 a.m., Vittorio Bertola via mailop wrote: Il 14/02/2021 07:42 André Peters via mailop ha scritto: Hi, Have you guys already read this? https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html I have seen the discussion and found it fits. Will you remove UCL from your servers? I am wondering if Gmail is actually using UCEPROTECT in any way. I was just told by a Gmail user that my messages started to be delivered into the spam folder, and AFAIK the only thing that changed in the last few days is that my VPS provider (Contabo) is now listed in the UCEPROTECT level 2 list as well (not just on level 3 - apparently, they just did an upgrade to their attempts to force people into paying them money). On the other hand, my reputation in the postmaster tools panel is good, etc. - no other visible issues. We always forgot, that when one RBL sees something, other RBL's, and even private ones probably saw the same activity. Contabo has had a problem with snowshoe spammers getting IP space, and there was a noted rise in new activity last week. So even if you aren't using an RBL, you should pay attention when one notices activity, as others might be seeing the same and silently blocking you.. 161.97.129.2433 basic-detail.com 161.97.129.244 3 basic-detail.com 161.97.129.245 3 basic-detail.com 161.97.129.246 4 basic-detail.com 161.97.133.1823 gloabl-mail.com 161.97.133.183 4 gloabl-mail.com 161.97.133.184 3 gloabl-mail.com 161.97.133.185 3 gloabl-mail.com 161.97.169.66 3 basic-detail.com 161.97.169.71 3 gloabl-mail.com Spot check on unusual activity going on.. Be nice if they offered their customers SWIP or 'rwhois' so only those responsible get the reputation, instead of Contabo's whole networks.. -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] When RBLs go bad
On 2/14/2021 10:00 AM, Chris via mailop wrote: On 2021-02-14 01:42, André Peters via mailop wrote: ... 2) Securi.net used mxtoolbox. It has problems of its own of synthesizing it's own queries, and jumping to conclusions and misleading you. For example, if you do a domain lookup, you can end up with assertions you're listed in IP-only DNSBLs which have nothing to do with you. I personally prefer to use this for straight and uncomplicated/non-misleading results: http://multirbl.valli.org/lookup/192.124.249.6.html Which lists some 9 listings for the IP. Now of course most of the DNSBLs listing it are trivial, not used much, or largely ignored (like RFC Ignorant), there are at least two that do seem indicate that they HAVE seen email traffic from that specific IP. So something seems to be awry with their assertion it can't make outbound connections. - If I had a nickel for everyone who insisted that their IP can't send email, when I have spam sample in my hand proving otherwise, I'd have retired long ago, or at least be a few dozen cases of beer richer. Even tho it's Securi.net, I'd prefer to see them at least expending the effort to see if anything *is* emitting from that IP rather than just asserting it. It wouldn't the first time that network hardware got infected, or a network operator got outsmarted. This was my first thought. The article's author states that his server doesn't accept [incoming] connections on port 25 and somehow interprets this as though the server therefore could not possibly send [outbound] mail on port 25. This is obviously false. A form on a website, a command line script, a malicious binary, etc could all certainly send email messages on a system that's not listening on port 25 (or has incoming connections to port 25 blocked). While remote, there's also a possibility of IP hijacking or spoofing - more likely when you're just talking about port scanning logs, less likely when you're talking about fully functional TCP connections. I'm surprised the author didn't try to do any self-verification (or state as such) before writing an article defaming another party. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] UCEPROTECT and Gmail (was Re: When RBLs go bad)
On Tue, 16 Feb 2021, Vittorio Bertola via mailop wrote: Il 14/02/2021 07:42 André Peters via mailop ha scritto: Hi, Have you guys already read this? https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html I have seen the discussion and found it fits. Will you remove UCL from your servers? I am wondering if Gmail is actually using UCEPROTECT in any way. I was just told by a Gmail user that my messages started to be delivered into the spam folder, and AFAIK the only thing that changed in the last few days is that my VPS provider (Contabo) is now listed in the UCEPROTECT level 2 list as well (not just on level 3 - apparently, they just did an upgrade to their attempts to force people into paying them money). On the other hand, my reputation in the postmaster tools panel is good, etc. - no other visible issues. I also use Contabo, which is listed (Level 3) already for a couple of weeks, but I'm not listed either in Level 1 or 2. Level 2 seems to apply when a number of Level 1's within a given subset (in my case it shows a /20 subnet) reach a certain level. It (still) does not bother me, and I (still) have not noticed any consequences (and specifically not when sending to gmail, but my volume of e-mail is extremely small (family server)) of being part of the Level 3 entry. Cheers.___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] UCEPROTECT and Gmail (was Re: When RBLs go bad)
> Il 14/02/2021 07:42 André Peters via mailop ha > scritto: > > > Hi, > > Have you guys already read this? > https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html > > I have seen the discussion and found it fits. Will you remove UCL from > your servers? > I am wondering if Gmail is actually using UCEPROTECT in any way. I was just told by a Gmail user that my messages started to be delivered into the spam folder, and AFAIK the only thing that changed in the last few days is that my VPS provider (Contabo) is now listed in the UCEPROTECT level 2 list as well (not just on level 3 - apparently, they just did an upgrade to their attempts to force people into paying them money). On the other hand, my reputation in the postmaster tools panel is good, etc. - no other visible issues. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Anyone from salesforce.com?
Mail from salesforce.com is getting scored up here for no DKIM in mail despite DKIM in DNS. bounces, of course. -- Andre van Eyssen. Phone: +61 417 211 788 mail: an...@purplecow.org http://andre.purplecow.org About & Contact: http://www.purplecow.org/andre.html ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] test
please ignore this message ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM: ed22519 experiences anyone?
mailauth (https://github.com/andris9/mailauth) library and cli utility can also be used to both verify and sign using Ed25519 DKIM keys. Can't see those keys to become mainstream any time soon though. RSA signature already verifies the message so double signing is basically just for testing purposes but has no practical effect. Probably happens once 2048bit keys are considered too weak and 4096bit keys are just too long for DNS. Regards, Andris Reinman Kontakt Patrick Ben Koetter via mailop () kirjutas kuupäeval T, 16. veebruar 2021 kell 09:50: > Hey Vsevolod! > > * Vsevolod Stakhov via mailop : > > On 15/02/2021 21:02, John Levine via mailop wrote: > > > In article <20210215085929.76srgtpbaqbms...@sys4.de> you write: > > >> Greetings, > > >> > > >> is anyone using ed22519 for DKIM signatures yet and what do you see? > Any > > >> interop problems? > > > > > > Aside from the fact that approximately nobody can validate them yet, > they're fine. > > > > > > So long as you don't try to use the same selector you use with RSA > signatures > > > they shouldn't cause any problems. > > ACK! After some consideration we agreed not to use subdomains of > _domainkey.$DOMAIN.$TLD, but add the algo name as suffix to the selector. > > > > Well, Rspamd can validate them, but I'd suggest to use dual signatures > > for now (RSA + ed25519) when signing - it is also supported by Rspamd > > dkim_signing module, even for the keys rotation scenario. > > I agree! Another standard withou a mechanism to tell feature sets apart. > We'll > have to live with two signatures for an undefined period, until someone > steps > up and forces senders to implement the "replacing feature", because the old > one will fall away on the receiving end. > > p@rick > > -- > [*] sys4 AG > > https://sys4.de, +49 (89) 30 90 46 64 > Schleißheimer Straße 26/MG,80333 München > > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief > Aufsichtsratsvorsitzender: Florian Kirstein > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus Public Mirror Error Return Code Update
On Mon 15/Feb/2021 22:07:20 +0100 John Levine via mailop wrote: In article <463b0950-7b4e-d81d-7abc-0cf5120f6...@tana.it> you write: https://www.spamhaus.org/news/article/807/using-our-public-mirrors-check-your-return-codes-now It would certainly have been less error-prone to return an appropriate rcode[*], such as FORMERR/ REFUSED, possibly followed by a more precise extended error code[†]. Except that REFUSED means something else, 5 Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data. and nobody looks at DNS error codes when interpreting DNSBLs. Just a line in the mail log. If the server is being taken care of, someone will notice repeated errors... Is it that requiring people to install a DNSBL-specific plugin earns Spamhaus something? If you see any of these codes, your setup is broken. What I see is something like this: Feb 16 09:30:44 north courieresmtpd: error,relay=193.188.30.85,port=50761,from=,to=: 550 Rejected - see http://www.spamhaus.org/query/bl?ip=193.188.30.85 I don't see the actual code. Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM: ed22519 experiences anyone?
> On 15 Feb 2021, at 22:29, Vsevolod Stakhov via mailop > wrote: > On 15/02/2021 21:02, John Levine via mailop wrote: >> In article <20210215085929.76srgtpbaqbms...@sys4.de> you write: >>> Greetings, >>> >>> is anyone using ed22519 for DKIM signatures yet and what do you see? Any >>> interop problems? >> >> Aside from the fact that approximately nobody can validate them yet, they're >> fine. >> >> So long as you don't try to use the same selector you use with RSA signatures >> they shouldn't cause any problems. > > Well, Rspamd can validate them, but I'd suggest to use dual signatures > for now (RSA + ed25519) when signing - it is also supported by Rspamd > dkim_signing module, even for the keys rotation scenario. Halon MTA (libdkim++) does support them as well. For about two years we've been collecting DKIM validation statistics for inbound traffic to our own company domains (approx 30M messages in total). We've not seen any differences in failed signatures depending on algorithms used. rsa-sha256 88.63% rsa-sha1 11.31% rsa-sha1 + rsa-sha256 0.05% rsa-sha256 + ed25519-sha2560.01% ed25519-sha256 - rsa-sha1 + ed25519-sha256 - rsa-sha1 + rsa-sha256 + ed25519-sha256 - ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
