DKIM ... KAPUT
Yesterday I disabled DKIM as a spam indicator, because I got tired of adding exceptions. Non-compliant relays should fail hard, but they do not. This is a tragedy.
Re: Rule: "1.0 R_DCD 90% of .com. is spam"
Ahhh The ikea mail was received through ... mta-numbers.ikea.com.sparkpostmail.com and is a request for feedback. The SA rule says ... header R_DCD Received =~ /\.com\./ I still do not know where the rule comes from, DCD may actually mean dot-com-dot, and perhaps it is true that they are mostly spam. Original Message On May 10, 2024, 17:18, Rupert Gallagher wrote: > I only have stock and KAM, and it is definitely not a custom rule of mine. > > Original Message > On May 10, 2024, 17:11, Matus UHLAR - fantomas wrote: > >> On 10.05.24 15:08, Rupert Gallagher wrote: >My local evidence does not >> support the general claim that 90% of .com is spam. > >I just received a >> mail from informat...@info.email.ikea.com marked as spam, with positive >> R_DCD. The rule did not trigger on mail from other .com addresses. > >I do >> not know what R_DCD means, and search indexes do not help. Short of reading >> the source code, does anybody know what R_DCD means? I have no idea. where >> did you get this rule from? I don't see it in stock rules -- Matus UHLAR - >> fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to >> receive e-mail advertising to this address. Varovanie: na tuto adresu chcem >> NEDOSTAVAT akukolvek reklamnu postu. There's a long-standing bug relating to >> the x86 architecture that allows you to install Windows. -- Matthew D. Fuller
Re: Rule: "1.0 R_DCD 90% of .com. is spam"
I only have stock and KAM, and it is definitely not a custom rule of mine. Original Message On May 10, 2024, 17:11, Matus UHLAR - fantomas wrote: > On 10.05.24 15:08, Rupert Gallagher wrote: >My local evidence does not > support the general claim that 90% of .com is spam. > >I just received a mail > from informat...@info.email.ikea.com marked as spam, with positive R_DCD. The > rule did not trigger on mail from other .com addresses. > >I do not know what > R_DCD means, and search indexes do not help. Short of reading the source > code, does anybody know what R_DCD means? I have no idea. where did you get > this rule from? I don't see it in stock rules -- Matus UHLAR - fantomas, > uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive > e-mail advertising to this address. Varovanie: na tuto adresu chcem > NEDOSTAVAT akukolvek reklamnu postu. There's a long-standing bug relating to > the x86 architecture that allows you to install Windows. -- Matthew D. Fuller
Rule: "1.0 R_DCD 90% of .com. is spam"
My local evidence does not support the general claim that 90% of .com is spam. I just received a mail from informat...@info.email.ikea.com marked as spam, with positive R_DCD. The rule did not trigger on mail from other .com addresses. I do not know what R_DCD means, and search indexes do not help. Short of reading the source code, does anybody know what R_DCD means?
Broken rule: FORGED_HOTMAIL_RCVD2
When hotmail user sends from outbound.protection.outlook.com, the SA rule must not intervene.
Re: localhost lookups ?
I see this in live mail, sent by RFC clueless administrators, causing business mail to be either rejected or quarantined. On production systems, the good mail server should self-discipline and fail hard, compelling the system administrator to take action. Original Message On Feb 25, 2024, 01:12, J Doe wrote: > On 2024-02-24 00:26, Matija Nalis wrote: > On Fri, Feb 23, 2024 at 06:43:53PM > -0500, J Doe wrote: >> 23-Feb-2024 18:33:02.422 queries: info: > (localhost.ca): query: >> localhost.ca IN +E(0) (127.0.0.1) >> >> > 23-Feb-2024 18:33:02.422 queries: info: (localhost): query: localhost IN >> > +E(0) (127.0.0.1) > >> What's interesting is that this is happening on a > mail server that has >> a: .ca TLD. It _looks_ like SA is appending this TLD > to: localhost, >> queries for it and it fails and then it queries correctly > for: >> localhost, which succeeds. > > And what does "ping localhost" > (running with the same user as SA) say? > I'd guess it might have the same > behaviour, in which case it is not > SA-related... > >> I'd like this > spurious lookup for: localhost.ca to stop ... has anyone >> seen something > similar - either: localhost.ca or: localhost.tld for a >> mail server with > another TLD (ie: mail.com -> localhost.com) ? >> >> If others have seen this, > is it result of a configuration parameter ? > > I've seen it in the past with > misconfigured /etc/hosts (missing > localhost entry) so search (or domain) > from /etc/resolv.conf was > being used as it would be for any unqualied host > name... > > (it also might be a permission problem on those files, or > > chroot / SElinux / Apparmor, or /etc/nsswitch.conf etc) Hi Matija, Thank you > for your quick reply. You were absolutely right - this was an issue with my: > /etc/resolv.conf and _not_ SA. Everything looks like it's working correctly > and the: localhost.ca lookup is no longer happening. - J
Re: Yahoo's DMARC reports fail DMARC themselves
cyber spaking -> cyber spanking --- The Grammar Nazi in me Original Message On Feb 16, 2024, 12:12, Rupert Gallagher wrote: > You are seing it yourself. Their e-mails fail SPF allignment, SPF > authentication and DKIM authentication. As a consequence, they fail DMARC. > > I see a deluge of DMARC failures, mostly from forwarding accounts, mailing > lists, and the mass mailer musvc.com > > I do not have the resources to contact them for cyber > spaking/slap/disciplining. Their e-mails are going where they belong. If they > do not care about the quality of what they send out, why should I care about > their negligence?
Yahoo's DMARC reports fail DMARC themselves
You are seing it yourself. Their e-mails fail SPF allignment, SPF authentication and DKIM authentication. As a consequence, they fail DMARC. I see a deluge of DMARC failures, mostly from forwarding accounts, mailing lists, and the mass mailer musvc.com I do not have the resources to contact them for cyber spaking/slap/disciplining. Their e-mails are going where they belong. If they do not care about the quality of what they send out, why should I care about their negligence?
FORGED_HOTMAIL_RCVD2
Rule broken. Please update.
Well hidden link mismatch
We all need a rule for things like the following: coinbase.com= /VERIFY
Re: New rule wanted
Note: Both client and server are not Windows. The attached file type is a generic "data" on unix. On a Windows client the file runs as executable. A SA rule should merely detect that the file type is a generic "data" file. Original Message On Feb 7, 2023, 11:15, Rupert Gallagher wrote: > I received a spam with score -1. Well written, looks legit commercial, asking > for a quotation, with details in the attachment, a 3MB file with unknown > extension ".one". > > The file turns out to be a Windows Trojan: > > https://www.virustotal.com/gui/file/f4d587f60f2d34add9f77fcbd8c3c0df3ca51cfaecd9de85c45d25647eaac40b > > Both SA and ClamAV passed it as legit. > > We should have a SA rule that says: "attached file with unknown data type".
New rule wanted
I received a spam with score -1. Well written, looks legit commercial, asking for a quotation, with details in the attachment, a 3MB file with unknown extension ".one". The file turns out to be a Windows Trojan: https://www.virustotal.com/gui/file/f4d587f60f2d34add9f77fcbd8c3c0df3ca51cfaecd9de85c45d25647eaac40b Both SA and ClamAV passed it as legit. We should have a SA rule that says: "attached file with unknown data type".
Re: sharepoint phish routed through sharepointonline/outlook
Message-Id: Read RFC 822, pp. 44-46. If your answer is that the latest RFC allows for it, the my reply is: my mail, my rules, so I apply the most stringent rules. Original Message On 15 Jan 2023, 20:47, Alex wrote: > Hi, > > X-Spam-Status: No, score=1.102 tagged_above=-200 required=5 > tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, > DKIM_VALID_EF=-0.1, DMARC_PASS=-0.1, FMBLA_HELO_OUTMX=-0.01, > FMBLA_RDNS_OUTMX=-0.01, HTML_MESSAGE=0.001, LOC_CDIS_INLINE=0.1, > LOC_FILE_SHARE_PHISH1=0.75, LOC_FROMADDR=0.01, LOC_FROMNAME=0.01, > LOC_IMGSPAM=0.1, LOC_XORIGORG=0.01, MIME_HTML_ONLY=0.1, > RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, > RCVD_IN_SENDERSCORE_80_89=-0.4, RELAYCOUNTRY_LOW=0.1, RELAYCOUNTRY_US=0.01, > SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TXREP=-0.166] autolearn=disabled > > I'm reporting it to spamcop and training bayes, but does anyone have any > other ideas? > > Is this just someone using their sharepoint account to send a phish? Perhaps > account takeover? > > https://pastebin.com/2CJ3SLf2
Re: Unicode considered harmful again
Original Message On Nov 4, 2021, 09:34, Damian < spamassas...@arcsin.de> wrote: > >> Please convert all source code to ASCII. If it fails to compile, > then it may have a trojan hiding in Unicode clothing. > > >Instructions unclear. > > CVE 2021-42574 > It remains unclear (to me). What source code should spamassassin-users > convert? Attached source code in emails? How should they convert, is there a > SpamAssassin-Plugin? Should they install compilers on their mail system? The CVE is a call to action for the developers. On users, if SA can safely detect an attack, it should report it.
Re: Unicode considered harmful again
Original Message On Nov 4, 2021, 07:45, Damian < spamassas...@arcsin.de> wrote: >> Please convert all source code to ASCII. If it fails to compile, then it may >> have a trojan hiding in Unicode clothing. >Instructions unclear. CVE 2021-42574
Unicode considered harmful again
Please convert all source code to ASCII. If it fails to compile, then it may have a trojan hiding in Unicode clothing.
Re: Message-ID with IPv6 domain-literal
Original Message
On Sep 24, 2021, 18:30, Grant Taylor < gtay...@tnetconsulting.net> wrote:
On 9/24/21 10:17 AM, Rupert Gallagher wrote:
>> The RFC 5322 as cited is concerned about domains and their internet
>> address, where the sender's address needs to be resolvable through DNS
>> by the recipient.
>"where the sender's address" seems to be discussing the email address,
>which is completely independent from the Message-ID.
Nope.
The Message-ID is generated by the MUA, whose only reference is the sender's
address. Bad MUA's use the LAN hostname of the sending machine, and thus
generate non-RFC compliant headers. If the MUA does not include the Message-ID,
then the server intervenes by adding its own RFC-compliant header, explicitly
marked as added by server. Note that if the aim with the RFC's new nasty
grammar for this limited to the uniqueness of the ID without any reference to
the domain, then a random string [a-zA-z0-9]{N} would be enough if N is a big
enough integer. But no, the RFC's grammar is at pains with domains and domain
literals, so they are important and must have a semantics.
>"needs to be resolvable through DNS by the recipient" seems to be discussing
>the recipient's email system's ability to resolve something, which can include
>B2B partners across any intermediate network, be it a VPN or the public
>Internet. It also seems to mean that it doesn't matter if other DNS servers
>are able to resolve it or not.
All domains and domain literals in the headers are required to be resolvable.
B2B make no exception to the rule. On VPN, being private networks by
definition, they belong to the LAN-like network treatment: they are not public,
and thus private for anyone outside those private network, both by RFC and by
law (GDPR).
>> If the email infrastructure serves local messages in a company, then LAN
>> addresses get the job done. But delivering messages across autonomous
>> systems calls for *public* fully qualified domain names and their *public*
>> IP addresses, or the delivery will fail.
> Again, email addresses and IP addresses are independent of the content of the
> Message-ID.
I disagree.
> You may dislike the content of the Message-ID. That's fine. That's your
> prerogative to have. But your prerogative does not negate the fact that the
> email was successfully delivered using a Message-ID that you
question.
Those e-mails are systematically rejected by our servers.
> The simple fact that the message arrived at your MTA such that SpamAssassin
> could score based on the questionable Message-ID is evidence to the fact that
> the message was successfully delivered.
They arrive in a special mailbox for admin verification, like a spam log. The
end users do not see them at all.
RG
Re: Message-ID with IPv6 domain-literal
Anyway, this part of the original RFC 822 reads loud and clear on the matter. Each new RFC aiming to improve it seems the result of spamming lobbies aiming at hiding themselves. The latest grammar for MIDs is horrible. Original Message On Sep 24, 2021, 18:17, Rupert Gallagher < r...@protonmail.com> wrote: The RFC 5322 as cited is concerned about domains and their internet address, where the sender's address needs to be resolvable through DNS by the recipient. If the email infrastructure serves local messages in a company, then LAN addresses get the job done. But delivering messages across autonomous systems calls for *public* fully qualified domain names and their *public* IP addresses, or the delivery will fail. Original Message On Sep 23, 2021, 19:56, Grant Taylor < gtay...@tnetconsulting.net> wrote: On 9/23/21 2:38 AM, Rupert Gallagher wrote: > A LAN address is not the "Internet address of the particular host", and > therefore, by RFC 5322 line 969, the header in the OP is not RFC compliant. Sure it is. What you refer to as a "LAN address" is in fact an Internet (Protocol) address just like what you re referring to as an "Internet address". The only effective difference is the values assigned to them. Both of them function identically from a technological stand point. Particularly as viewed by the end systems. The only difference between them is an agreed upon convention of how / where the different address values are used. -- That is a human imposed requirement and definitely not a technical requirement. The closest that it comes to a technical requirement is that the Internet at large does not have routes for RFC 1918 IP addresses. This lack of routes has been chosen by humans for the aforementioned agreed upon convention. There is no /technical/ reason that RFC 1918 IP addresses can't be routed across the Internet. -- We have all experienced leaks of RFC 1918 addresses at some point. What's more is that RFC 5322 § 3.6.4 ¶ 5 states: The message identifier is intended to be machine readable and not necessarily meaningful to humans. Further, the entire message ID is what's to be globally unique. And using a domain or a globally routed IP address via domain-literal on the RHS is the RECOMMENDED way to achieve global uniqueness. But there are other ways. If we take meaning for humans out, we can have something like the "Message-ID: " That's the same domain-literal converted to an MD5 hash. It complies with obs-id-right -> domain -> obs-domain -> atom -> atext. "Message-ID: " So why does "43f011297907b952855484a6635191ff" work for the id-right when you say that "[IPv6:::193.168.1.30]" doesn't work for the id-right? They are both the same information, just different representations. If you don't like MD5 because it's lossy, how about Base64 "W0lQdjY6OmZmZmY6MTkzLjE2OC4xLjMwXQ==". You seem to be enforcing that the id-right be meaningful to humans, when RFC 5322 explicitly states that such is not necessary. If you do not super-impose human conventions on top of the Message-ID, then the Message-ID that Rupert asked about is perfectly valid. If you do super-impose human conventions on top of the Message-ID, then say that you are doing so. But know that you are going above and beyond the RFC. I believe in the same spirit that grey listing did years ago. Do so if you want to, but admit that you are doing so. -- Grant. . . . unix || die
Re: Message-ID with IPv6 domain-literal
The RFC 5322 as cited is concerned about domains and their internet address, where the sender's address needs to be resolvable through DNS by the recipient. If the email infrastructure serves local messages in a company, then LAN addresses get the job done. But delivering messages across autonomous systems calls for *public* fully qualified domain names and their *public* IP addresses, or the delivery will fail. Original Message On Sep 23, 2021, 19:56, Grant Taylor < gtay...@tnetconsulting.net> wrote: On 9/23/21 2:38 AM, Rupert Gallagher wrote: > A LAN address is not the "Internet address of the particular host", and > therefore, by RFC 5322 line 969, the header in the OP is not RFC compliant. Sure it is. What you refer to as a "LAN address" is in fact an Internet (Protocol) address just like what you re referring to as an "Internet address". The only effective difference is the values assigned to them. Both of them function identically from a technological stand point. Particularly as viewed by the end systems. The only difference between them is an agreed upon convention of how / where the different address values are used. -- That is a human imposed requirement and definitely not a technical requirement. The closest that it comes to a technical requirement is that the Internet at large does not have routes for RFC 1918 IP addresses. This lack of routes has been chosen by humans for the aforementioned agreed upon convention. There is no /technical/ reason that RFC 1918 IP addresses can't be routed across the Internet. -- We have all experienced leaks of RFC 1918 addresses at some point. What's more is that RFC 5322 § 3.6.4 ¶ 5 states: The message identifier is intended to be machine readable and not necessarily meaningful to humans. Further, the entire message ID is what's to be globally unique. And using a domain or a globally routed IP address via domain-literal on the RHS is the RECOMMENDED way to achieve global uniqueness. But there are other ways. If we take meaning for humans out, we can have something like the "Message-ID: " That's the same domain-literal converted to an MD5 hash. It complies with obs-id-right -> domain -> obs-domain -> atom -> atext. "Message-ID: " So why does "43f011297907b952855484a6635191ff" work for the id-right when you say that "[IPv6:::193.168.1.30]" doesn't work for the id-right? They are both the same information, just different representations. If you don't like MD5 because it's lossy, how about Base64 "W0lQdjY6OmZmZmY6MTkzLjE2OC4xLjMwXQ==". You seem to be enforcing that the id-right be meaningful to humans, when RFC 5322 explicitly states that such is not necessary. If you do not super-impose human conventions on top of the Message-ID, then the Message-ID that Rupert asked about is perfectly valid. If you do super-impose human conventions on top of the Message-ID, then say that you are doing so. But know that you are going above and beyond the RFC. I believe in the same spirit that grey listing did years ago. Do so if you want to, but admit that you are doing so. -- Grant. . . . unix || die
Re: Message-ID with IPv6 domain-literal
A LAN address is not the "Internet address of the particular host", and therefore, by RFC 5322 line 969, the header in the OP is not RFC compliant. Original Message On Sep 21, 2021, 20:54, Grant Taylor wrote: The use of a domain name or IP literal is RECOMMENDED, not even a SHOULD, much less MUST.
Re: Message-ID with IPv6 domain-literal
My mistake in quoting. The IP was 192.168.1.30, a LAN address.
Original Message
On Sep 21, 2021, 19:25, Dave Funk < dbf...@engineering.uiowa.edu> wrote:
On Tue, 21 Sep 2021, Bill Cole wrote:
> On 2021-09-21 at 12:25:30 UTC-0400 (Tue, 21 Sep 2021 10:25:30 -0600)
> Grant Taylor
> is rumored to have said:
>
>> But why the penalty for using non-public addresses* in a Message-ID: string?
>
> Empirical evidence. The use of a non-public address in a Message-ID
> correlates to a message being spam. In my experience, so does using an IP
> literal of any sort in a Message-ID, but that may be an idiosyncrasy in my
> mail.
>
>> I was not aware that Message-ID had any requirements that the content had to
>> mean anything beyond being syntactically correct. As such I would expect
>> private / non-globally routed content to be allowed. After all, isn't the
>> purpose of the Message-ID to be a universally unique identifier? If so, why
>> does it matter what the contents is as long as it's syntactically correct?
>> What am I missing?
>
> Private IP addresses in general cannot specify globally unique devices
> (consider 127.0.0.1 or the very-popular 192.168.1.1) and therefore a
> Message-ID using an IP literal as the RHS part with a non-public IP cannot
> assure uniqueness.
That is valid for Private IP addresses.
However "[IPv6:::193.168.1.30]" is the representation of IPv4: 193.168.1.30
which is a Public IP address, thus that 'hit' is in error.
This should be considered a parsing bug.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St.
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Message-ID with IPv6 domain-literal
An unknown MUA (user agent header removed by sender) writes its Message-IDs as . Is the header syntactically corrext? A custom SpamAssassin rule added a penalty for syntax error, and another for using a non-public address.
Re: Plugin to extract Links from PDF
A clickable picture should trigger a web client only if the pdf contains a script for this action, which you can detect using clamav. Original Message On Jun 4, 2021, 08:19, Benoît Panizzon < benoit.paniz...@imp.ch> wrote: Hi Gang In the last couple of weeks, I have seen a lot of spam mails containing just one single PDF, hardly any other text. That PDF again contains a clickable picture leading to some phishing site or similar. Of course the URL in the PDF is not being checked against URI Blacklists. Also creating a rule to match PDF attachment and little text would create way too many false positives, as sending 'PDF Emails' seems to be something quite common. So I wonder if someone already came up with a AS plugin to extract links from a PDF and check them against URI blacklists. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch __
Re: CHAOS v1.1.1
Original Message On Apr 7, 2021, 20:40, Jared Hall <> wrote: - Better Unibabble bibber-blabber blockage. This makes sense not.
Re: "Please send us a quote..."?
We get that from face-to-face leads from hell. Original Message On Apr 7, 2021, 03:27, Grant Taylor wrote: I've seen a few where they are asking for samples prior to -- purportedly -- submitting an order.
Re: CHAOS: Version 1.1.0
I love projects that are long in technical nonsense and short in motivation.
Original Message
On Mar 26, 2021, 21:40, Jared Hall < ja...@jaredsec.com> wrote:
A new version of CHAOS.pm is available: https://github.com/telecom2k3/CHAOS
The module can run in Tag mode, AutoISP mode, and Manual mode. As per RW et al,
there is greater utility in being able to score the rules. Just the ability to
name rules for differing Eval conditions is useful.
Uni-Babble rules now fully encompass the LATIN-1 Unicode character sets
(LATIN-1 and LATIN-1 SUPPLEMENT). This function should work in any North
American, South American, Australian, and Western European country. Uni-Babble
rules also should work in Israel and all Arabic countries, and in Greece. The
Orhodox Slav countries that are Cyrillic are also supported.
There is only partial support for LATIN-2 countries (defined by ISO 8859-2 and
ISO 8859-3). Currently, these countries (Czech, Slovakia, Slovenia, Hungary,
etc) should increment the UniBabble codeset count by 1, like from:
eval:from_lookalike_unicode(1) to eval:from_lookalike_unicode(2) and from
eval:subj_lookalike_unicode(1) to eval:subj_lookalike_unicode(2).
From the Changelog: https://github.com/telecom2k3/CHAOS/wiki/CHANGELOG
Version 1.1.0
Released March 26, 2021. "Postreleasem Depression"
New Features
Major release.
Added {chaos_mode}: Tag, Manual, AutoISP.
New Eval: check_to_public_name(), JR_CC_PUB_NONAME, many CC recipients without
a name.
New Eval: check_to_public_name(), JR_TO_PUB_NONAME, many TO recipients without
a name.
New Eval: eval:from_no_vowels(), JR_FROM_NO_VOWEL, From Name has words but no
vowels.
Changed Functions
Changed mailer_check() to include the PHP Script detection.
mailer_check() rules are immutable and will generate Callout scores unless in
Auto mode.
Remove Unbalanced Bracket rule. Callout rule from new check_for_brackets() has
total count.
Rule JR_HAS_MANY_BRACKETS in check_for_brackets() changed to JR_SUBJ_BRACKETS
in Auto mode.
Split Uni-Babble rules up into their individual parts.
Added ZIPX detection in Eval: id_attachments().
New X-Mailer callouts added to mailer_check()
New PHP Scripts added to mailter_check()
Uni-Babble Fixes
Complete integration of the LATIN and LATIN SUPPLEMENTAL codesets for Alphabet
detection.
Fix for incorrect scoring of LATIN SUPPLEMENT characters.
Latin Digits can appear in multiple alphabets, so they are now ignored when
matching Unicode codesets.
General Fixes
Fixes for excessive Auto Scoring.
Changing references from Self-Scoring to Auto-Scoring.
Corrected Description field operation throughout the module.
Documentation corrections.
Removed timezones from Framed Words/Messages rule.
New Admin Fraud messages added.
-- Jared Hall
Re: ViraLife
Note that gmail lets the first Received non public (it is the sender's machine). This is both a violation of the RFC and a tiny data breach. If you are ok with it, then whitelist the stinker. Original Message On Jan 28, 2021, 08:11, Rupert Gallagher < r...@protonmail.com> wrote: All Received must be public domains or literals by RFC. We reject such non compliant e-mails upfront, and I recommend you do the same. Original Message On Jan 27, 2021, 20:18, Loren Wilton < lwil...@earthlink.net> wrote: Has anyone been getting spams from "ViraLife"? They have slowly started, one by one, hitting all of my email inboxes. It shows up about once a week as a "newletter". It claims to be from a legit email hosting company I know nothing about, and I certainly have never signed up for this spam. Here are some headers for what I just got: Received: from ver-vp1.custonews.net ([192.250.230.87]) by oxsus1nmtai04p.internal.vadesecure.com with ngmta id 3cd7cc16-165e208a6ec4ede9; Wed, 27 Jan 2021 15:31:36 + Received: from localhost ([127.0.0.1]) by ver-vp1.custonews.net with SMTP; Wed, 27 Jan 2021 10:31:36 -0500 (EST) Date: Wed, 27 Jan 2021 10:31:36 -0500 (EST) Subject: Some articles from this week that might interest you.. From: "ViraLife" Message-ID:
Re: ViraLife
All Received must be public domains or literals by RFC. We reject such non compliant e-mails upfront, and I recommend you do the same. Original Message On Jan 27, 2021, 20:18, Loren Wilton < lwil...@earthlink.net> wrote: Has anyone been getting spams from "ViraLife"? They have slowly started, one by one, hitting all of my email inboxes. It shows up about once a week as a "newletter". It claims to be from a legit email hosting company I know nothing about, and I certainly have never signed up for this spam. Here are some headers for what I just got: Received: from ver-vp1.custonews.net ([192.250.230.87]) by oxsus1nmtai04p.internal.vadesecure.com with ngmta id 3cd7cc16-165e208a6ec4ede9; Wed, 27 Jan 2021 15:31:36 + Received: from localhost ([127.0.0.1]) by ver-vp1.custonews.net with SMTP; Wed, 27 Jan 2021 10:31:36 -0500 (EST) Date: Wed, 27 Jan 2021 10:31:36 -0500 (EST) Subject: Some articles from this week that might interest you.. From: "ViraLife" Message-ID:
Re: google and spam
I see a deluge of spam from google.com, catched at FROM, all containing an @NXDOMAIN. Google is tripping on its own shoe laces in this period. Original Message On Dec 14, 2020, 12:01, Iulian Stan wrote: > Hi all, > > First of all i am writing this email from yahoo because from my own domain it > seems it's not working because i have DMARC setup and apparently > something(maybe ezml) is messing up with the headers. If you have any ideea > to whom should i address i will more than happy :) > > I am also receiving a lot of spam from google (aparently always domain is > trix.bounces.google.com) and all spam is using google forms. > For me the problem is solved(meaning that all of these spam is going to > quarantine and bayes is learning about those) but i was wondering if: > > 1) Since email are coming from google how come google is not doing anything? > > 2) Are those spam sent manually ? It will be a nightmare for a spammer to do > this but how come there not any limitation coming from google if spam are > sent via mass-bulk programs/interfaces/etc? > > 3) I am using also a local(my own) RBL which is trained with IPs from spam. > It is queried by spammasssin because i don't want to reject from MTA but use > it in conjunction with others scores/rules. Now i have doubts that if i keep > adding IPs from google i will end up having all google MTAs added and legit > email might be hurt in the progress. What do you think ? Do you have insides > about this trix.bouces.google.com? Looking on RBL doesn't looks too great and > it seems from his domain there is spam which is actively sent. > > 4) I though that maybe google launch something similar with sendgrid but i > don't find any reference about it and also the envelope-from are different i > didn't found a common denominator. Few examples: > > envelope-from > <3lxrkxxqobqgumoiuqttqwva.rjfiarllqitwojzivl.zcwnnqkmoajmb...@trix.bounces.google.com> > envelope-from > <3qte3xwgjbdml8usyttw5bz7a.1dbz0jh35h03i...@trix.bounces.google.com> > envelope-from > <3sentxxqjbtgj8n8l4g4ha5i.54hechaag4cf.6igi99c68am58n...@trix.bounces.google.com> > envelope-from > <3pgtvxxmjbqkrwox0lkwkjwt.x0p.wppvjru.lxvjk31np1kn2...@trix.bounces.google.com> > envelope-from > <3qc7wxxijdt4rw.wfxmjjifgizqm99lrfnq.htrhtxrns.lfnyfslxgjy...@trix.bounces.google.com> > envelope-from > <3vt3kxwwjdvwqymqymqmrk55kqemp.gsqmsryx.tixvmwsvkwfix...@trix.bounces.google.com> > envelope-from > <3uxldxwsjd4gymp6m645uzjsymux.o0yo045qx.stq03stqs4nq5...@trix.bounces.google.com> > > Above also a full example of an email: > > https://pastebin.com/DW6dvdxP > > Thanks in advance, > Iulian
Re: Zero-point garbage text that isn't caught by the small-font rules
Original Message On Aug 20, 2020, 18:13, Loren Wilton < lwil...@earthlink.net> wrote: I've started receiving a bunch of spam or more likely phish mails that contain the following sort of trash in large quantities between almost every word of the visible text. The invisible font rules don't seem to catch this. lzdtec Loren I am beginning to love spammers. They seem to avenge loopholes and buttheaded decisions, like allowing for html in e-mails. I add a +1 score to each html email, and a +1 score to those whose font is smaller than 10pt. If it does not parse, then it goes straight into the bin.
Re: Blacklisting a stubborn sender
The domains turn out to be already in the rfc-clueless.org database since 2014. Original Message On 1 Aug 2020, 14:58, Rupert Gallagher < r...@protonmail.com> wrote: Two well known companies in my country persist in making the mistake of writing their mid with a non-public fqdn, violating the rfc. It has been so for the past three years, with me sending detailed, manually written error messages to their painstakingly collected admin addresses. Their answer is that everybody else accepts their invalid mid, and their servers are enterprise ibm / microsoft shitware that they are unwilling to fix. Since we get a lot of their emails, I decided to scale up their problem. There are many blacklists, and I have no intention to go through each idiosyncratic procedure. Is there an ombusdman that superintends the major blacklists and enforces rfc compliance through them?
Re: Blacklisting a stubborn sender
Original Message On 2 Aug 2020, 17:02, Bill Cole < sausers-20150...@billmail.scconsult.com> wrote: > if you want to authenticate email, ... The helo is a necessary, but not sufficient criteria for authentication. I use them all, up to dane. However, they all fail with those two senders, because they do not implement them, and they send mail from an IP whose rDNS is that of the ISP. Authenticating the source in this case reduces to cheching the sending IP against those from known valid e-mails, as well all rfc compliance as evidence of some degree of home work from their side. I am talking about a bank and an accountancy firm, and I resent having to do this.
Re: Blacklisting a stubborn sender
Original Message On 2 Aug 2020, 17:02, Bill Cole < sausers-20150...@billmail.scconsult.com> wrote: > smtpd_helo_restrictions Good idea. Thank you.
Re: Blacklisting a stubborn sender
To ignore it, as you say, I would have to remove the postfix check, write rules to implement a non-blocking check, then write rules to implement the rejection except for whitelisted domains. It is a lot of work, to allow a bank and an accounting firm to violate an industry standard, and still have the doubt on the authenticity of their e-mails. No thank you. Original Message On 2 Aug 2020, 15:54, Kevin A. McGrail < kmcgr...@apache.org> wrote: On 8/2/2020 9:18 AM, Rupert Gallagher wrote: > They will procrastinate until the end of time unless we do something. > I tried hard, but they are lazy/ignorant/careless. Blacklisting would > trigger a problem with most of their customers, then they will try to > de-list at first, then they will comply when de-listing is rejected. If they aren't spending spam, why care about their MID or Helo format unless there is a delivery issue. This project exists to stop spam not to weaponize our capabilities to become the RFC-police. If the users have consent to receive the mail and the mail is getting to the right person, I'd recommend you ignore it. Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Blacklisting a stubborn sender
They will procrastinate until the end of time unless we do something. I tried hard, but they are lazy/ignorant/careless. Blacklisting would trigger a problem with most of their customers, then they will try to de-list at first, then they will comply when de-listing is rejected. Original Message On 2 Aug 2020, 12:30, Matus UHLAR - fantomas < uh...@fantomas.sk> wrote: On 02.08.20 05:11, Rupert Gallagher wrote: >Correction: it is not the mid, it is the helo. oh... this is something quite different. But unless multiple servers start implementing reject_unknown_helo_hostname, such companies ignore to change that... ... apparently with possibly reject_non_fqdn_elo_hostname and reject_invalid_helo_hostname. and smtpd_helo_required=yes of course > Original Message >On 1 Aug 2020, 14:58, Rupert Gallagher < r...@protonmail.com> wrote: >Two well known companies in my country persist in making the mistake of >writing their mid with a non-public fqdn, violating the rfc. It has been so >for the past three years, with me sending detailed, manually written error >messages to their painstakingly collected admin addresses. Their answer is >that everybody else accepts their invalid mid, and their servers are >enterprise ibm / microsoft shitware that they are unwilling to fix. Since we >get a lot of their emails, I decided to scale up their problem. There are many >blacklists, and I have no intention to go through each idiosyncratic procedure. > >Is there an ombusdman that superintends the major blacklists and enforces rfc >compliance through them? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
Re: Blacklisting a stubborn sender
Correction: it is not the mid, it is the helo. Original Message On 1 Aug 2020, 14:58, Rupert Gallagher < r...@protonmail.com> wrote: Two well known companies in my country persist in making the mistake of writing their mid with a non-public fqdn, violating the rfc. It has been so for the past three years, with me sending detailed, manually written error messages to their painstakingly collected admin addresses. Their answer is that everybody else accepts their invalid mid, and their servers are enterprise ibm / microsoft shitware that they are unwilling to fix. Since we get a lot of their emails, I decided to scale up their problem. There are many blacklists, and I have no intention to go through each idiosyncratic procedure. Is there an ombusdman that superintends the major blacklists and enforces rfc compliance through them?
Re: Blacklisting a stubborn sender
They have explicit consent to send rfc compliant e-mail. Rfc-clueless.org seems.a good starting point. Thank you Original Message On 1 Aug 2020, 15:53, Kevin A. McGrail < kmcgr...@apache.org> wrote: On Sat, Aug 1, 2020 at 8:59 AM Rupert Gallagher wrote: Two well known companies in my country persist in making the mistake of writing their mid with a non-public fqdn, violating the rfc. It has been so for the past three years, with me sending detailed, manually written error messages to their painstakingly collected admin addresses. Their answer is that everybody else accepts their invalid mid, and their servers are enterprise ibm / microsoft shitware that they are unwilling to fix. Since we get a lot of their emails, I decided to scale up their problem. There are many blacklists, and I have no intention to go through each idiosyncratic procedure. Is there an ombusdman that superintends the major blacklists and enforces rfc compliance through them? First, I use Chris Santerre's definition of Spam that spam is about not having consent rather than the content. If someone sends something with RFC issues to evade spam detection, that demonstrates a lack of consent and clear intent. But if it's something with consent, as long as the email can get from point A to point B, bending the RFCs is fine. I'd equate it to a kid addressing an envelope to his Granny in crayon, forgetting the zip code and put the stamp on the wrong corner. The post office can figure it out automatically and it gets where it's meant to go. By comparison, the big bad Wolf trying to contact Granny from his jail cell would be spam. The RFC compliance might be an indicator for me but not a reason to block but that's my take. If you want to share a sample on pastebin, I can give you my take on it using the content vs consent litmus test for rules/blocking. Second, I'm not aware of any ombudsman for RBLs. Many RBLs are run by distinct organizations and many have unique listing/delisting criteria. An ombudsman would basically be a consultant spending a lot of time on the issue so you might just go that route and hire someone. Finally, there are RBLs you might want to use. There used to be RFC Ignorant but it appears to be shuttered. Take a look at http://rfc-clueless.org/ Also if they use the same domain, just locally block it. Regards, KAM
Blacklisting a stubborn sender
Two well known companies in my country persist in making the mistake of writing their mid with a non-public fqdn, violating the rfc. It has been so for the past three years, with me sending detailed, manually written error messages to their painstakingly collected admin addresses. Their answer is that everybody else accepts their invalid mid, and their servers are enterprise ibm / microsoft shitware that they are unwilling to fix. Since we get a lot of their emails, I decided to scale up their problem. There are many blacklists, and I have no intention to go through each idiosyncratic procedure. Is there an ombusdman that superintends the major blacklists and enforces rfc compliance through them?
Re: Thanks to Guardian Digital & LinuxSecurity for the nice post about SpamAssassin's upcoming change
Your LinkedIn post thanks the Guardian while hitting on us by hiding our lack of consent. Original Message On 16 Jul 2020, 01:24, Kevin A. McGrail < kmcgr...@apache.org> wrote: All: We're getting some positive attention from the verbiage change. See https://www.linkedin.com/posts/kmcgrail_apache-spamassassin-leads-a-growing-list-activity-6689260331719520256-gMy7 for a link to a Guardian Digital post about it. Anyway, I hope those not excited by the change will come around. We are working hard to make it as painless as possible and we have gotten word that several tools and projects that integrate with SpamAssassin will follow suit. Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
> racially-charged nature of blacklist There is no such thing. Black list originates from black book, that is a book with white pages and black cover, with black ink, where sins are listed in haven for you to be judged upon. On the colour of the cover, it is black because that's how old leather turns out to be. On the colour of ink, try writing white ink on black paper if you can... Stop using SA to push your political agenda. When v4 comes out, do not dare writing that *we* decided to *change* blacklist into blocklist because of the "racially-charged nature" of it, because it is not, because we said so, and because you are forcing it. Have the courage to put your own name under your own decision, do not blame us for it. Original Message On 14 Jul 2020, 16:48, Kevin A. McGrail < kmcgr...@apache.org> wrote: Your association is just antiquated. I can't remember exactly when but blocklist has been getting used to replace the racially-charged nature of blacklist. Here's a public example from 2012: https://cwiki.apache.org/confluence/display/SPAMASSASSIN/DnsBlocklistsInclusionPolicy This verbiage change isn't new and the impetus wasn't political nor American-driven. It's just the right time to do it AND we have 4.0's release giving us the perfect opportunity. Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Tue, Jul 14, 2020 at 10:28 AM Marc Roos wrote: > Yeah, allow/deny is more logical but using them requires all acronyms to change. > After some trial and error, we dialed in the changes to welcome and block which > also keeps other terminology like RBL, DNSBL, WLBL, etc. consistent > so there is less upheaval. I associate BL with blacklist. If that is how the general perception is, and most of what is written on the internet is relating to, I don't see how you can maintain those acronyms. Allow/deny is also commonly used in linux so one could argue, it is adapting to standards.
Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
Whatever you do under the hood, make sure it does not affect external behaviour. On your motivation, bear in mind that *lists here contain computer addresses, not people, so the reference you are trying to fix is mistaken, and changes will be painstaking for no reason at all. And the terms master and slave have nothing to do with white and black, and again they refer to machine processes, not people. Original Message On 10 Jul 2020, 06:00, Kevin A. McGrail < kmcgr...@apache.org> wrote: IMPORTANT NOTICE If you are running trunk, we are working on changing terms like whitelist to welcomelist and blacklist to blocklist. https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826 The first test of this work is done with allowlist_to replacing whitelist_to Committed revision 1879456. If you are using trunk, there may be disruption since routines, plugins and rule changes will all interweave. IF YOU ARE RUNNING TRUNK: I recommend you subscribe to the d...@spamassassin.apache.org mailing list to stay abreast of the changes. Please let me know if you have any questions! Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Question on early detection for relay spam
Fails with travelling clients. Original Message On Mar 3, 2020, 16:49, Benny Pedersen wrote: > Marc Roos skrev den 2020-03-03 16:15: >> Use ipset, hardly causing any latency using 50k entries. > > i dont need to block 50k entries, but only whitelist few accepted client > ips, where i resolve asn and open this specifik asn to have access, if > there is abuse it will be removed so its again is blocked, i have tryed > blockin 50k entries it failed maserable, for me it does not matter of > ipsets or not was used > > keeping it tieght helps alot > > the log i showed was not from clients that already had access, so no > need to block it > > if you know iptabels you dont need ipsets :=)
Re: GeoIP2 packages
The real problem is their database. For the purposes of SA, the whois database is good enough. On Mon, May 6, 2019 at 17:20, Alex wrote: > Hi all, > > I'm looking for the GeoIP2 and IP Country packages for fedora/CentOS > needed for the RelayCountry plugin. I believe there were some license > changes recently that prevent them from being included with the latest > distributions? > > I believe they also have a ton of dependencies based on the last time > I tried to build them on my own, including a bunch of maxmind modules. > > Of course I could build them from CPAN, but would obviously prefer the > ease of a package manager. The best approach for getting this all > working would be greatly appreciated.
HTML/URI defuser
Let's talk about those works of art that elude our best filters. Written and posted like a legit message, their only threat is a big red button with a label that says "do not push me". In truth, they are just a "click here for your overdue bill" and similar hooks for the gullible few. There are two things I would like to do asap: automatically rewrite any html e-mail into plain text, and automatically rewrite any URI into something that does not trigger any external program (browser, ftp, you name it). This is the only loophole left in my systems, and see non alternative.
Re: Filtering at border routers: Is it possible?
I reject tons of spam from OVH. So much that I am banning whole CIDRs. Whatever they do, it's not working. On Sat, Mar 23, 2019 at 12:53, Giovanni Bechis wrote > Hi, > this is what OVH does (article in french, sorry): > https://www.numerama.com/magazine/26297-ovh-copie-et-analyse-tous-les-e-mails-sortant-de-ses-serveurs.html > Giovanni
Re: Filtering at border routers: Is it possible?
I agree with Benny on port 25. I disagree with Kevin on port 587, because it is vulnerable to mitm attacks. I was royally pissed when they introduced port 587 and deprecated port 465. Port 587 is an RFC mandated security loophole. Port 465 is golden. On Sat, Mar 23, 2019 at 03:01, Kevin A. McGrail wrote: > On 3/22/2019 9:44 PM, Noel Butler wrote: > >> On 23/03/2019 05:54, Benny Pedersen wrote: >> >>> dont relay mail from port 25, mails there is final recipient only, not >>> forwared >> >> you ave not been taking your medication again Benny > > Noel, please. The personal attacks aren't in keeping with our code of > conduct. Please don't email them to the list. > > IMO and I believe the RFCs back me up, Port 25 should only be used for local > recipients. Port 587, submissions would be appropriate for submissions > requiring other delivery methods and should be protected with SMTP AUTH, for > example. That would certainly be best practice, well supported and easy to > add TLS to address. > > Getting back to the original question: Yes, you can scan outbound mail for > spam and block it. There are a number of ways to do that. We also do a LOT > with MIMEDefang, LDAP & IPTables, & Access files to extend the edge of the > network to the board to avoid backscatter, DDoS attacks, etc. I've published > a lot of stuff about this before and happy to give pointers again. > > But in short, setup an SMTP host that allows rely by IP from all your servers > behind it and set those servers to use the SMTP host as a smarthost. On the > smarthost, you can use amavisd-new and drop/redir mail that is considered > spam. More complex solutions are available with alerting, rate limiting, etc. > > Regards, > > KAM > > -- > Kevin A. McGrail > Member, Apache Software Foundation > Chair Emeritus Apache SpamAssassin Project > https://www.linkedin.com/in/kmcgrail > - 703.798.0171
Re: RE: Filtering at border routers: Is it possible?
I think you are in for a lot of pain. This is the view from my seat. If my company has a client that sends spam using my IP, then my IP earns a bad reputation and is blacklisted. Therefore, my other clients are blacklisted too, even if they do not send spam. If I do not solve the problem, then I will loose all of my clients and go bankrupt, eventually. As a businessman with complaining clients, I must hire a *professional* consultant who gets under my skin and finally tells me what my problem *is* and how to solve it. None of us in this list can bear responsibility for your decisions. Out of curiosity, did you look up for potential consultants? How much did they ask for wearing your problem? On Fri, Mar 22, 2019 at 21:31, wrote: > Thank you all for your suggestions. > I will follow the path of using a whitelist and block everyone. > I can track the IPs, but i taught i could put in place something (like OVH by > example) do (If their system detects spam being sent, the port on that ip is > automatically blocked and the client alerted). > > Cheers > > Bruno Carvalho (CEO xervers) | +41 79 884 00 44 > Please consider the environment before printing this email > > -Mensagem original- > De: Benny Pedersen > Enviada: sexta-feira, 22 de março de 2019 20:55 > Para: users@spamassassin.apache.org > Assunto: Re: Filtering at border routers: Is it possible? > > Anthony Hoppe skrev den 2019-03-22 18:23: >> Not knowing the details of your environment... >> >> Instead of taking on the job of filtering email for all of your >> clients (this, to me, will open up a can of worms), why not set a >> policy that port 25 is blocked by default and customers must request >> for it to be unblocked? > > dont relay mail from port 25, mails there is final recipient only, not > forwared > >> You can then build a list of who may be using your services to send >> mail and better track if/when undesirable mail is sent from your >> network? > > ask custommers to use port 587 or 465 as common pratice > > but do require sasl auth on this ports, reject all else > > sadly i see mtas try to use 587, and 465, i like to know with book thay read
Re: Semioff-topic: DoS mitigation technique mentioned in SA-list
Tarpitting? On Mon, Mar 11, 2019 at 10:03, Pedro David Marco wrote: > Hi all, > > Not a long time ago someone in the list mentioned an interesting antiDos > mitigation technique consisting in "playing" with attackers TCP windows > sizes... (as far as i remember)... but i cannot find the post with the name > of the tehcnique :-( > > Please, if someone remembers the name of the technique, tell me off-list.. > > Thanks a lot in advance... > > --- > PedroD.
Re: Spam rule for HTTP/HTTPS request to sender's root domain
On Fri, Mar 1, 2019 at 23:14, Mike Marynowski wrote: >> Does SpamAssassin even have facilities to do that? > Yes, if spf runs at priority 1, you can define your test at priority 2, so SA > executes them in the given order. >> Don't all rules run all the time? > They run when relevant, in the given order, and they do whay they say, so if > you say that webtest stops if spf test succeeds, then SA does it. >> SpamAssassin still needs to run all the rules because MTAs might have >> different spam mark / spam delete /etc thresholds than the one set in SA. > >> The number of cycles you're talking about is the same as an RBL lookup so I >> really don't see it as being significant. The DNS service does all the heavy >> lifting and I'm planning to make it public. > > It is significant of you have many emails to process. It is even more > significant if you run the test locally. > > On 3/1/2019 5:09 PM, Rupert Gallagher wrote: > >> Case study: >> >> example.com bans any e-mail sent from its third levels up, and does it by >> spf. >> >> spf-banned.example.com sent mail, and my SA at server.com adds a big fat >> penalty, high enough to bounch it. >> >> Suppose I do not bounch it, and use your filter to check for its websites. >> It turns out that both example.com and spf-banned.example.com have a >> website. Was it worth it to spend cycles on it? I guess not. The spf is an >> accepted rfc and it should have priority. So, I recommend the website test >> to first read the result of the SPF test, quit when positive, continue >> otherwise. >> >> --- ruga > > On 3/1/2019 5:09 PM, Rupert Gallagher wrote: > >> Case study: >> >> example.com bans any e-mail sent from its third levels up, and does it by >> spf. >> >> spf-banned.example.com sent mail, and my SA at server.com adds a big fat >> penalty, high enough to bounch it. >> >> Suppose I do not bounch it, and use your filter to check for its websites. >> It turns out that both example.com and spf-banned.example.com have a >> website. Was it worth it to spend cycles on it? I guess not. The spf is an >> accepted rfc and it should have priority. So, I recommend the website test >> to first read the result of the SPF test, quit when positive, continue >> otherwise. >> >> --- ruga >> >> On Fri, Mar 1, 2019 at 22:31, Grant Taylor >> wrote: >> >>> On 02/28/2019 09:39 PM, Mike Marynowski wrote: >>>> I modified it so it checks the root domain and all subdomains up to the >>>> email domain. >>> >>> :-) >>> >>>> As for your question - if afraid.org has a website then you are correct, >>>> all subdomains of afraid.org will not flag this rule, but if lots of >>>> afraid.org subdomains are sending spam then I imagine other spam >>>> detection methods will have a good chance of catching it. >>> >>> ACK >>> >>> afraid.org is much like DynDNS in that one entity (afaid.org themselves >>> or DynDNS) provide DNS services for other entities. >>> >>> I don't see a good way to differentiate between the sets of entities. >>> >>>> I'm not sure what you mean by "working up the tree" - if afraid.org has >>>> a website and I work my way up the tree then either way eventually I'll >>>> hit afraid.org and get a valid website, no? >>> >>> True. >>> >>> I wonder if there is any value in detecting zone boundaries via not >>> going any higher up the tree past the zone that's containing the email >>> domain(s). >>> >>> Perhaps something like that would enable differentiation between Afraid >>> & DynDNS and the entities that they are hosting DNS services for. >>> (Assuming that there are separate zones. >>> >>>> My current implementation fires off concurrent HTTP requests to the root >>>> domain and all subdomains up to the email domain and waits for a valid >>>> answer from any of them. >>> >>> ACK >>> >>> s/up to/down to/ >>> >>> I don't grok the value of doing this as well as you do. But I think >>> your use case is enough different than mine such that I can't make an >>> objective value estimate. >>> >>> That being said, I do find the idea technically interesting, even if I >>> think I'll not utilize it. >>> >>> -- >>> Grant. . . . >>> unix || die
Re: Spam rule for HTTP/HTTPS request to sender's root domain
The focus was on the To header for mailing lists, complaints on MUAs and people's choices. If you do not want to appear in the To header of a list, you are exercising a legal right under the GDPR. So, to cut through all those problems and enforce a sound solution, I suggest list majordomos do the compliance heavy lifting by forcing a sane To header. That's all. If you want to talk more in general about GDPR, I do it everyday, so leave me alone on weekends, will you? :-) On Fri, Mar 1, 2019 at 22:41, Grant Taylor wrote: > On 03/01/2019 01:25 AM, Rupert Gallagher wrote: >> A future-proof list that complies with GDPR would automatically rewrite >> the To header, leaving the list address only. > > Doesn't GDPR also include things like signatures? Thus if the mailing > list is only modifying the email metadata and not the message body (thus > signature), then it's still subject to GDPR. > > I also feel like it is a disservice to the mailing list to hide who the > message is from. But I have no idea of the legalities of (not) doing such. > >> Any other recipient will still receive it from the original sender. > > I presume you're talking about (B)CC and additional To recipients. > > I never did hear, how does GDPR play out in such a scenario. Does the > sender need to make a request to all To / (B)CC recipients for them to > forget the sender? Also, does the mailing list operator have any > responsibility to pass the request on to all subscribers to purge the > requester from their personal archives? I feel like there's a LOT of > unaddressed issues here, and that singling out the mailing list is > somewhat unfair. But life's unfair. So … ¯_(ツ)_/¯ > > -- > Grant. . . . > unix || die
Re: Spam rule for HTTP/HTTPS request to sender's root domain
Case study: example.com bans any e-mail sent from its third levels up, and does it by spf. spf-banned.example.com sent mail, and my SA at server.com adds a big fat penalty, high enough to bounch it. Suppose I do not bounch it, and use your filter to check for its websites. It turns out that both example.com and spf-banned.example.com have a website. Was it worth it to spend cycles on it? I guess not. The spf is an accepted rfc and it should have priority. So, I recommend the website test to first read the result of the SPF test, quit when positive, continue otherwise. --- ruga On Fri, Mar 1, 2019 at 22:31, Grant Taylor wrote: > On 02/28/2019 09:39 PM, Mike Marynowski wrote: >> I modified it so it checks the root domain and all subdomains up to the >> email domain. > > :-) > >> As for your question - if afraid.org has a website then you are correct, >> all subdomains of afraid.org will not flag this rule, but if lots of >> afraid.org subdomains are sending spam then I imagine other spam >> detection methods will have a good chance of catching it. > > ACK > > afraid.org is much like DynDNS in that one entity (afaid.org themselves > or DynDNS) provide DNS services for other entities. > > I don't see a good way to differentiate between the sets of entities. > >> I'm not sure what you mean by "working up the tree" - if afraid.org has >> a website and I work my way up the tree then either way eventually I'll >> hit afraid.org and get a valid website, no? > > True. > > I wonder if there is any value in detecting zone boundaries via not > going any higher up the tree past the zone that's containing the email > domain(s). > > Perhaps something like that would enable differentiation between Afraid > & DynDNS and the entities that they are hosting DNS services for. > (Assuming that there are separate zones. > >> My current implementation fires off concurrent HTTP requests to the root >> domain and all subdomains up to the email domain and waits for a valid >> answer from any of them. > > ACK > > s/up to/down to/ > > I don't grok the value of doing this as well as you do. But I think > your use case is enough different than mine such that I can't make an > objective value estimate. > > That being said, I do find the idea technically interesting, even if I > think I'll not utilize it. > > -- > Grant. . . . > unix || die
Re: Spam rule for HTTP/HTTPS request to sender's root domain
A future-proof list that complies with GDPR would automatically rewrite the To header, leaving the list address only. Any other recipient will still receive it from the original sender. On Thu, Feb 28, 2019 at 20:29, Mike Marynowski wrote: > Unfortunately I don't see a reply-to header on your messages. What do > you have it set to? I thought mailing lists see who is in the "to" > section of a reply so that 2 copies aren't sent out. The "mailing list > ethics" guide I read said to always use "reply all" and the mailing list > system takes care of not sending duplicate replies. > > I removed your direct email from this reply and only kept the mailing > list address, but for the record I don't see any reply-to headers. > > On 2/28/2019 2:21 PM, Bill Cole wrote: >> Please respect my consciously set Reply-To header. I don't ever need 2 >> copies of a message posted to a mailing list, and ignoring that header >> is rude. >> >> On 28 Feb 2019, at 13:28, Mike Marynowski wrote: >> >>> On 2/28/2019 12:41 PM, Bill Cole wrote: You should probably put the envelope sender (i.e. the SA "EnvelopeFrom" pseudo-header) into that list, maybe even first. That will make many messages sent via discussion mailing lists (such as this one) pass your test where a test of real header domains would fail, while it it is more likely to cause commercial bulk mail to fail where it would usually pass based on real standard headers. (That's based on a hunch, not testing.) >>> >>> Hmmm. I'll have to give some more thought into the exact headers it >>> decides to test. I'm not sure if my MTA puts in envelope info into >>> the SA request or not. For sake of simplicity right now I might just >>> ignore mailing lists, I don't know. What I do know is that in the >>> spam messages I'm reviewing right now, the reply-to / from headers >>> set often don't have websites at those domains and none of them are >>> masquerading as mailing lists. I haven't thought through the >>> situation with mailing lists yet. >>> >>> I'm new to this whole SA plugin dev process - can you suggest the >>> best way to log the full requests that SA receives so I can see what >>> info it is getting and what I have to work with? >> >> The best way to see far too much information about what SA is doing is >> to add a "-D all" to the invocation of the spamassassin script. You >> can also add that to the flags used by spamd, if you want to punish >> your logging subsystem >>
Re: Semi Off-topic: VFEMail destroyed
Live backups are unheard of. The best I can do is a write protected hourly backup, with manual restore... Sent from ProtonMail Mobile On Fri, Feb 15, 2019 at 14:07, @lbutlr wrote: > On 14 Feb 2019, at 19:31, Grant Taylor wrote: >> >> If VFE had backups stored off-site via something like Amazon Glacier with no >> normal in-band connectivity between the main systems and the backups, and >> the hacker went out of their way to delete the backups, I don't think I >> could hold /that/ against VFE. > > I believe that when you hold customer data you have an obligation to have > backups that cannot be deterred by accessing your systems. There are many > possible ways to do this, from a rsync process on another machine that your > network has no write access to that is able to login and do a backup, all the > way up to services like backblaze or Arq that will (or can) keep differential > backups for you. > > If your keys and passwords are so poorly guarded that someone can get access > to everything everywhere and destroy all the data then you did something > wrong. > > -- > How soon after the USPS issues the Calvin stamp will you send a letter with > one > on the envelope? Watterson: Immediately. I'm going to get in my horse and > buggy and snail-mail a check for my newspaper subscription.
Re: New type of SPAM aggression
They are very different tools. One uses an SMTP RFC repeat clause to understand whether the attacker is using a real server, slowing burst connections and eventually adding the IP to the firewall. This is limited to port 25, and it does not work against ddos attacks, because pf is not that efficient. The other tool works on any port, it sits in the firewall, it is process efficient, to manage ddos-like connections, and its purpose is to efficiently redirect the attacker's force back to the attacker, eventually burning the cpu of the attacker. On Wed, Feb 13, 2019 at 05:52, Bill Cole wrote: > On 12 Feb 2019, at 15:04, Rupert Gallagher wrote: > >> Ehhh not available on bsd with pf, or so it was the last time I >> checked. > > A good 'tarpit' tool that IS available for *BSD (originating on OpenBSD) > is 'spamd' which unfortunately shares a name with the daemon aspect of > SA. There's a port for FreeBSD and pf.conf(5) documents its integration > with pf. > >> Good for you as you have it! It is a fantastic piece of aikido. >> >> On Tue, Feb 12, 2019 at 18:19, John Hardin wrote: >> >>> On Tue, 12 Feb 2019, Rupert Gallagher wrote: >>> >>>> and we have now blocked their IP at the firewall, >>> >>> A suggestion: it may hurt them more if you TCP tarpit them instead of >>> just >>> blocking them. That's what I do. > [...] > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Available For Hire: https://linkedin.com/in/billcole
Re: Semi Off-topic: VFEMail destroyed
On Wed, Feb 13, 2019 at 17:51, Pedro David Marco wrote: > FYI > > [https://thehackernews.com/2019/02/vfemail-cyber-attack.html](https://thehackernews.com/2019/02/vfemail-cyber-attack.html?utm_source=feedburner_medium=feed_campaign=Feed%3A+TheHackersNews+%28The+Hackers+News+-+Cyber+Security+Blog%29&_m=3n.009a.1926.ca0ao0c4uu.16rq) Looks like a compromised IP from legit provider. 94.155.49.9 daticum.com [cooolbox.bg](https://www.cooolbox.bg/)
Re: New type of SPAM aggression
On Tue, Feb 12, 2019 at 18:34, RW wrote: > On Tue, 12 Feb 2019 16:49:27 + > Rupert Gallagher wrote: > > Before the change, the >> service stated that the IP fell into their spamtrap, whatever that >> is. > > Seriously? > >> The fact remains that we have never sent mail to the gremlin, > > How can you possibly know that you haven't sent anything to the > spamtrap? Logs!
Re: New type of SPAM aggression
Ehhh not available on bsd with pf, or so it was the last time I checked. Good for you as you have it! It is a fantastic piece of aikido. On Tue, Feb 12, 2019 at 18:19, John Hardin wrote: > On Tue, 12 Feb 2019, Rupert Gallagher wrote: > >> and we have now blocked their IP at the firewall, > > A suggestion: it may hurt them more if you TCP tarpit them instead of just > blocking them. That's what I do. > > Perhaps a little stale, and overkill for manual punishment, but it > documents the tools: > > http://www.impsec.org/~jhardin/antispam/spammer-firewall > > -- > John Hardin KA7OHZ http://www.impsec.org/~jhardin/ > jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org > key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 > --- > The world has enough Mouse Clicking System Engineers. > -- Dave Pooser > --- > Today: Abraham Lincoln's and Charles Darwin's 210th Birthdays
Re: New type of SPAM aggression
I like it! On Tue, Feb 12, 2019 at 18:15, John Hardin wrote: > On Tue, 12 Feb 2019, Rupert Gallagher wrote: > >> Let see if the mail arrives with the correct escaping this time. >> >> body __HAS_URI /(http|https):/// >> tflags __HAS_URI multiple >> meta TMU ( _HAS_URI > 10 ) >> describe TMU Too many URIs (>10) >> score TMU 5.0 > > How about: > > uri __HAS_URI /^http/i > tflags __HAS_URI multiple, maxhits=11 > etc. > >> As rightly noted, the same link is counted twice, for text and html bodies >> when they are present. However, my corpus has more of the odd type, where >> the text and the html parts are different: if you switch from text to html >> you read a different message for the same email. Those who fill their emails >> with lots of useless pics get the spam rating they deserve, so I >> intentionally count all links. >> >> I feel more than generous with 5+5 links, but if you want more, or less, you >> can easily change to fit your local policy. > > -- > John Hardin KA7OHZ http://www.impsec.org/~jhardin/ > jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org > key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 > --- > The world has enough Mouse Clicking System Engineers. > -- Dave Pooser > --- > Today: Abraham Lincoln's and Charles Darwin's 210th Birthdays
Re: New type of SPAM aggression
Ah, ok... On Tue, Feb 12, 2019 at 18:04, RW wrote: > On Tue, 12 Feb 2019 16:38:47 + > Rupert Gallagher wrote: > >> Let see if the mail arrives with the correct escaping this time. >> >> body __HAS_URI /(http|https):/// >> tflags __HAS_URI multiple >> meta TMU ( _HAS_URI > 10 ) >> describe TMU Too many URIs (>10) >> score TMU 5.0 >> > >> Those who fill their emails with lots of useless pics get the spam >> rating they deserve, so I intentionally count all links. > > You stopped doing that when you switched from full to body.
Re: New type of SPAM aggression
Note that the "too many uris" thing has nothing to do with the Russian gremlin who, in the meantime, has disabled the part of the rbl that explains why the IP was listed. Before the change, the service stated that the IP fell into their spamtrap, whatever that is. The fact remains that we have never sent mail to the gremlin, and we have now blocked their IP at the firewall, so if they want to play, they can go play elsewhere.
Re: New type of SPAM aggression
Let see if the mail arrives with the correct escaping this time. body __HAS_URI /(http|https):\/\// tflags __HAS_URI multiple meta TMU ( _HAS_URI > 10 ) describe TMU Too many URIs (>10) score TMU 5.0 As rightly noted, the same link is counted twice, for text and html bodies when they are present. However, my corpus has more of the odd type, where the text and the html parts are different: if you switch from text to html you read a different message for the same email. Those who fill their emails with lots of useless pics get the spam rating they deserve, so I intentionally count all links. I feel more than generous with 5+5 links, but if you want more, or less, you can easily change to fit your local policy.
Re: RE: New type of SPAM aggression
full __HAS_URI /(http|https):/// tflags __HAS_URI multiple meta TMU ( _HAS_URI > 10 ) describe TMU Too many URIs (>10) score TMU 5.0 On Thu, Feb 7, 2019 at 09:12, MAYER Hans wrote: > > >> … All emails were spam with links. … > > We receive such spam mails with a lot of links too. > > Is there a rule which detects a certain amount of links inside an e-mail ?
Re: New type of SPAM aggression
On Wed, Feb 6, 2019 at 15:42, RW wrote: > On Wed, 06 Feb 2019 11:55:07 + > Rupert Gallagher wrote: > >> This is to inform about a new type of SPAM aggression. >> >> We received from Russia, for months, and redirected them >> automatically to an administrative address for manual inspection. All >> emails were spam with links. From the standpoint of the attacker(s), >> all emails were delivered, but none turned into exploits. >> >> Today, we learned that "gremlin.ru" included our IPs in their DNSBL. >> We followed the address to de-list, but gremlin.ru does not exist. >> >> So, if you are successful against Russian spam, you will be ... >> blacklisted by an unknown gremlin. > > You reported some spam and now you are listed in a blocklist, therefore > that list is run by the same spammer. There's no evidence of anything > here aside from a paranoid delusion. No, you idiot! The spammer votes against you on the dnsbl as a revenge. The fact that the dnsbl itself is suspicious and allows downvotes from arrogant spammers just adds up. We do not send spam at all, we never did, and we have never ever sent anything to Russia.
Re: New type of SPAM aggression
Search engines on DNSBLs: multiRBL.valli.org www.rbls.org On Wed, Feb 6, 2019 at 15:19, Tom Hendrikx wrote: > Hi, > > Anyone can start a DNSBL and list IP space of people they don't like, as > you surely know. As long as no one uses such a DNSBL to block traffic, > no harm is done. > > The interesting part is which "engines" (I guess that you mean antispam > software or antispam saas providers) think that such a DNSBL should be > actually used. Can you disclose which parties you found? > > Kind regards, > > Tom > > On 06-02-19 14:40, Rupert Gallagher wrote: >> The spammers at gremlin.ru have just created a homepage, with no >> information on how to delist an IP. >> >> Their fake dnsbl is listed as genuine in at least two antispam engines. >> >> >> On Wed, Feb 6, 2019 at 12:55, Rupert Gallagher > <mailto:r...@protonmail.com>> wrote: >>> This is to inform about a new type of SPAM aggression. >>> >>> We received from Russia, for months, and redirected them automatically >>> to an administrative address for manual inspection. All emails were >>> spam with links. From the standpoint of the attacker(s), all emails >>> were delivered, but none turned into exploits. >>> >>> Today, we learned that "gremlin.ru" included our IPs in their DNSBL. >>> We followed the address to de-list, but gremlin.ru does not exist. >>> >>> So, if you are successful against Russian spam, you will be ... >>> blacklisted by an unknown gremlin. >>> >> >>
Re: New type of SPAM aggression
The spammers at gremlin.ru have just created a homepage, with no information on how to delist an IP. Their fake dnsbl is listed as genuine in at least two antispam engines. On Wed, Feb 6, 2019 at 12:55, Rupert Gallagher wrote: > This is to inform about a new type of SPAM aggression. > > We received from Russia, for months, and redirected them automatically to an > administrative address for manual inspection. All emails were spam with > links. From the standpoint of the attacker(s), all emails were delivered, but > none turned into exploits. > > Today, we learned that "gremlin.ru" included our IPs in their DNSBL. We > followed the address to de-list, but gremlin.ru does not exist. > > So, if you are successful against Russian spam, you will be ... blacklisted > by an unknown gremlin.
Re: Another form of obfuscation email.
I would focus on the headers: they have plenty for a spam flag. On the body, SA should already mark the text/code ratio, and the number of links. On Sun, Jan 27, 2019 at 05:43, Mark London wrote: > Does anyone have any rules that can catch this type of obfuscated spam? > > https://pastebin.com/qi8dsREW > > Thanks. - Mark
Re: Huge spam increase
row Sent from ProtonMail Mobile On Wed, Jan 23, 2019 at 14:42, Rupert Gallagher wrote: > Nope. We are celebrating the 5th month in a raw with zero spam in users > folders. > > On Tue, Jan 22, 2019 at 18:12, Pedro David Marco > wrote: > >> Out of curiosity... >> >> we are noticing a huge spam increase (x10) from the last 2 days... maybe any >> reactivated botnet??? >> >> is someone noticing it as well? >> >> - >> PedroD
Re: Huge spam increase
Nope. We are celebrating the 5th month in a raw with zero spam in users folders. On Tue, Jan 22, 2019 at 18:12, Pedro David Marco wrote: > Out of curiosity... > > we are noticing a huge spam increase (x10) from the last 2 days... maybe any > reactivated botnet??? > > is someone noticing it as well? > > - > PedroD
Re: gcc -> clang
Sorry! Ignore/delete. On Thu, Jan 3, 2019 at 11:42, Rupert Gallagher wrote: > The compiler returns many warnings, and the test returns two IPv6-related > errors. I am attaching both logs as reference. > > ‐‐‐ Original Message ‐‐‐ > On Thursday, January 3, 2019 9:53 AM, Aki Tuomi > wrote: > >> We compile all core code with both gcc and clang. What sort of interesting >> things did you find? >> >> Aki >> >>> On 03 January 2019 at 11:50 Rupert Gallagher via dovecot < >>> dove...@dovecot.org> wrote: >>> >>> Please, use clang instead of gcc. Code quality can only profit from it. I >>> just compiled 2.3.4 and compiler stderr is full of interesting problems. >> >> --- >> Aki Tuomi
Re: BITCOIN_PAY_ME and new type of blackmail, non porn.
Please paste the original header. On Mon, Dec 17, 2018 at 20:15, Mark London wrote: > This email hit the new (to me) BITCOIN_PAY_ME rule. Never ending fun. > > Begin forwarded message: > >> From: "Broaddus Walther" >> Date: December 17, 2018 at 1:49:04 PM EST >> To: m...@psfc.mit.edu >> Subject: You should definitely go through this before something negative can >> happen 17.12.2018 08:49:31 > >> I own a site that have all types of offerings which actually i sell in >> darknet.Just about anything from entirely ruining somebody's small business >> to human injuries and so forth, on the other hand almost nothing serious >> just like getting rid of. Most of the time it's all that shit similar too >> refused relationships or rivalry at your workplace.Anyway i have been >> previously reached this week by client to make an order and also target is >> evidently you. In a instant and painless approach. The thing is i only get >> money soon after any completed task and so choice to contact you before, in >> order to pay me just for sitting inactive which i usually proffer the >> target.In the event that i don't receive what i'm requesting, my people will >> accomplish the request.But if we'll generate deal, besides canceling the >> order you are going to obtain complete information associated with the >> customer that i have discovered. Quickly after the order is finished, I >> often clear away the operator as well, so i have got a selection, getting >> 1200 out of you, basically with no tough work, or perhaps to get four >> thousand from purchaser, but to get rid of my operator. >> >> I am obtaining exchanges solely via Bitcoin, this is my bitcoin transaction >> address - 1MfNdCu4diTCsaJNDnVdWHbFdNpdNcWK8X >> >> Now you have 34 hours to transfer.
Re: SpamSender with 2 @-signs in the address
Problem solved last year on this list. Sent from ProtonMail Mobile On Wed, Dec 12, 2018 at 15:32, Benny Pedersen wrote: > Matus UHLAR - fantomas skrev den 2018-12-12 14:55: > >> From: "name surname " > > From:name ne From:addr > > dont know if sa can test this
Re: spoofing mail
Although the RFC allows muas not to include the mid, the same RFC does not mandate mtas to accept them. Since 100% of such emails on our records are spam, then we reject them upfront. I understand that spammers and scummers hate our policy, but hey, who cares, right? Our inbox, our rules. On Fri, Nov 30, 2018 at 10:06, Matus UHLAR - fantomas wrote: > On 29.11.18 09:30, Rupert Gallagher wrote: >>Message-ID and To have the same domain, but From does not. You should have >> never received that mail. > > this happens when message-id is added by mailserver of the recipient. > Should hit MSGID_FROM_MTA_HEADER. > > And, yes, there could be rule that catches message-id added by internal > server. Note that: > - Message-ID is not required (has SHOULD in RFC) > - many mailservers add message-id if it doesn't exist. > >>On Wed, Nov 28, 2018 at 19:15, Rick Gutierrez wrote: >> >>> El mié., 28 nov. 2018 a las 6:03, Christian Grunfeld >>> () escribió: >>>> >>>> Hi, >>>> >>>> this is a logcould you paste the email headers? >>>> >>>> cheers >>>> >>> I do not know if it is useful, the amavisd + spamassassin I have it in >>> front of the mail server. >>> >>> https://pastebin.com/ktMUDLps > > not available anymore :-( > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95
Re: spoofing mail
Message-ID and To have the same domain, but From does not. You should have never received that mail. On Wed, Nov 28, 2018 at 19:15, Rick Gutierrez wrote: > El mié., 28 nov. 2018 a las 6:03, Christian Grunfeld > () escribió: >> >> Hi, >> >> this is a logcould you paste the email headers? >> >> cheers >> > I do not know if it is useful, the amavisd + spamassassin I have it in > front of the mail server. > > https://pastebin.com/ktMUDLps > > I appreciate any comments or help. > > -- > rickygm > > http://gnuforever.homelinux.com
Re: semi-OT - reporting an organization that ignores unsubscribe requests
The "right to be forgotten" is the natural outcome of three decades of self-inflicted pain. Some argue that deleting old e-mails is like re-writing history. Other, like me, argue that e-mail was born as an informal medium, different than, for example, a published book or factual evidence of a genocide. I contend that e-mail can only be included as evidence in court if the forensics are both sound and complete, because (most) e-mails can be easily fabricated. Would you like to be convicted by a fake e-mail? I guess not. Also, many of those "archives" have no legal or commercial value. They are not a book you can re-sell. Granted that, there are people who committed suicide out of shame, because they were the object of defamation or cyberbullying, things that move almost no one, until it happens to their children. A number of lawyers in the EU just couldn't pass by without taking notice. Both the US and the UN at some point will follow up, and make the world a better place. On Wed, Nov 21, 2018 at 20:39, Anne P. Mitchell, Esq. wrote >> On Nov 21, 2018, at 12:03 PM, Bill Cole >> wrote: >> >> On 21 Nov 2018, at 13:03, Anne P. Mitchell, Esq. wrote: >> >>> Except for the private right of action provided in GDPR, and small claims >>> court in the U.S. >> >> Are you saying an EU law can create an actionable civil tort claim in a US >> state small claims court for actions which are not illegal under any US >> state or federal law? > > No, I'm saying that anybody can sue anybody for anything in the U.S., and > it's extremely easy to file an action in small claims court. It wouldn't even > have to be, technically, 'under' GDPR (as you mention, there is always tort) > - but GDPR would be the hook that they would use, and the authority (note I > said authority, not law) they would cite. > > That said, I think it's much more likely that the lawsuits already filed > against Google and Facebook by Max Schrems will be ones to test the > jurisdiction/enforcement issues. > > Anne > > Anne P. Mitchell, > Attorney at Law > GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Legislative Consultant > CEO/President, Institute for Social Internet Public Policy > Board of Directors, Denver Internet Exchange > Board of Directors, Asilomar Microcomputer Workshop > Legal Counsel: The CyberGreen Institute > Legal Counsel: The Earth Law Center > California Bar Association > Cal. Bar Cyberspace Law Committee > Colorado Cyber Committee > Ret. Professor of Law, Lincoln Law School of San Jose > Ret. Chair, Asilomar Microcomputer Workshop
Re: semi-OT - reporting an organization that ignores unsubscribe requests
On Wed, Nov 21, 2018 at 03:41, John Hardin wrote: > On Tue, 20 Nov 2018, Rupert Gallagher wrote: > >> The email address is an address, part of your personally identifiable >> data. > > I'm not disputing that. I write software that deals with PII in my day job. > >> If an identifiable entity in the US sends mass mail to European >> addresses, then they must have a representative in Europe and comply >> with the GDPR. > > (1) how do you *force* someone in the US to have a representative in > Europe? > You file a complaint with your national ombudsman. In your case, stress the > fact that they are processing political data in addition to common data. Do > not expect immediate termination of spam. The ombudsman will proceed to > verify the facts, identify the parties involved, check compliance claims, and > enforce the EU-US bilateral agreement. In the end, the spammers will most > likely refuse to appoint an EU representative, and the EU will shut down > their website. > (2) if they do no business in the EU, and do not have any presence in the > EU (sending email to addresses in the EU is not "having a presence in the > EU"), how are they subject to fines for violating the law in the EU? > > If, for example, I - a private, non-commercial entity - hosted a mailing > list on my private server (which I have done in the past), and someone in > the EU subscribed and posted to that list and their email address was > captured in the list archives, and they later unsubscribed and asked for > their email address to be removed from the list archives, and I (for > whatever reason) did not do so, *how* would an EU court levy fines against > me? > > The US is not a signatory to the GDPR as far as I am aware, and I have > *no* legal presence outside the US. > The US signed a bilateral agreement with the EU: https://www.privacyshield.gov/ > >> On Tue, Nov 20, 2018 at 17:03, John Hardin wrote: >> >>> On Tue, 20 Nov 2018, Rupert Gallagher wrote: >>> >>>> Yes, if you are European, and might get some money as compensation. >>> >>> From a US political advocacy group which has no commercial presence in EU? >>> How does GDPR apply in that situation? >>> >>>> On Mon, Nov 19, 2018 at 04:19, Joe Acquisto-j4 >>>> wrote: >>>> >>>>> Gents, >>>>> >>>>> I somehow became subscribed to a list, political in nature, in whose mail >>>>> I have no interest. This is a legitimate AFAIK, US organization. >>>>> >>>>> Thus far, several uses of their unsubscribe link had not provided relief. >>>>> Direct email to the founder and operations manager seem to have been >>>>> ignored as well. >>>>> >>>>> While I can just dump their mail, it offends my finely hones sense of >>>>> propriety, justice and my all around good nature. Besides, it hoses me >>>>> off. >>>>> >>>>> So, is there some "authority" to which I can report these a**holes? that >>>>> might have an effect? > > -- > John Hardin KA7OHZ http://www.impsec.org/~jhardin/ > jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org > key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 > --- > The question of whether people should be allowed to harm themselves > is simple. They *must*. -- Charles Murray > --- > 600 days since the first commercial re-flight of an orbital booster (SpaceX)
Re: semi-OT - reporting an organization that ignores unsubscribe requests
The email address is an address, part of your personally identifiable data. If an identifiable entity in the US sends mass mail to European addresses, then they must have a representative in Europe and comply with the GDPR. On Tue, Nov 20, 2018 at 17:03, John Hardin wrote: > On Tue, 20 Nov 2018, Rupert Gallagher wrote: > >> Yes, if you are European, and might get some money as compensation. > > From a US political advocacy group which has no commercial presence in EU? > How does GDPR apply in that situation? > >> On Mon, Nov 19, 2018 at 04:19, Joe Acquisto-j4 wrote: >> >>> Gents, >>> >>> I somehow became subscribed to a list, political in nature, in whose mail I >>> have no interest. This is a legitimate AFAIK, US organization. >>> >>> Thus far, several uses of their unsubscribe link had not provided relief. >>> Direct email to the founder and operations manager seem to have been >>> ignored as well. >>> >>> While I can just dump their mail, it offends my finely hones sense of >>> propriety, justice and my all around good nature. Besides, it hoses me off. >>> >>> So, is there some "authority" to which I can report these a**holes? that >>> might have an effect? > > -- > John Hardin KA7OHZ http://www.impsec.org/~jhardin/ > jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org > key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 > --- > The world has enough Mouse Clicking System Engineers. > -- Dave Pooser > --- > 600 days since the first commercial re-flight of an orbital booster (SpaceX)
Re: semi-OT - reporting an organization that ignores unsubscribe requests
Spam is income for those who sell it, a cost for those who buy it, and a liability for those who receive it. Thousands of junk and weaponized messages try their luck while wasting our resources. It is not by accident that we have anti-spam laws. Our unpaid job is to reject spam efficiently. Sometimes you cannot reject it, because sent properly, by someone you can identify, and it falls within your legal reach. That's when you file a complaint to the ombudsman and cash in a small reward for the inconvenience. Laws are there for us, not against us. On Tue, Nov 20, 2018 at 11:36, Martin Gregorie wrote: > On 18 Nov 2018, at 22:19, Joe Acquisto-j4 wrote: >> >> > Gents, >> > >> > I somehow became subscribed to a list, political in nature, in >> > whose mail I have no interest. This is a legitimate AFAIK, US >> > organization. >> > > I just auto-bin this stuff if their 'unsubscribe' link doesn't work. > Emirates, the well-known airline, is the latest outfit to get this > treatment here. > > However, given the recently mentioned US freedoms of political speech, > why can't you simply exercise your freedoms by reflecting it back to > the mailing list unseen but with a polite note added to the the body in > big caps saying something along the lines of: > > "I tried to unsubscribe from your list but that doesn't work, so here's > your unwanted mail back. Kindly take me off your list". > > I don't see how that could be twisted into offensive speech, but it > just might embarrass their mailadmin into taking you off the list. > > Martin
Re: semi-OT - reporting an organization that ignores unsubscribe requests
Yes, if you are European, and might get some money as compensation. On Mon, Nov 19, 2018 at 04:19, Joe Acquisto-j4 wrote: > Gents, > > I somehow became subscribed to a list, political in nature, in whose mail I > have no interest. This is a legitimate AFAIK, US organization. > > Thus far, several uses of their unsubscribe link had not provided relief. > Direct email to the founder and operations manager seem to have been ignored > as well. > > While I can just dump their mail, it offends my finely hones sense of > propriety, justice and my all around good nature. Besides, it hoses me off. > > So, is there some "authority" to which I can report these a**holes? that > might have an effect?
Re: config files in spamasassin is unintended tlds :/
.local is a valid tld for LANs. Please do not mess with the DNS. On Sun, Nov 4, 2018 at 17:14, Benny Pedersen wrote: > is it a problem ? > > i think it should be solved to make configfiles local dns resolved only, > if at all it needs to be dns > > so cf changes to cf.localdomain or cf.localhost, not just use cf with is > a valid cctlds :( > > is cf.local valid and where ? > > i have not maked a bug on it yet, but will start here to hear what > should be done
FireEye...
...catched sending spam to a gmail address, twice, using our fqdn. From google: google.com noreply-dmarc-supp...@google.com [...] example.com s s reject reject 100 154.57.155.23 2 none pass fail [...] From whois: FireEye, Inc. FIREEYE-CGNT-154-57-155-1 (NET-154-57-155-0-1) 154.57.155.0 - 154.57.155.255
Re: Is fuzzyocr i.e. Image scanning
I see a vps and an ".expert" tld sender domain. My servers handle those with a REJECT rule. On Fri, Oct 12, 2018 at 15:11, Brent Clark wrote: > Good day Guys > > I am getting quite a bit of image spam, and googling put me in the > direction of a tool called FuzzyOCR. > > What I did was configure vagrant to install spamassassin and fuzzyocr, > and fuzzyocr does not appear to be catching my spam (The example > provided work). > > Before I go down the road of installing and configuring fuzzyocr on my > MTA, I thought I would double check with the spamassassin community and > ask is there still a place for image scanning in 2018? > > The documentation is fairly old, so it got me wondering if image > scanning and old technology and method. > > Thanks in advance. > > Regards > Brent > P.s. Here is a pastebin link of what I am seeing. > https://pastebin.com/raw/gurvFrZw
Re: Is fuzzyocr i.e. Image scanning
My comments on http://pralab.diee.unica.it/en/ImageCerberus IC is an effort to dig a hole in the water, because the problem of image spam with obfuscated text cannot be solved by ocr. My approach is a "better safe than sorry" best practice that anyone can implement with existing software: 1. do not display inline the content of attachments and linked resources; 2. give high spam score (>=5) to any email with very low text to image ratio. On pdf and similar attachments, reject anything with built in macros or scripts. R On Tue, Oct 16, 2018 at 06:49, Olivier wrote: > Brent, > > I have Fuzzy OCR installed and running, but the only rule that was > trigered 22 times during the past 40 days was FUZZY_OCR_WRONG_CTYPE, > meaning that the image type does not match the content-type set for > MIME. > > That is still a valid catch, but not based on the OCR'ed text. > > One of my holdback with FuzzyOCR is that you have to provide an > independant word list, while we have a very good tool to analyze text > contents: SpamAssassin itself. So I would much prefer FuzzyOCR to feed > the OCR'ed text back to SA for further analysis (the way pdfAssassin is > working). But then, we need a way to detect that the OCR process has > worked, that some more or less valid text, in a valid language has been > extracted. > > Another approach I like is the one of Image Cerberus (dig in > http://prag.diee.unica.it/amilab) which uses meta data of the image > (size, histogram of colours, etc.) to classify the image as probable > spam or probable ham and then implements Bayes classifier. > > As for your question about the place for image scanning, if your MTA has > the resources to do so, why not? And if FuzzyOCR is not yet the ultimate > OCR solution, it is still improving, so why give-up a tool that can > help? > > Regards, > > Olivier > --
Re: Phishing email or no?
I met the administrator of a national airway company whose IP addresses (used to send airplane tickets) were blacklisted. He had serious problems recovering the reputation of those IPs. Failing that, he jumped into O365, but they are still having problems. I am not surprised. On Sun, Oct 14, 2018 at 08:17, Daniele Duca wrote: > On 13/10/2018 19:51, Rupert Gallagher wrote: > >> "The message was marked as spam by the content filter." >> >> Nice... so they know they are sending spam! > > Who doesn't :) > > I mean, for a setup big enough like theirs, having abused accounts or > outright spammers is somewhat endemic. What I think they are doing is trying > to limit the damages by routing outbound thought spam with different /24s > hoping to keep most used IPs as clean as possible. I do the same for outbound > emails, but my setup have a little more than 10k users and I deal immediately > with any abused account. > > Just FYI, I looked at my logs for the last 10 days and I have ~250 email > inbound from O365 tagged with SFV:SPM , about 50 are legit emails (so their > error), but more worrying is that there is also malware being delivered from > O365 :( This mean they don't even do basic outbound virus scanning, or do it > very poorly. > > On 12/10/2018 23:40, David Jones wrote: > >> Maybe they need to start using >> >> SpamAssassin and hire some of us to do their mail filtering. :) > > I think that too :D > > Daniele
Re: Phishing email or no?
"The message was marked as spam by the content filter." Nice... so they know they are sending spam! Sent from ProtonMail Mobile On Sat, Oct 13, 2018 at 11:40, Daniele Duca wrote: > On 12/10/2018 23:12, Pedro David Marco wrote: > >>>On Friday, October 12, 2018, 10:48:21 PM GMT+2, Rupert Gallagher >>>[](mailto:r...@protonmail.com) wrote: >> >>>I love outlook.com ... >> >> i have seen recently an Office365 Phishing campaign coming from Office365 >> severs... as good as it gets... > > It may be already known, but O365 does some outbound spam filtering and adds > some interesting headers on every email. It also uses different IP pools for > outbound emails that it thinks are > spam:https://docs.microsoft.com/en-us/office365/SecurityCompliance/anti-spam-message-headers > > I personally check the X-Forefront-Antispam-Report header for the string > "SFV:SPM" and bump the score accordingly. Some phishing campaigns that I saw > in the past and that came from O365 ip space had that header set, but it's > not perfect in any way, there are many FPs, so don't just blindly trust their > headers. > > Daniele
Re: Phishing email or no?
I love outlook.com ... Sent from ProtonMail Mobile On Thu, Oct 11, 2018 at 22:30, Alex wrote: > Hi, > > I'm curious what people think of this: > > https://pastebin.com/1XjwaCY1 > > It's unsolicited, so that makes it spam to me, but is it dangerous? > yesinsights.com appears to be a legitimate company, but the sender, > e...@hrteamerus.com, is a registered domain but has no DNS record. > > Is it just a lame attempt to confirm email addresses? > > Outlook just seems to be a non-stop source of spam. I'd report it to > yesinsights, but it appears it's being used exactly as the service > intended? > > Any idea on tips to block it, other than bayes?
Re: Bitcoin update
You did well. Not perfect, but nearly there. The key words here are: dynamic, helo, from and to. No need to use a black list. The message was sent from a dynamic IP. No reputable email server does that. The next reason to reject is the failure of SPF. The recipient should implement SPF correctly. The third reason is the Message-ID. RG On Fri, Oct 5, 2018 at 23:57, David Jones wrote: > On 10/5/18 4:38 PM, Antony Stone wrote: >> On Friday 05 October 2018 at 23:26:12, Rupert Gallagher wrote: >> >>>> https://pastebin.com/TRD7FzRQ >>>> >>>> I have a sample here >>> >>> There are at least three reasons to reject that e-mail upfront, with no >>> need to parse its body. >> >> Hints might be appreciated for the uninitiated. >> >> >> Antony. >> >> >> PS: Please do NOT set Reply-To to your own address on list postings. >> > > Are you doing any RBLs at the MTA? This thing looks really bad and > would never have made it past my Postfix postscreen_dnsbl_sites list. > > http://multirbl.valli.org/lookup/114.46.223.46.html > > If it had made it to SpamAssassin, here's what my rules would have scored: > > Content analysis details: (29.8 points, 5.0 required) > > pts rule name description > -- > -- > 5.2 BAYES_99 BODY: Bayes spam probability is 99 to 100% > [score: 1.] > 3.2 BAYES_999 BODY: Bayes spam probability is 99.9 to 100% > [score: 1.] > 0.5 FROM_DOMAIN_NOVOWEL From: domain has series of non-vowel letters > 1.5 CK_HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname > (Split IP) > 0.2 CK_HELO_GENERIC Relay used name indicative of a Dynamic Pool or > Generic rPTR > 1.9 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date > 3.2 DCC_CHECK Detected as bulk mail by DCC (dcc-servers.net) > 0.1 FROM_EQUALS_TO From: and To: have the same username > 0.0 KHOP_DYNAMIC Relay looks like a dynamic address > 3.6 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr > 2) > 1.0 RDNS_DYNAMIC Delivered to internal network by host with > dynamic-looking rDNS > 2.2 ENA_RELAY_NOT_US Relayed from outside the US and not on > whitelists > 0.1 HDR_ORDER_FTSDMCXX_DIRECT Header order similar to spam > (FTSDMCXX/boundary variant) + direct-to-MX > 2.0 MIMEOLE_DIRECT_TO_MX MIMEOLE + direct-to-MX > 2.5 DOS_OE_TO_MX Delivered direct to MX with OE headers > 2.5 NO_FM_NAME_IP_HOSTN No From name + hostname using IP address > 0.0 ENA_BAD_SPAM Spam hitting really bad rules. > > -- > David Jones
Re: Bitcoin update
> https://pastebin.com/TRD7FzRQ > I have a sample here There are at least three reasons to reject that e-mail upfront, with no need to parse its body.
Re: Non-ascii subjects with images
This is a subject line: Re: Habemus APP LG On Sat, Sep 1, 2018 at 14:15, Antony Stone wrote: > On Saturday 01 September 2018 at 14:09:52, Rupert Gallagher wrote: > >> On Sat, Sep 1, 2018 at 09:35, Pedro David Marco wrote: >> > >> >> On Saturday, September 1, 2018, 7:02:20 AM GMT+2, Rupert Gallagher wrote: >> > > >> > > Do you have an SA rule for it? >> > >> > Do you have any sample, Rupert? >> >> Of course I do. > > Would you care to show us? > > Antony. > > -- > I wasn't sure about having a beard at first, but then it grew on me. > > Please reply to the list; > please *don't* CC me.
Re: Non-ascii subjects with images
Of course I do. On Sat, Sep 1, 2018 at 09:35, Pedro David Marco wrote: > Do you have any sample, Rupert? > >>On Saturday, September 1, 2018, 7:02:20 AM GMT+2, Rupert Gallagher >> wrote: >> >>Do you have an SA rule for it?
Non-ascii subjects with images
Do you have an SA rule for it?
Re: spample: porn extortion with pure numeric From domain and base64 body
OK at a second glance I would say rejected upfront again, because its From domain is NXDOMAIN. On Wed, Jul 18, 2018 at 14:34, Daniele Duca wrote: > On 18/07/2018 14:22, Rupert Gallagher wrote: > >> At first glance I would say rejected upfront, because the client >> 180.252.178.204 does not have RDNS. No need for SA. > > I wish I could 5xx last untrusted relays without rdns without having the > company's phones melt :) > > Daniele
Re: spample: porn extortion with pure numeric From domain and base64 body
At first glance I would say rejected upfront, because the client 180.252.178.204 does not have RDNS. No need for SA. On Wed, Jul 18, 2018 at 02:00, Chip M. wrote: > http://puffin.net/software/spam/samples/0058_extortion_numeric_domain.txt
Line too long [rfc 2822, section 2.1.1]
A little survey on your local policies... What do you do when a subject line is longer than 78 characters? A. Reject B. Accept as spam C. Accept
Re: MISSING_SUBJECT
On Wed, Jun 13, 2018 at 10:38, Matus UHLAR - fantomas wrote: > MISSING_SUBJECT is here because when message has no Subject:, it is highly > probably spam. Right. Well, my new accountant, being an external company of 16 people, insists in sending messages without a subject, "because we always did, and you are the only one complaining". These are the same people who cannot bother reading the bounched message that says "your e-mail was rejected because it does not contain a subject" and, when interrogated, they respond that "the e-mail was rejected". This reminds me of a common practice in both UK and CH where people anticipate by phone call that an e-mail is coming and then they call again to make sure it arrived, with some wanting a subject line that says "From to : ". The take-away is: if you manage a company, make sure your employees know their ABCs, and if you are a company, insist on best practices with both your clients and providers. To close, I think we need standard leaflets to pass around stubborn employees.
Re: More outlook phish
On Fri, Jun 8, 2018 at 23:05, David Jones wrote: > 2.2 MISSING_HEADERS Missing To: header The fillowing is all one needs. 5.0 MISSING_HEADERS Missing To: header Remember that e-mail is mail after all.
Re: More outlook phish
You did well in noting the lack of the To header. Just raise its score to 5.0. Sent from ProtonMail Mobile On Fri, Jun 8, 2018 at 22:17, Alex wrote: > Hi, Received this one today that was delivered to about 25 recipients, lacked > a To header, routed through outlook.com and contained a link to a Google > Drive doc that's still active. https://pastebin.com/y1k0LtM1 It was done > under the pretense of a ShareFile attachment. Is a plugin necessary to tag on > when the Subject matches content in the From? I've created some body rules, > and tweaked my existing outlook.com rules, but I thought everyone should see > this, and thought others might have additional ideas for blocking...
Re: List From and Reply-To
In the example at hand, the article you linked to does not grant to Apache the right to oppose to your right to oblivion. Sent from ProtonMail Mobile On Fri, Jun 1, 2018 at 14:45, Anthony Cartmell wrote: >> Ok we both subscribed to the list, but > the GDPR gives us the right to be >> forgotten, for example. Now suppose > you unsubscribe. You find out that >> your e-mails are archived on various > sites other than SA. You send an >> e-mail to SA's or Apache's postmaster > exerting your rights and demanding >> your shit to be deleted. According to > the GDPR, Apache *must* comply *and* >> it must forward the demand to all > of the third party archives. Nope. The >> right to be forgotten does not supersede every other interest, and there are >> situations where personal data does *not* need to be deleted: >> https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/dealing-citizens/do-we-always-have-delete-personal-data-if-person-asks_en >> Anthony -- www.fonant.com - Quality web sites Tel. 01903 867 810 Fonant Ltd >> is registered in England and Wales, company No. 7006596 Registered office: >> Amelia House, Crescent Road, Worthing, West Sussex, BN11 1QR
Re: List From and Reply-To
I lost track of your reasoning. Let us start again. From the standpont of the GDPR, there is you, me, and someone in between who is responsible for our personal data. Infact, if you send to users@spamassassin.apache.org, I receive a copy of it *because* apache.org used our addresses. Ok we both subscribed to the list, but the GDPR gives us the right to be forgotten, for example. Now suppose you unsubscribe. You find out that your e-mails are archived on various sites other than SA. You send an e-mail to SA's or Apache's postmaster exerting your rights and demanding your shit to be deleted. According to the GDPR, Apache *must* comply *and* it must forward the demand to all of the third party archives. And it must do so quietly, that is, not publishing your demand on the internet. A lawyers matter? Well, the law is on the table, and one must execute it. Now, what I said is, to prevent this mess, the mailing list could clean up before itself by simply (relatively) obfuscating the addresses and removing any banner signature that hold personal data (full address and such). Am I making sense now?
Re: Dynamic clients
Stiff piece of shit, dumped long ago. Sent from ProtonMail Mobile On Fri, Jun 1, 2018 at 08:05, @lbutlr wrote: > On 31 May 2018, at 01:52, Rupert Gallagher wrote: > How much do you pay for > it? Someone has a stiff piece of cellulose in a downward facing bodily > orifice about spamhaus, it appears. -- Mirrors contain infinity. Infinity > contains more things than you think. Everything, for a start. Including > hunger. Because there's a million billion images, but only one soul to go > around. --Witches Abroad @protonmail.com>
Re: List From and Reply-To
On Thu, May 31, 2018 at 17:39, Antony Stone wrote: >PS: I notice you choose to take the opposite approach with your own Reply-To >header, deliberately making it more difficult for people to reply to the list >:) I just use the official ios client, where such regulations are not possible. This is an example of default client settings that may put you in trouble, and the usefulness of server-side enforced policy. Servers can automatically do things to keep both owners and clients on the safe side of the law. We shall not make the mistake of ignoring the GDPR: many sites are going down as we speak.
