Re: Anyone have a rule to detect "Dear xxx" in the body of the message where the "To:" address is xxx@domain?

[Grant Taylor via users]

On 7/19/24 5:34 AM, giova...@paclan.it wrote:

do you intend to have a rule like this one ?

header __TO_NAME To:name =~ /(?.*)/
body   DEAR_NAME /Dear %{TO_NAME}/


Once I'm dealing with versions of SpamAssassin that support such, yes.

I'm currently caring for and feeding a small group of older servers.



--
Grant. . . .
unix || die

Re: Anyone have a rule to detect "Dear xxx" in the body of the message where the "To:" address is xxx@domain?

[Grant Taylor via users]

On 7/18/24 15:58, Mark London wrote:
I asked ChatGPT how to test for a "Dear 'username'".  After a bit of 
work, I got working code.


Okay.


ChatGPT knows perl.


I question the value of "knows" as in knowledge of Perl.

I already had a Perl file EvalTests.pm file with customized Perl eval 
functions, so I threw it in there.  Otherwise, you'll need to create 
your own file with the proper headers.


sub check_body_for_username {
     my ($self, $permsgstatus) = @_;

     my $to = $permsgstatus->get('To:addr');
     return 0 unless $to;

     my ($username) = $to =~ /([^@]+)/;
     return 0 unless $username;

     # Check if the username is in the body of the email
     my $body = $permsgstatus->get_decoded_stripped_body_text_array();
     foreach my $line (@$body) {
     if ($line =~ /^(Dear|Hi|Hello) \Q$username\E\b/i) {
     return 1;
     }
     }
     return 0;
}

header DEAR_USERNAME    eval:check_body_for_username()


Very interesting.

I'll have to find a stick to poke this with and some time to do the poking.

Thank you for sharing.



--
Grant. . . .


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Anyone have a rule to detect "Dear xxx" in the body of the message where the "To:" address is xxx@domain?

[Grant Taylor via users]

On 7/17/24 18:04, Matija Nalis wrote:
I.e. would you consider it to be significantly less likely to be 
spam if it contained "Dear Elizabeth," while being addressed to 
"mark@domain" instead of to "elizabeth@domain" ?


I've seen quite a bit of spam that opens message bodies with:



Where  is "Dear" or some other greeting, often language 
specific and  is the local part of the email address.


Something like the following is probably a good indication that it's spam:

--8<--
Dear ux37932,

I've missed talking to you, what is your opinion of ?  Please check 
it out and let me know what you think.

-->8--

If there was any doubt about the paragraph, the "ux37932" makes it quite 
evident to a human that the name in the salutation is not real.  This is 
ESPECIALLY true when the name in the salutation is identical, byte for 
byte, including case, as the local part of the email address.




--
Grant. . . .


smime.p7s
Description: S/MIME Cryptographic Signature

Re: ChatGPT > Spamassassin? :) -- move along, this is not the reply you are looking for.

[Grant Taylor via users]

On 6/25/24 12:21 PM, Adam Bowen wrote:
I asked a well known chatbot: What would Bill Cole say if he was asked 
about integrating AI in to spamassassin?


LOL

I needed that laugh.

Thank you Adam.




--
Grant. . . .
unix || die

Re: OT: Trigger words in email addresses?

[Grant Taylor via users]

On 4/8/24 5:44 AM, Antony Stone wrote:
- make your systems transparent so that people feel they understand 
what's happening and when at different stages in the process - don't 
create a "corporate black box" which customers can't understand


I'll add to this and say that URLs that include things like email 
addresses for things like unsubscribe forms are okay.  Make these things 
obvious and transparent.  If at all possible, avoid any obfuscated 
parameters.  If you do need something like a checksum or signature or 
validation token (think message authentication code), make it as short 
and as clear as possible.  E.g.



https://contact.example.com/email-preferences.html?email=u...@example.net&action=unsubscribe&checksum=abc123



--
Grant. . . .
unix || die

Re: OT: Trigger words in email addresses?

[Grant Taylor via users]

Below is my opinion, it's worth everything you paid for it.  But I do 
suggest you read it and think about it for a few minutes.


On 4/7/24 20:40, Jerry Malcolm wrote:

I send the validation email from donotre...@xyz.com.


I absolutely hate the do not reply type email addresses as you're trying 
to use them.  Not because I get annoyed at people replying -- and people 
will reply -- but because I think that doing such is a wasted opportunity.


I think you should send with an SMTP envelope that uses some form of 
VERP to be able to correlate inbound messages with the original outbound 
recipient address.


I think that you should send using a friendly From: header address.

I think that you should embrace user+detail in the From: header so that 
you can do similar correlation of inbound messages with the original 
outbound recipient address.


I think that you should leverage the Reply-To: header to try to steer 
replies somewhere useful, like the ticketing system.


I think the ticketing system should be aware of the U+D data and use 
that to prime the association of the inbound message with a client ID / 
account number / etc.


We have a ticket reporting system and seriously want to discourage 
users from sending in problem reports by email.


Does your ticketing system have a way to generate tickets from email?  I 
assume that it does.  I strongly suggest that you leverage it and cause 
the emails that people will send to be routed to the ticketing system.


DoNotReply is actually a legit inbox, and I monitor it to catch 
users that haven't yet mastered the art of reading.


The universe is winning.  The universe will always win.  No matter how 
smart we make the mouse trap, there will always be mice that avoid it / 
get out of it / break it / etc.


I want to keep that DoNotReply email address to tell the 
user "don't send an email to this address"


That's a never ending battle.  Stop fighting a battle that you can not win.

Pull a Kobayashi Maru and make what people naturally want to do work for 
you.


But I have a co-worker that is convinced that "donotre...@xyz.com" 
is a trigger for gmail's spam filters and all spam filters will score 
the email higher as spam due simply to that word in the email address. 
I'm not convinced.


I don't know about Google, but I perceive do not reply types of email 
addresses as a broadcast only sender and I have poor opinions of them.


On the flip side, I have high opinions of senders that can take my input 
any way that is convenient for me, even if that's replying or sending a 
new email to an address I just received a message from.


I do not want to change it to something else that will encourage users 
to start inundating us with questions/problems by email instead of 
using our established ticket system..


Why can't the email address be a gateway into the ticketing system?

Let users do what they want to do and comes naturally to them while it 
also does what you want by routing messages to the ticketing system.


But I also don't want to be shooting myself in the foot with spam 
filters by using that name if it's indeed a trigger word.


I have no first hand experience there because I always try to use system 
generated emails as a way to steer inbound messages like I've described 
here.  I'd suggest sending from an address that accurately describes 
what the messages are; password-reset@, automated-bill-reminder@, what 
have you.  Don't hide.  Be clear about what you are doing and why you 
are doing it.


As for the HTML email, please make sure that you are sending a 
comparable text/plain MIME part and not just text/html.


Don't encode / obfuscate anything that doesn't have a specific need to 
do so.  If there is a need, seriously consider if you can change that 
need.  This goes for being both transparent and clear on what you are 
doing and why you are doing it.




--
Grant. . . .


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Correct way to allowlist an IP from DNSBL checks when it's not the final Received?

[Grant Taylor via users]

On 9/27/23 2:15 PM, Andy Smith wrote:

Hi,


Hi,


The IP address of a supplier is currently listed by Spamhaus
SBL-CSS.


Oops.


How would I go about allowlisting this IP address against DNSBL
hits? Ideally for a specified range of from addresses and/or
envelope senders, but for every sender if necessary. I think I would
be okay with exempting such an IP address from *all* negative DNSBL
hits, at least temporarily.


I'm not sure what the SpamAssassin approved method is.

But I suspect that you could play some DNS games to make the SBL lookup 
for 192.0.2.1 fail by monkeying with the 1.2.0.192.sbl.spamhaus.org 
query.  Either something like RPZ to make sure that the listed result 
never comes back or make it resolve to what you want it to resolve to.




--
Grant. . . .
unix || die

Re: OT - Re: DNFTEC - was My apologies

[Grant Taylor via users]

On 8/6/23 12:04 AM, David B Funk wrote:
For the most part they can be pretty much interchangeable but slight 
shading:


EC -> alignment: neutral/chaotic
T -> alignment: evil

IE an EC can be unpredictable and occasionally positive but at a cost
T is pretty predictability undesirable


Ah ha!

That makes perfect sense to me.

Thank you for helping me understand Dave.



Grant. . . .

Re: OT - Re: DNFTEC - was My apologies

[Grant Taylor via users]

On 8/5/23 6:42 PM, Martin Gregorie wrote:

Yes given that he is


Sorry, I as asking for differences between Energy Creatures and Trolls.

I agree with your advice about the particular EC / T.

I'm still trying to understand the conceptual difference between an EC 
and a T or if they are synonyms for the same type of individual.




--
Grant. . . .

OT - Re: DNFTEC - was My apologies

[Grant Taylor via users]

On 8/5/23 1:51 PM, Kevin A. McGrail wrote:
REDACTED is the definition of something I learned decades ago as an energy 
creature.


Is there anything to differentiate an Energy Creature from a Troll?

The tricky thing about this particular ${ENTITY} is that they are 
seemingly on topic and seem to have a significantly different opinion 
about something than their target.


As such, it's too easy for a target to be drawn into what they probably 
initially think as a legitimate technical discussion with someone of a 
differing opinion or different experience.


I personally think that it is good to understand differing opinions / 
experiences.  I find that when I take the time to understand them, even 
if I don't agree with them, that I usually end up learning something, 
often reconfirming my opinion, but sometimes showing me that there might 
be a better way, or at least something that warrants further 
investigation / learning.


So, open minded people like myself seem to be easier prey for an 
${ENTITY} like you describe.


DNFTEC is an acronym to live by.  Suggested reading: 
http://www.cryonet.org/cgi-bin/dsp.cgi?msg=6284


Intersting.

Copied here for other's convenience.

--8<--
Q: SOME PERSON HAS POSTED SOMETHING REALLY RUDE IN RESPONSE TO ME, OR IS 
PICKING ON ME.  WHAT DO I DO?


A: There is a certain type of being that's all too common in the online 
world.  I call them "Energy Creatures," a term I first heard on one of 
the commercial services.  Energy Creatures are a bizarre lifeform which 
grow and feed off of the negative energy generated by others.


Energy Creatures' favorite feeding tactic is to try to hurt people's 
feelings or get them angry.  Then they can feed off the pain and anger 
they've generated. Their second favorite tactic is to hurt one person or 
group's feelings while gathering the sympathy of others.  That way, when 
the injured party lashes back, others will jump to the Energy Creature's 
defense.  Then the Energy Creature need do nothing except feed off the 
attention and the negative energy generated by the people fighting.


We'll never be completely rid of these noxious beings, but we can do a 
lot to keep the herds under control by remembering this simple formula: 
DNFTEC.  This stands for Do Not Feed The Energy Creature. If you 
encounter such a beast, your best bet is usually to say absolutely 
nothing.  No matter how hard it is, sitting on your fingers and posting 
NOTHING in response is usually the best bet.


Remember, if you fight them, they just get stronger.  If you ignore 
them, eventually they weaken, wither, and go away.  This may be hard to 
remember, but in the long run, that's exactly what you need to do.  The 
temptation to fight back is incredible, but remember, fighting them only 
makes them stronger. Believe it.

-->8--



--
Grant. . . .

PSA: ${HE} is now using a new email address.

[Grant Taylor via users]

On 8/5/23 12:23 PM, Grant Taylor via users wrote:
The catch is that he keeps tripping up people that have not had the ... 
experience of dealing with him and thus have not ... quieted him yet.


For those of you that have started filtering someone --  who I'm not 
going to name -- ${HE} has started using a Gmail address that is his 
first name dot his last name at gmail dot com.




Grant. . . .

Re: My apologies

[Grant Taylor via users]

On 8/5/23 8:04 AM, Ralph Seichter wrote:
Well, that is what local mail killfiles are for. The world is sadly 
full of morons, but one does not necessarily have to accept mail 
from them.


Agreed.

The catch is that he keeps tripping up people that have not had the ... 
experience of dealing with him and thus have not ... quieted him yet.




Grant. . . .

Re: My apologies

[Grant Taylor via users]

Having myself been through what Thomas is appologizing for, I have some 
comments on what Reindl H. is doing.


On 8/3/23 3:06 PM, Ken D'Ambrosio wrote:

I ... think he should be blocked.


He /is/ blocked from from sending messages to / through the mailing list.

I've been online for over 40 years, and it's rare to have someone so 
actively hostile right out of the gate


Here's the thing.  He is sending his reply /around/ the list -- 
apparently -- so that it looks like his messages came from the list.


So his behavior is -- in my opinion -- both hostile and deceptive.

I admit, it made me worried what kind of environment was fostered 
on the Spamassassin list when I asked my newbie question, and was 
outright mocked by him.


I think that reaction is perfectly understandable.

I'm sorry that someone made you feel that way about the SpamAssassin 
users mailing list / community.


I hope that you realize that he is in the minority and doesn't speak for 
the vast majority of us.


And so, while I have zero sway as a team member or anything like that, 
as a newbie mailing list member, looking for help, I humbly submit 
that he's not someone you want being the first interaction a new list 
member has.


Agreed.


$.02, YMMV, etc.


:-)



Grant. . . .

Re: Ensuring SPF/DKIM for @gmail.com

[Grant Taylor via users]

On 7/27/23 6:25 AM, Matus UHLAR - fantomas wrote:
I use spamass-milter on my system and amavisd-milter on other systems 
especially to be able to reject spam at SMTP time. Definitely a good thing.


:-)

You just should not use it for "outgoing" mail from your clients, so 
they don't complain about sending mail taking ages.


Eh 

I'm an advocate for spam filtering all email coming into the server, 
even email coming into the MSA on it's way out to another server across 
the Big Bad Internet.


You may need to limit SA processing to some 270 seconds to avoid 
5-minutes timeout (which contradicts RFC5321 section 4.5.3.2.6. which 
mandates 10-minute timeout on DATA termination, but here we are).


This is one of the reasons that I mentioned configuring the MSA with 
much longer timeouts in another recent thread (though I don't remember 
which list).


I have in the past configured an MSA to accept messages (with really 
long for email timeouts) and relay the messages through the local MTA 
where I applied the filtering that I'm talking about.


This allowed clients, even on dial up, to send larger email with 
attachments to not time out /and/ to be able to be filtered to avoid 
contributing to spam if (when) accounts were compromised.


Seeing as how the MUAs authenticated to the MSA to send, I have a very 
good idea who I needed to have a chat with in the event that something 
unsavory was making it through the MSA to the filtering MTA, or worse 
out to the Big Bad Internet.




Grant. . . .

Re: Ensuring SPF/DKIM for @gmail.com

[Grant Taylor via users]

On 7/26/23 7:20 PM, Matija Nalis wrote:

I'd appreciate more civil expressions of disagreement


+1


I personally know several people who still use procmail today, sooo...


+1

That at least I can attest is not always the case (I still see 
systems with custom sendmail.cf which nobody dares to touch, 
and with a good reason!)


Is said sendmail.cf based on a sendmail.mc file or is it older / bespoke?

Yeah, I agree that it sure would be nice if world worked that way and 
everybody upgraded regularly and configured them according to latest 
BCPs, but around here at least, it sometimes (I'm avoiding to say 
"often") doesn't.


I agree with following the latest BCPs *if* *reasonably* *possible* *to* 
*do* *so*.


But I don't agree with upgrading just because something is old, 
especially if it's still working.


After all, Ethernet is 50 (?) years old and TCP/IP is no spring chicken. 
 Yet we are still using them.


There are quite a few systems that someone knowledgable setup some 
time back, and after they've gone to greener pastures, nobody have 
touched them, yet they continue to use them.


Sometimes you find the diamond in the rough that knows how to care and 
feed said systems and does tweak them to abide by / support BCPs.



Sure, I'll be first to agree that it is bad and should be fixed.


What is the actual problem that /needs/ /to/ /be/ /fixed/?

Procmail can forward emails without re-writing the envelope if the MTA 
does the envelope re-writing for it.


Just because something is old and doesn't provide the latest and 
greatest feature doesn't mean that something else can't assist and 
provide said feature.


The complete solution needs to provide the features.  Not all features 
need to be provided by specific components.


Telnet over a VPN is perfectly fine especially if the destination 
doesn't support something better.


But I won't agree that "it does not exist", nor would I agree that it 
doesn't matter (if it didn't matter to them, people wouldn't be 
asking me to troubleshoot it, and yet they do)


#truth +1

Good for you. But that is anecdotal - you are certainly not participating 
in every mailing list in existence, nor do you contact all people on the 
planet which use every kind of mail forwarder.


Neither do I, but I service lots of systems of other people that do, 
and with many people, the chances rise. So, still in 2023, I have to 
deal with SPF (and DKIM) failing due to such forwarders/ML (as well 
as misconfigurations, of course)


+1

Also, 1990s? Weren't first SPF-alike ideas drafted first time in 
early-mid 2000s, and SPF itself not published as *proposed* IETF 
standard until 2014?


I was wondering, but I couldn't be bothered to look up the dates.  I 
think I started using SPF in the mid-2000s.  Maybe late 2000s.



That was less than a decade ago, barely yesterday :)


LOL



Grant. . . .

Re: Ensuring SPF/DKIM for @gmail.com

[Grant Taylor via users]

On 7/26/23 2:09 PM, Matija Nalis wrote:
Only way to make SPF never incorrectly fail/softwail is to use "+all", 
but that kind of kills its point :-)


I question the veracity of that.

Is SPF failing to perform it's intended function if an unauthorized 
server is blocked from sending email with an envelope from a domain with 
an SPF record ending in "-all"?


I'll defend that SPF is doing exactly what it was designed to do.

I'll agree that some people may be surprised at the message being 
blocked.  But that's a failure of the users understanding of SPF, and 
not a failure of SPF itself.


It may be a bad configuration / SPF record, but again, that's not a 
failure of SPF to do what it was designed to do.



(actually, even with +all, some sites will fail it - especially
because of it, as +all is sign of either intentional sloppy spammer
or incompetent postmaster, both likely leading to spam coming from
that site).


That is a receiving site applying local policy to override what the 
purported sending site has published.  --  I don't care how many 
receiving sites apply that mentality.  It is still contrary to what the 
purported sending site published.



Any SPF, no matter how correctly configured, will lead to false
positives in some cases (e.g. encoutering mailing list or .forward
not using VERP/SRS).


Is that /truly/ a false positive?  Or did SPF function the way that it 
was designed and configured?  I believe that it did.


I recently helped someone set up SPF for a new domain.  It was working 
fine for a few weeks until they tried to use a 3rd party service to send 
email on their behalf.  I said that's new information and we need to 
update SPF to authorize the 3rd party to send email on their behalf.


Did SPF fail?  Nope.  SPF did exactly what it was designed to do.  The 
user changed what they wanted and needed to update their SPF record 
accordingly.


SPF didn't fail.  The user failed to make a change ahead of time.


It is inherit in the SPF protocol (which is why
DMARC checks both DKIM and SPF, in order to reduce, but not
eliminate, false positives).


DMARC is applying local policy and deciding to ignore the information 
that SPF successfully provided.


Providing unfavorable information is not a failure to provide information.


We are NOT living in ideal world where everybody implements every
existing standard.


Agreed.

But we can strive for the ideal world.  By doing so we will end up 
closer to the ideal world than where we started, even if we fall short 
thereof.



Thus, even most correctly configured SPF will
sometimes softfail/fail, when it should not.


I question the veracity of "should not".



Grant. . . .

Re: Ensuring SPF/DKIM for @gmail.com

[Grant Taylor via users]

On 7/26/23 1:44 PM, Marc wrote:

so your ip does not generate a softfail or fail


I assume that you mean so that your outbound SMTP server is actually 
authorized in some capacity and fall under "all".  Is that correct?



When you configure your spf your result is either pass, softfail or fail
I think we can agree that a correctly configured spf results in a pass,
don't you?


I agree that known and authorized sources of email for my domain are 
authorized in the SPF record for my domain.


I thought you were alluding to a particular value of "all".  I did not 
understand your statement to be about servers being authorized or not.


I've had a number of conversations with people of late that seem to 
dislike "-all" almost as much as others dislike "+all".




Grant. . . .

Re: Ensuring SPF/DKIM for @gmail.com

[Grant Taylor via users]

On 7/26/23 2:34 AM, Benny Pedersen wrote:

milters should not be spam scanners, spamassassin is better


{spamass-milter,milter-spamc} combined with SpamAssassin cause me to 
question the veracity of that statement.


Milter implies doing the filtering during the SMTP transaction.  I 
consider the ability to reject messages that SpamAssassin declares as 
(bad enough) spam at SMTP time to be a good thing.


maybe use bind9 rpz to change spf data for stupid domains, mostly 
freemail domains in this category ? :)


Will you provide a description of what you would have an RPZ do?

I know that you can specify local data overriding the upstream DNS zone 
data.


All of the local data would be locally and artificially baked.  I guess 
you could do some sort of query and create a fresh RPZ record with a 
different "all" value.  Or are you thinking something else?


This might be a use case for RPS to more dynamically alter the record. 
But I've not messed with RPS much.  Conversely I've done a lot with RPZ.




Grant. . . .

Re: Ensuring SPF/DKIM for @gmail.com

[Grant Taylor via users]

On 7/26/23 1:44 AM, Marc wrote:

asking them to correctly setup spf is mostly enough.


At the risk of starting a flame war...

What does "correctly setup SPF" mean to you?

What makes your opinion better than someone else's opinion that differs? 
 (I take it for granted that someone will have a differing opinion.)


I get your server your rules.  But your server / your rules doesn't 
translate to someone else's server any more than someone else's rules 
translate to your server.




Grant. . . .

Re: Sudden surge in spam appearing to come from my email address

[Grant Taylor via users]

On 7/17/23 6:07 PM, Reindl Harald wrote:
because we have 2023 and in the last decade everybod with a brain was 
using spf and sender-spoofing-rejection fro envelopes


I wish that was the case.

There was a recommendation on mailop less than a week ago that people 
only set up SPF records to appease Google and the person recommending 
this actively discouraged doing any filtering on SPF.


IMHO there are too many people not utilizing SPF / 
sender-spoofing-rejection for envelopes.



we can agree that fools are doing foolish things


Can we agree that Google states that DKIM is sufficient to send email to 
them?


and? this idiotic nitpicking leads nowhere and in the real world SPF is 
way easier to setup and maintain


I've seen too many people nay saying / lamenting / poo pooing SPF. 
People on mailing lists like mailop / and various IETF mailing lists.


In the last month, of 2023, I've seen multiple people suggest:
 - that SPF should not be done
 - that you should publish a record but not filter on SPF
 - to publish questionable / soft SPF records; "~all" / "?all", or 
$DEITY forbid "+all"

 - ignore the result of the SPF test and filter on something else


but that's not the topic

the topic is you pretend mailing lists are using subsribers 
envelope-from in 2023


I'm not pretending.  I have seen mailing lists in the last year send 
messages using subscribers email address in the RFC5321.MailFrom 
envelope address.  -  I don't have any examples handy.



oh - they have  been changed - guess why!


I know why the ones that have changed have done so.  But there are still 
a small number that haven't yet changed.


the topic is you pretend mailing lists are using subsribers 
envelope-from in 2023


Believe me or don't.  I still see a small number of mailing lists 
sending messages with subscribers addresses as the RFC5321.MailFrom in 2023.


These types of messages will be filtered by the recommendation to reject 
any local recipient address as the RFC5321.MailFrom envelope address 
mentioned earlier in thread.



for a mail you send today it's irrelevant what was state of play in 2010


I'm talking about 2023, not 2010.

I don't remember which thread on which mailing list, but within the last 
week I saw multiple people saying that services doing forwarding should 
not rewrite sender addresses and that it was the downstream recipient's 
system's fault for rejecting the message for -- what they considered to 
be -- silly things like SPF failure.


Yes, it is 2023 and yes there are people / mailing lists / MTAs / 
organizations trying -- and largely failing -- to re-send messages using 
the inbound RFC5321.MailFrom envelope address.


I say this so that people can make an informed decision.  Despite all 
the recommendations to the contrary, people still run with scissors in 
hand and run at the pool.  Very bad ideas still happen.




Grant. . . .

Re: Sudden surge in spam appearing to come from my email address

[Grant Taylor via users]

On 7/17/23 4:49 PM, Reindl Harald wrote:

Alias expansion does this


is not a mailing list


What definition are you using for a mailing list?

Do you consider Majordomo to be a mailing list?

Because as far as I'm concerned, alias expansion in the MTA is where 
mailing lists originated.


in the real world i was subsribed the past 15-20 years to at least 30 
mailing-lists


That's all?

I still have email for more than 200 different mailing lists that I've 
been subscribed to over the last 20 years.



* not a single one used the senders envelope - period


I've seen way too many use the sender's envelope.  Thankfully it's not 
nearly as common in the last decade as it was before.



* we have 2023 - period



* you can't send to gmailif you don't have SPF - period


I've had SPF for much longer than Gmail wanted it or DKIM.

But it is my understanding that you can send to Gmail with just DKIM.

I hope that we can agree that simply having an SPF record isn't 
necessarily the same as using SPF; "ip4:0/0" and / or "+all" isn't 
really having SPF.


and yes i get sick an tired from customers don't hosting mail on our 
servers with complaints of rejected mails to gmail users quoting the 
following:


host gmail-smtp-in.l.google.com[74.125.133.26] said:
550-5.7.26 This mail is unauthenticated, which poses a security risk to the
550-5.7.26 sender and Gmail users, and has been blocked. The sender must
550-5.7.26 authenticate with at least one of SPF or DKIM. For this message,
550-5.7.26 DKIM checks did not pass and SPF check for


There you go; "at least one of SPF or DKIM".  So by Google's own 
message, you can send to them without SPF /if/ you have DKIM.



in the past 15 years?
name them!


I don't remember the exact mailing lists, it was 5-10 years ago.  They 
have since changed.


It was multiple lists with an organization that I think should have 
known better.  The IETF comes to mind.




Grant. . . .

Re: Sudden surge in spam appearing to come from my email address

[Grant Taylor via users]

On 7/17/23 4:29 PM, Reindl Harald wrote:

no single mailing-list on this planet does this - period


Can we agree to disagree?

Maybe no /contemporary/ mailing list.  But there have been -- and I 
contend still are -- LOTS of mailing lists that did / do this very thing.


.forward does this.
Alias expansion does this.
Mailman 2.x used to do this by default.

I've seen multiple mailing lists sate that they will unsubscribe people 
if they send email from a domain with strict SPF settings because they 
refuse to deal with altering the RFC5321.MailFrom envelope address.


You only need to look as far as mailing lists getting tripped by SPF.

If the mailing lists weren't re-using the RFC5321.MailFrom from the 
incoming message in the message that they send out, there wouldn't be a 
problem.  Yet there have been many GB of email written about this very 
problem.


DMARC/DKIM are problematic for mailing-lists but 
envelope-ender/spf/spoofing-protecting is a no-brainer


I take it that you are in favor of the mailing list sending outgoing 
messages using an RFC5321.MailFrom envelope sender that is different 
than the the incoming message's RFC5321.MailFrom envelope sender.


Before VERP and SPF it was very common for mailing lists to send 
outgoing messages with the same RFC5321.MailFrom as the incoming message 
had.


it's time to understand the difference between from-header and 
envelope-sender or for the sake of god stop operating public mailservers 
at all


Yet there are people that don't know the difference.



Grant. . . .

Re: Sudden surge in spam appearing to come from my email address

[Grant Taylor via users]

On 7/16/23 5:57 PM, Benny Pedersen wrote:

why accept local envelope SENDER domains on port 25 ?


Do you subscribe to any mailing lists that don't rewrite the sender? 
Thus your mail server would receive messages that you sent to the 
mailing list as your SENDING domain on port 25 inbound from the world.


That's just the first example of why this -- let's go with -- workaround 
-- I'm being polite -- will work most, but not all of the time.


This starts to become a problem when you have multiple servers working 
cooperatively and communicating over port 25.  --  I remember tell of 
having email cascade through multiple Exchange servers for various 
questionable reasons.



its safe to reject them


I would not bet on it.



Grant. . . .

Re: Sudden surge in spam appearing to come from my email address

[Grant Taylor via users]

On 7/16/23 12:41 AM, Matija Nalis wrote:
So, it fails SPF, but DKIM passes. Meaning, your mail would pass 
normally modern servers which check both.


That is predicated on the receiving server(s) not rejecting the message 
for SPF failure.


You probably might want to use some nice frontend to visualizing 
DMARC results, if reading XML and SPF/DKIM/DMARC protocol internals 
is not second nature for you. e.g. 
https://github.com/topics/dmarc-reports


Thank you for sharing the pointer to that front end.

If mailing list is employing SRS, mail reaching final recipients 
would not be failing SPF checkes, as envelope sender (i.e. SMTP's 
"MAIL FROM: ") would be rewritten as the mail is coming from 
mailing list domain and their servers (as it would), not yours.


See https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme


+1 for SRS (like behavior)

Only if the mailing list remailing server leaves original (your) 
envelope sender (which it shouldn't be doing, yet often does), would 
you get such SPF problems. So, SPF problem is solvable from mailing 
list server side, if its admins are willing.


I've found that many, if not most, but definitely not all, mailing list 
administrators are willing to make changes if they are aware of the 
problem, know how to make the change, and have access to make said change.


Sadly, there are a few mailing lists that I'm on that are quite aware of 
the problem but have decided to refuse to make the change and are in my 
opinion acting like ostriches and sticking their head in the sand.


Also, if your mails are signed by DKIM, and mailing list software is 
not rewriting signed headers nor body (as it shouldn't, but some 
mailing lists try to add annoying text to the bottom of messages 
like "to unsubscribe, do xyz", thus breaking both DKIM, S/MIME and 
PGP signatures), then your mail should pass DKIM checks too. So that 
problem is avoidable on mailing list server side too.


Yep.  Mailing lists and other similar forwarding services are the places 
that have the most influence of if things work well or not for the most 
people.


Should each and every sending subscriber make changes to their 
independent systems?  Or should the singular mailing list make changes 
in one place and help everybody?


Simple energy conservation seems to indicate changes in fewest places is 
better.




Grant. . . .

Re: Sudden surge in spam appearing to come from my email address

[Grant Taylor via users]

On 7/16/23 9:37 AM, Thomas Cameron wrote:

It does clarify, ...


:-)


... but unfortunately, it doesn't alleviate my concerns.


:-/


I totally understand why SPF et al. are good ideas.


:-)

But I swear, I feel 
like they introduce darned near as many problems as they "solve."


I question the veracity of that statement.

Specifically is SPF /introducing/ a *new* problem?  Or is SPF 
/highlighting/ an *existing* problem?


It sounds to me like:
1)  you really do want to detect (and prevent) other servers from 
sending email w/ an RFC5321.MailFrom address in your domain.
2)  you want messages send to be able to be resent by specific other 
servers.


IM(ns)HO #2 is in conflict with, if not diametrically opposed to, #1.

If other servers, like mailing lists, didn't send messages using your 
RFC5321.MailFrom address, then this wouldn't be a problem.


Who's really doing the wrong thing here?  You specifying you want 
stringent email security or someone else pretending to be you?



But that's another rant. Thanks for your explanations.


Maybe.



Grant. . . .

Re: Sudden surge in spam appearing to come from my email address

[Grant Taylor via users]

On 7/15/23 10:04 PM, Thomas Cameron wrote:

I'd love to do this, but see below. I get TONS of warnings every
time I send email to lists (even this list) that make me hesitant to
do hard fails.

I understand and appreciate what you're describing.


I do, as well, but mailing lists outside of my sphere of influence.
I can't very well dictate to mailing list admins that they change the
way they do things. Even the earlier email I sent to this list
generated a bunch of warning messages. One of many:


You can't dictate.  But you can ask.

I'd almost guarantee that you wouldn't be the first bringing this to 
their attention.



It's not so much mailing list operators I'm worried about. It's
that, when my email goes through a listserv mailing list, if I define
hard failures, I am worried that my email isn't going to get to list
members.


Yes, that is a risk.

But ...


That's not the mailing list admin, it's the admins of the
list members' mail servers.


... if you stop and think about it, SPF is doing exactly what it's 
designed to do.  The servers that receive messages from the list are 
detecting your domain in the 5322.MailFrom, identifying that the sending 
IP isn't authorized, and acting accordingly.


I'd argue that's exactly what is supposed to happen.

So who's doing something wrong?  The receiving mail server who's acting 
according to your published wishes or the server that is sending 
contrary to your published wishes?



If I'm not understanding something, please feel free to clarify.

Does that help clarify (my opinion)?



Grant. . . .

Re: Sudden surge in spam appearing to come from my email address

[Grant Taylor via users]

On 7/15/23 2:00 AM, Reindl Harald wrote:

SPF don't care about the visible From-header


I agree that SPF doesn't (SHOULDN'T) care about the RFC522.From header.

However my experience has been that the vast majority of messages that 
are spoofing the RFC522.From header are also spoofing the 
RFC521.MailFrom which is squarely in SPF's domain.


Think of it as -- based on my experience -- a VERY STRONG but indirect 
correlation.




Grant. . . .

Re: Sudden surge in spam appearing to come from my email address

[Grant Taylor via users]

On 7/14/23 6:06 PM, Thomas Cameron wrote:
I'm trying to figure out how to block this stuff. Something like "if 
it appears to come from me, but it's not actually coming from my 
email server," block it.


SPF with hard fail in your own domain /and/ filtering that respects SPF 
hard fail will almost certainly stop this like a switch.


On 7/14/23 7:28 PM, Thomas Cameron wrote:
But because I use several mailing lists, I do not have a hard fail 
set up. I get SO many notices when I send email to lists that I'm really 
worried about defining hard failures/rejections.


I consider that to be a failure on the mailing list's part.

Mailing lists can't successfully operate like they did 25+ years ago.


But I'll play around with what you suggested.


+10 for SPF.

+1 for encouraging mailing list operators to get with the times.

You can also do as Robert suggests and use a separate (sub)domain for 
mailing lists with different SPF settings thereon.




Grant. . . .

Re: Espoofer - An Email Spoofing Testing Tool That Aims To Bypass SPF/DKIM/DMARC And Forge DKIM Signatures

[Grant Taylor via users]

On 12/28/22 10:32 AM, Greg Troxel wrote:
It would be great if someone(tm) went through the blackhat pdf and 
wrote rules for all the evasions, and fixed the MTAs etc.


I have seen and heard discussion about the raft number of bugs fixed 30 
- 90 days after the annual Blackhat / Pwn2Own conferences.


It's not detection rules, but it is security fixes based on questionable 
research.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Espoofer - An Email Spoofing Testing Tool That Aims To Bypass SPF/DKIM/DMARC And Forge DKIM Signatures

[Grant Taylor via users]

On 12/28/22 6:17 AM, Kevin A. McGrail wrote:
Sigh.  Yet another borderline ethical posting / tool like far too many 
pentesters who think transparency is the ultimate way to move the needle 
of security

Many tools can be used for both good and evil.

I have yet to find a kitchen knife that can tell the difference, much 
less behave differently when cutting bread vs the human operator.


SATAN, SARA, cops, crack, firesheep, metasploit, nmap, et al. come to 
mind as tools used to help identify weaknesses in security / defenses. 
It seems like Espoofer is yet another in a long line of such tools.


I will read about Espoofer, what it does, and how it does it in the 
spirit of securing my systems.  I think that any such information has 
some value.


If nothing else, know they enemy.

while thinly veiling their search for love and attention that their 
mother didn't give them.


I see no need for the (minor) ad hominem attack and I don't think it 
brings anything to the conversation.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Facepalm

[Grant Taylor via users]

I am terribly sorry.

I accidentally forwarded one (or more) messages to the SpamAssassin mailing 
list which I meant to forward to SpamCop. High-latency remote control, address 
prefix collision, and lack of sleep are contributing factors.

I will update address books to reduce likelihood of collisions in the future.

To those that asked if I was mentally ill, I don’t think so. Rather I think 
this was an honest mistake. All be it one with considerable egg on my face.  
Also, please reframe from as hominem attacks as they are unnecessary.



-- 
Grant. . . .
unix || die

smime.p7s
Description: S/MIME cryptographic signature

Fwd: #1 Secret to PERFECT Blood Sugar

[Grant Taylor via users]

--
Grant. . . .
unix || die
--- Begin Message ---
 
If you’re never to get an email from me
click 
here:https://click.superiorbrainhealth.net/?t=u&schedule_campaign_id=NzA0Ng%3D%3D&subscriber_id=MTYwNjg3OTQ%3D&ids=MjYw__MjY1MTU1MzY3__NDY4
 and say goodbye forever :-(

-

Have you heard about this WEIRD METABOLISM “RESET
BUTTON” discovered by a famous Harvard doctor?

A recent study on 3 men showed how hitting this hidden button in your
body restores PERFECT BLOOD SUGAR. And clinical studies confirm how
it starts working IN AS LITTLE AS 7 DAYS.

https://click.superiorbrainhealth.net/?t=c&ids=MjY1MTU1MzY3__NzA0Ng%3D%3D__MTYwNjg3OTQ%3D__NDY4__260/aHR0cHM6Ly9lbWRsdnIuY29tL3RhbXI%3D

It may sound too good to be true, but you can actually do it
yourself IN JUST 30 SECONDS A DAY.

Click here to discover how it 
works.:https://click.superiorbrainhealth.net/?t=c&ids=MjY1MTU1MzY3__NzA0Ng%3D%3D__MTYwNjg3OTQ%3D__NDY4__260/aHR0cHM6Ly9lbWRsdnIuY29tL3RhbXI%3D

If you have blood sugar concerns, you could even be eligible to try it
for yourself now.

Find out how 
here.:https://click.superiorbrainhealth.net/?t=c&ids=MjY1MTU1MzY3__NzA0Ng%3D%3D__MTYwNjg3OTQ%3D__NDY4__260/aHR0cHM6Ly9lbWRsdnIuY29tL3RhbXI%3D

 

 

 

 

 

 

  
-

We sent this email! This e-mail was sent to your email
address focusatw...@gtaylor.tnetconsulting.net because you requested one of our
quizzes, purchased one of our exercise, diet, or health plans from
NaturalHealthyNews, 164 Norma Lane Shreveport |  Louisiana |
71101​. If you want to update your account or unsubscribe from
future emails you can do so below. If you chose to unsubscribe, just
know that you won't be receiving any more valuable health and
nutrition info from us. So make sure about unsubscribing.
 
1-Click 
Unsubscribe:https://click.superiorbrainhealth.net/?t=u&schedule_campaign_id=NzA0Ng%3D%3D&subscriber_id=MTYwNjg3OTQ%3D&ids=MjYw__MjY1MTU1MzY3__NDY4
 
--- End Message ---


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Gmail confidential mode

[Grant Taylor via users]

On 11/17/22 10:13 PM, Dave Warren wrote:
This isn't e-mail, it's a hosted text document and a link sent by email. 
It is functionally the same as putting something on a (vaguely) private 
PasteBin and telling your recipient where to go look at it.


Agreed.

I have read about some email encryption methods that do send the 
encrypted message but don't provide the key with the cipher text. 
Rather the client has to get the key from the sender (or their host) 
upon disposition.


This is germane as it means that the sender can refuse to give out the 
key after a certain point.  Thereby expiring the encrypted message 
contents.  (Assuming that the message encryption is sufficiently 
advanced that it effectively can't be read without the key.)


N.B. message expiry is subject to the recipient saving the key for later 
re-use and / or screen shot and / or over the shoulder security holes.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: spam subject marking

[Grant Taylor via users]

On 11/17/22 9:00 AM, Bill Cole wrote:

Easier said than done.


It's actually quite easy to do.  But most people don't want to do what I 
think should be done.


IMHO, the email list itself is a 1st class / proper entity that you are 
emailing or reading email from.  --  I'm not emailing Bill or Greg or 
Marc or any specific individual when I type this reply.


Treat the mailing list as an individual that receives / reads / types / 
sends email messages.  The mailing list is an SMTP terminal point.  It 
is the end exclusive or the start of a message.


The new messages that it generates may be substantially based on content 
in messages that it received.  But that's still a new message.


As such, messages from the mailing list should reflect the mailing list 
and not pretend or lie or fudge or fake that they are anyone else.


But that's my opinion and it's an unpopular one.  But it's also one that 
is completely 100% compatible with SPF / DKIM / DMARC / etc.  (Assuming 
that the mailing list / it's MTA apply said security to the new messages 
that it originates.)




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: spam subject marking

[Grant Taylor via users]

On 11/16/22 4:46 AM, Greg Troxel wrote:

Can you expand on that?


I'll try.

My understanding is that few MUAs test DKIM signatures /client/ /side/. 
--  The only exception that I'm aware of is that there was a Thunderbird 
add-on that would test DKIM signatures /client/ /side/.  Almost all DKIM 
/testing/ / /checking/ that I'm aware of is /receiving/ MTA side.


A DKIM failure means that one can't establish that the message came 
from the domain, and this leads to:


Sure.


   decline to apply whitelist_from_dkim

   perhaps, if one has data that most things with that From: have valid 
dkim sigs, give it some spam points.


My understanding is that /per/ /RFCs/ a failing DKIM signature is to be 
treated the same as if there is no DKIM signature.


Or said another way, DKIM is only supposed to be a /positive/ 
/assertion/ if / when a DKIM signature validation passes.  DKIM is 
supposed to not be negative.


Please correct me if I'm wrong.


in spam filtering and

   if there is a DMARC policy, and it fails SPF also, file as spam 
or reject


N.B. DMARC is vastly different from, but still potentially reliant upon 
DKIM.


Are you saying tht some MTAs outright reject on DKIM failure, in the 
absence of DMARC?


I have seen evidence of postmasters /mis/configuring their MTAs to 
behave the /opposite/ /of/ /what/ /RFCs/ /prescribe/.


I did just get a bounce message in reply to a message I sent here, 
complaining that my message failed DKIM (maybe the list munged it) 
and SPF (ok; the list is not in general authorized to send mail from 
my domain) and therefore was being rejected (but I do not currently 
publish a DMARC policy).


I'm not getting on my what mailing list managers should and should not 
do horse in this email.  ;-)


Not really this topic, but I think mailing lists really need to be 
set up to not break DKIM.


TL;DR:  I believe that mailing list managers are an email terminus; end 
of my message and the start of a new message substantively based on my 
message.



The kids all want us to use forums anyway,


It's healthy to want things.  It's an indication that you have opinions 
and are not a sheepeople.



and DKIM-breaking and spam filtering issues, really doesn't help.


I've found that when both email terminus (termini?) behave properly, 
DKIM is not an issue.  At worst, a failing DKIM signature is treated as 
if the DKIM signature doesn't exist.  At best, a passing DKIM signature 
adds credence to a message / it's source.


Agreed.  Really the MUA needs support for a spam-marking 
header, or to file messages with such headers into a separate 
mailbox/folder/whatever.


I would assume that any contemporary MUA worth it's disk space does, and 
has for 10-15 years, understands various spam filter headers asserting 
status.  E.g. Thunderbird has built in support for SpamAssassin, 
Bogofilter, DSPAM, POPFile, and SpamPal.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: spam subject marking

[Grant Taylor via users]

On 11/15/22 1:16 PM, Marc wrote:
Hmmm, good point, not really thought about this even. Are email 
clients complaining about this?


Few email clients are testing DKIM.  Some servers are testing DKIM. 
Some systems are mis-treating DKIM failure as something more sever than 
the specification allows.


So the alternative is adding a header and move it to the spam folder 
automatically on the basis of the header?


Adding the header, yes.

Altering where the message is delivered is completely independent and 
outside of SpamAssassin purview.


Currently I just want to 'warn' users that the message is possible 
spam, they can decide to move such emails automatically to a spam 
folder by enabling a sieve rule.


I suspect any visible modification you make to the message will also 
likely break DKIM in the same way.


You can attach the unmodified message to a wrapper message, and add 
whatever text you want in the wrapper message.  This is an exercise left 
up to the reader.  ;-)


What would be an alternative method to keep such functionality without 
altering the subject?


Adding headers is the most common thing that I see.  Then let the email 
client decide what action, if any, to take based on that header's contents.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: How to incorporate network blocks

[Grant Taylor via users]

On 11/11/22 10:10 AM, Bill Cole wrote:

 From my bashrc...

# type cidrcon
cidrcon is a function
cidrcon ()
{
 for a in $*;
 do
 echo $a;
 done | perl -e "use Net::CIDR::Lite;  \$cidr = Net::CIDR::Lite->new(<>) ; \$_ = join 
(\"\n\",\$cidr->list) ; print \"\$_\n\";"
}


Oh ... (minimally) obfuscated Perl one liner.

N.B. My Perl is rusty.

Let's try deobfuscating and interpreting.


use Net::CIDR::Lite;


Load the Net::CIDR::Lite module.


$cidr = Net::CIDR::Lite->new(<>);


Instantiate an instance of the Net::CIDR::Lite module.

It also looks like you're reading from STDIN via "<>".  Is that correct?

I feel like that's a Perlish short cut to opening the STDIN.  I have 
almost always used an "open" statement for such.



$_ = join ("\n",$cidr->list);


Set the unnamed variable to the output of the list output from the 
Net::CIDR::Lite object using new lines.



print "$_\n";


Print the unnamed variable with a trailing new line.

I /think/.

Am I close?

Obviously requires Perl and the Net::CIDR::Lite module. I do not 
recall why the implementation is so weird, but I've been using it 
for decades(!?)


The deobfuscated code doesn't seem weird to me.

I suspect some of the weirdness comes from transforming it into a one 
liner and escaping things as necessary to pass it from shell to Perl.


I guess it may be a little weird that the cidrcon() shell function takes 
multiple parameters and prints each of them on a line to pass into Perl.


I wonder if it was easier / simpler to do -- what I call -- the rotation 
(from one line with multiple parameters to multiple lines with one 
parameter) in shell than to deal with them in Perl.


Thank you for sharing Bill.  --  Your message has been waiting for me to 
read, analyze, assimilate, and reply.  ;-)




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: How to incorporate network blocks

[Grant Taylor via users]

On 11/11/22 9:09 AM, Bert Van de Poel wrote:
- IP/CIDR lists like the one you mention, but also lists like Stop Forum 
Spam (https://www.stopforumspam.com/) I cron fetch then add to an ipset 
with a DROP (which is quite similar to what others are suggesting).


Stop Forum Spam seems interesting.

I'd be curious to see how you're converting SFS list(s) to ipset 
entries.  Mostly I've not yet had enough coffee to convert from a range 
of IPs; -, to CIDR; /.


I didn't pay close attention to the list, but I did see that it was 
range based and would need some conversion.  --  I have added it to my 
pile of things to look at more closely later.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: How to incorporate network blocks

[Grant Taylor via users]

On 11/10/22 9:54 AM, Joey J wrote:

Hello All,


Hi,

I'm trying to see if there is a way to incorporate network ranges into 
SA to essentially flag messages.


N.B. at least one of the lists below is individual IPs and not networks 
/ ranges of IPs.  --  I'm not sure how to square that peg with your 
wants / needs.


I know I can use iptables and reject it before getting to SA, but in 
some cases we would have legit email get flagged within these bigger blocks.


I would suggest investigating the other offerings from each vendor.  I 
suspect there is a good chance that many, if not all, of them offer a 
DNS based query method.


See Riccardo's comment about Spamhaus / Spamteq.


I'm trying to incorporate:
feeds.dshield.org/block.txt
spamhaus.org/drop/drop.lasso
ciarmy.com/list/ci-badguys.txt
openbl.org/lists/base.txt
Short of that, it wouldn't be hard to turn them into a locally hosted BL 
and then configure SpamAssassin to query it.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Gmail confidential mode

[Grant Taylor via users]

On 10/16/22 8:14 AM, Alex wrote:

Hi,


Hi,


What do you know about "Gmail confidential mode" emails?


Not much.

I'm starting to see a few of these come in to users now, and not 
sure how to treat them.


I think the /notification/ emails that Gmail sends for confidential 
messages are /probably/ benign.


My understanding is that the actual confidential message is retained on 
Google's system and that users navigate there using a web browser to see 
the confidential message.


As such, the /notification/ message that comes through your system is 
probably largely opaque.


They are sent through gmail, but require a one-time passcode sent 
to the recipient, so any potential threat is not transferred through 
the same email (or any email at all).


Yep.

So there's nothing that your filtering system will have to detect and 
react to.


IMHO this is no different than a "Come check out my new fancy website!" 
email linking to a web page laden with malware.  --  Eliding detection 
of suspect URLs.


The messages I've received were all tagged as spam due to bayes, but 
they otherwise have no other spam indicators.


I expect that the /notification/ emails will be fairly, if not quite, 
benign.


This doesn't appear to be anything new, but it's the first time I'm 
seeing it. Just thought I'd share and see if anyone had any input on how 
they're managing them.


:-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Supposed bounces

[Grant Taylor via users]

On 7/18/22 5:30 PM, Noel Butler wrote:
Which is a joke, because it does not, and qmails ezmlm has never 
included enough of the headers telling us _why_ we rejected it.


Your opinion of the notification doesn't change the intention behind the 
notification.


Most of the notifications that I see also include a message number which 
can be used to find the message in the archives.


At the very least they let you know that a message was rejected.

I can then go look at my MTAs logs and deduce why message(s) were 
rejected with more authority than anything the MLM could tell me.


But seriously folks, why the noise, its 3 years old (well mine was), get 
over it :)


The age of what prompted the discussion doesn't negate the discussion.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Supposed bounces

[Grant Taylor via users]

On 7/18/22 4:23 PM, @lbutlr wrote:

Don't know why this didn't go through.


chuckle

The copy with your comment /did/.  But I suppose the message that 
prompted you to make the comment didn't.



That is what it is SUPPOSED to be. What it actually is is something else.


Every version of what you describe that I've looked at has been the 
courtesy message.



Which is
1) three years old


Things happen.  Messages get stuck in queues.  Old queues get restored 
from backups.  Old systems are brought online prior to a wipe / 
recommission.  $THINGS



2) could not possibly have come from my mail server.


I would expect that a message that someone else sent to the mailing list 
which failed to send to you would not come from your server.



No, and I never said that.


My interpretation of your comment about not coming from your mail server 
suggested otherwise.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Supposed bounces

[Grant Taylor via users]

On 7/13/22 12:19 PM, @lbutlr wrote:
So, a supposed bounce from also three years ago. And that bounce 
did not come from my mail server as I have never run qmail. No IP 
addresses, no Received headers, nothing that could possibly be used 
to figure out what is going on here.


I think this is a courtesy message from the mailing list saying that a 
message that it tried to send to you was bounced.


It provides a copy of (part of) the message for your convenience.

Nothing about that implies that you sent the message that bounced. 
Instead it is extremely likely that you did not originate the message 
that bounced.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Attachment policy

[Grant Taylor]

On 6/27/22 2:50 PM, Alex wrote:

Hi,


Hi,

I'm looking for input from people on how they handle attachments, and 
people using email as a file transfer service.


My opinion is that you shouldn't rely on using email as a file transfer 
service until /after/ you've tested that it works.


One of our users must have posted to a job site recently, soliciting 
resumes from people internationally. This resulted in 100+ emails 
from random people who had never emailed this user before, many of 
which had no subject and no body, just a PDF attachment. Some had the 
"Sent by my iPhone" signatures, but that's about it. Virtually all 
of them were tagged as spam due to bayes.


>wince<

Any recommendations? There wasn't otherwise anything wrong with the 
attachments - they were all legitimate resumes from legitimate sources.


*nod*


Should they be blocked?


I don't think so.

By your own description, these seem like perfectly legitimate email. 
Admittedly the content was a little questionably formatted.


Should I retrain bayes to not consider these spam? I'm now training 
bayes with them as ham, but it will take a lot to offset these. Same 
with emails that only contain images.


I don't know what the /technical/ solution to this particular use case 
is.  However these messages /sound/ legitimate to me.


Should an email with only an image attachment with no subject and no 
body but sent from a legitimate source and otherwise not dangerous 
be considered spam?


These don't sound like spam to me.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Memory requirement for SpamAssassin/Postfix/Roundcube/Dovecot stack

[Grant Taylor]

On 5/27/22 12:59 AM, Sean Greenslade wrote:

You can quite confortably fit SA and a full SMTP + IMAP stack in less
than 1 GB. My (admittedly low volume) mail server is currently sitting
at 340 MB of used memory and is running:


Interesting.

Thank you for the counter point Sean.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Memory requirement for SpamAssassin/Postfix/Roundcube/Dovecot stack

[Grant Taylor]

On 5/26/22 8:32 AM, Ian Evans wrote:
Is it safe to assume that a $5/mth 1gig memory account will laugh at the 
resources needed to run a SpamAssassin/Postfix/Roundcube/Dovecot/Nginx 
stack and not ever break a sweat?


Sadly, I found that I needed to quit tilting at the 1GB memory windmill 
and upgraded my tiny VPSs to 2GB for SpamAssassin + ClamAV + some other 
milters.


You /might/ be able to get SpamAssassin in 1GB, but I don't know what 
else will be on the system.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: IPv6 issue

[Grant Taylor]

On 5/7/22 1:55 AM, Ted Mittelstaedt wrote:

I used to greylist and it helped a lot.


I used to use grey listing too.  I've found no listing to be equally 
effective.


2FA killed that, however.  When someone logs into a website, bank, 
etc quite often they use an email address as the second factor - 
so for that to work the email has to be delivered instantaneously. 
Also most 2FA does not follow any kind of SMTP standard, the will 
attempt delivery once and not retry if it fails.


No listing tends to benefit from this in that the sender is able to use 
the next server in line as soon as the sender can establish the 
connection fractions of a second later.


Once 2FA became a big deal for the banks I got far too many user 
complaints on the greylisting to keep it.


I've not knowingly had any problems with no listing like I used to have 
with grey listing.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: IPv6 issue

[Grant Taylor]

On 5/6/22 10:49 AM, Ted Mittelstaedt wrote:
Arg.  Well I think you hit the nail on the head.  And I think I may 
have stumbled on to a spam defeating trick.


Ya ... not running email server on IPv6 is a way of not receiving (some) 
spam.  But I view it very similarly as not running an email server 
period is another way of not receiving (all) spam.


It's a short term gain that has long term negative repercussions.

The problem for them is that if there is no response from that A record 
then normal TCPIP stack is going to wait for a while then eventually 
time out.


What you are describing is the premise behind "No Listing".  The two 
primary ways it's done is to 1) leverage TCP timeouts or 2) leverage a 
TCP Reset.  Either way, you're tickling bugs that alter behavior of spam 
cannons.  Things that proper SMTP servers handle much more gracefully, 
most without any problem at all.


I did not remove the  records because the IPv6 RFCs require that 
if the initial connection tried with IPv6 fails you retry with IPv4.


I would encourage you to not have your host's FQDN include a  record 
if it's not going to be utilizing it.  I'd instead suggest adding an 
alternate name with the (bogus)  record and reference that in MX 
records.



It is in effect a sort of tarpit I believe.


That's not tar pitting to me.  Tar pitting would be answering and 
replying extremely slowly.  Such that you burn a LOT of time for an 
established and arguably functioning (as in exchanging data) SMTP 
connection.  Like one character per second or every few seconds.


You could extend this to defining multiple nonexistent numbers for 
an IPv4 host except that DNS does not seem to have a way to force 
ordering of multiple IPv4s


DNS zone files don't have a way to force ordering.  Some DNS servers, 
BIND in particular, does have the ability to sort records.


Of course, spammers could get around this by recompiling their bots 
to use only IPv4.


You can apply No Listing to different IPs within a protocol and / or 
across protocols.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: using spamassassin to classify spam

[Grant Taylor]

On 3/24/22 5:00 PM, Michael Grant wrote:
List-Unsubscribe: 



I want to extract the mumble.aidemxwzlwt.bwbibibi.edu and run it 
through AskDNS and if I get an NXDOMAIN, I want to score it.


Remember, there are historic mechanisms for an MX for parent domains to 
handle child domains even if the child domain in question doesn't have 
it's own MX record.


I don't recall the current state of support for this, so don't rely on 
it without testing it.



Is it possible to do this within a cf file?


I don't know.  Someone else with more knowledge of SpamAssassin will 
need to speak to this.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Add header, not beginning with X?

[Grant Taylor]

On 2/14/22 1:18 PM, joea- lists wrote:
The reason has to do with "reply" and "reply to all" with the email 
client/system I am using and prefer to continue using for now.


To each their own.

Being subscribed to several lists, I find some variation between them 
regarding the headers they provide and how my "reply" feature works.


I've noticed similar.

Those that provide "Reply-to: somelist" act as expected and 
place the list address in the To: field.  Those that do not 
(users@spamassassin.apache.org included) find the address of the 
poster rather than the list in the To: field.


Ya.

While this is not a new issue, I do occasionally fail to correct the 
address issue and an email goes astray. '


Been there.  Done that.

I'm aware that "modern" clients can deal with this and there are more 
"practical" solutions, but I view this as an opportunity for "exercise" 
and perverse amusement.


I understand /why/ you might think that.

Does not appear to be something that can or should be done in SA, 
just exploring possible avenues, or, abandoning the idea completely.


However, I believe what you are wanting to do is outside of 
SpamAssassin's (et al.) preview.  Rather I think this is better done 
with something like procmail + formail.  SpamAssassin tends to be system 
wide while procmail + formail tends to be per-user.  And I suspect that 
what you're wanting to do definitely falls under the per-user end of 
that category.


I have implemented some procmail + formail rules to do very similar to 
what you are wanting to do.  One big difference is that I /usually/ 
*add* a List-Post: header and leverage my MUA's Reply to List 
functionality.  That way I am able to do a normal reply or reply to all 
and have the message go where the original author and / or mailing list 
administrator intended for it to go.  I say usually because I do use the 
same procmail + formail functionality to alter additional things in some 
very specific situations.  But all of this only applies to my user and 
definitely not system wide.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Avoid processing upsteam trusted mail with X-Spam-Flag: YES?

[Grant Taylor]

On 1/5/22 9:19 PM, Jered Floyd wrote:
Some of this mail gets forwarded to another organization (also partially 
under my control) which has a mailhub also running spamassassin.


I would like the downstream spamassassin to skip scanning on messages 
flagged as spam, rather than wrapping in another layer of SA (or 
deciding that the message is now ham after forwarding). ...


Is there a way to do this within Spamassassin config?


I don't know if it would work in your scenario or not, but it might work 
to have the upstream system send to the downstream mailhub on a 
different IP+port pair wherein SpamAssassin is not integrated.  In 
Sendmail, this could be as simple as an additional DaemonPort that 
doesn't include the InputMailFilter (milter) that's interfacing with 
SpamAssassin.


2) I can get a similar result by having my downstream MTA skip the 
spamassassin pipeline part for messages from the upstream mailhub 
(probably by establishing an authenticated alternate delivery port), but 
this is less ideal as it won't filter messages originating from the 
upstream organization (and not scanned) and also seems more brittle...


So ... you want /conditional/ filtering between the upstream and 
downstream mailhub.


Q:  Does the upstream MSA not do filtering of inbound messages from 
clients?  I would think that this filtering would cover messages 
originating from the upstream organization to the downstream organization.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Spamhaus Notice] Reminder of changes to the Spamhaus beta Domain Blocklist & request for feedback

[Grant Taylor]

On 12/15/21 1:00 PM, Riccardo Alfieri wrote:
We’d like to say a big “thank you” to all of you who have been testing 
the beta version of the Spamhaus Domain Blocklist (DBL) with hostnames.


:-)

You're welcome.  Thank you for making it available.

How are you getting on with it? Have you encountered issues? Are you 
noticing a reduction in false positives with the abused-legit component 
of the DBL? How’s the plug-in (with the recommended configuration 
changes) working for you?


If you could find the time to let us know we would really appreciate it.


I've noticed a small down turn in the amount of spam entering my 
personal systems.  My personal systems are small enough that I don't 
have good counters of before / after to share.


This means that if you have changed your plug-in config to test the beta 
DBL you will need to upgrade it to use the production DBL. An updated 
plug-in will be released on Jan 11^th , 2022.


Will free / non-commercial DQS subscribers need to do anything other 
than upgrading the plugin come January 11th?


Am I correct in assuming that you will be sending out notification(s) 
around the time you make the changes on January 11th?


We will continue to make the beta zone available for two weeks after 
the Production version of the blocklist goes live to provide time to 
ensure these config changes are made.


What will happen to the beta zone after the two week window?  Will it 
remain with increasingly stale data?  Will the zone be emptied to start 
answering as if nothing was listed?  Will it have a wildcard to start 
inducing false positives a la. fail hard / fail fast?  Again, just 
trying to set my expectations.


Thank you again.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Do these domains merit blocking?

[Grant Taylor]

On 12/15/21 9:39 AM, Bill Cole wrote:
There has recently been a spate of odd spams to harvested 
addresses asking hypothetical questions about domains' privacy 
practices. It turns out this is a grad student enrolling human 
subjects in a study without informed consent... The explanation is 
at https://measurement.cs.princeton.edu/privacystudy/ and there is a 
list of domains there which were created to run this maldesigned study.


Insert obligatory $Postmaster...Liberty...Filter...Discression message here.

I've added rejections for policy reasons to systems that I administer.

A customer has expressed mild dismay at the concept that a fine 
research institution should be "punished for doing research."


I want to support research.  But I can't stand research that takes a 
cavalier attitude because it's research.  To whit I saw some comments on 
another mailing list, mailop?, that indicated that the researcher 
admitted that s/he was sending the messages and the attitude was "so 
what".  I feel like the institution needs to be held accountable for this.


This is now (at least) the 2nd mailing list where I've seen this 
discussed and engineer hours are being consumed.  There are real world 
costs to the purported research.


So I say not on the systems that I administer.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Message-ID with IPv6 domain-literal

[Grant Taylor]

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.


"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.


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.


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.  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.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Message-ID with IPv6 domain-literal

[Grant Taylor]

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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Message-ID with IPv6 domain-literal

[Grant Taylor]

On 9/21/21 2:00 PM, Greg Troxel wrote:

You are missing that SA is not a standards conformance test suite.  It
is a tool to guess if a message is spam.   Bill said that some forms of
Message-ID are correlated with spamminess.   So whether the form that is
correlated is compliant to the spec or not is not a relevant question.


Fair enough.

Rupert's original question was about syntax, which seems to be more RFC 
based than convention applied by SpamAssassin.  This seems perfectly 
legitimate to me, just different than what I understood Rupert's 
question to be about.


Thank you for clarification.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Message-ID with IPv6 domain-literal

[Grant Taylor]

On 9/21/21 11:03 AM, Bill Cole wrote:
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.


Fair enough.  To each their own.

Private IP addresses in general cannot specify globally unique devices 
(consider 127.0.0.1 or the very-popular 192.168.1.1) ...


Agreed.  However, I don't think the non-uniqueness of the IP address 
actually matters.


... therefore a Message-ID using an IP literal as the RHS part with a 
non-public IP cannot assure uniqueness.


The use of a domain name or IP literal is RECOMMENDED, not even a 
SHOULD, much less MUST.


The thing that MUST be the case is that the message ID is unique.  So to 
me, it doesn't matter if multiple servers use the same IP literal (or 
domain name) as long as the entire message ID is universally / globally 
unique.


I am still not seeing anything beyond RECOMMENDED that states that the 
RHS of a message ID needs to have any form of uniqueness.  Hence why I 
think it's okay for multiple systems to have the same RHS.


Aside:  I agree that the RHS ideally is universally / globally unique to 
separate divide the message ID space such that it's per sending system.


I simply don't see any requirement for the RHS of the message ID to be 
unique.  In fact I only see a requirement for the message ID in it's 
entirety to be unique.


I guess this is a "spirit of the RFC" (RHS = unique) vs "letter of the 
RFC" (LHS + RHS = unique) type thing.


What am I missing?



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Message-ID with IPv6 domain-literal

[Grant Taylor]

On 9/21/21 7:09 AM, Rupert Gallagher wrote:
An unknown MUA (user agent header removed by sender) writes its 
Message-IDs as .


Ew.


Is the header syntactically corrext?


After looking at EBNF from RFC 5322 for 90 seconds, I /think/ that it is 
using obs-id-right syntax.  --  I say think because I see the left and 
right square brackets are part of domain-literal, which chains up to 
obs-id-right which itself chains up to message-id.  But I stopped at the 
dtext and didn't check to see if the colon character is allowed or not.


A custom SpamAssassin rule added a penalty for syntax error, and another 
for using a non-public address.


I get the penalty for the syntax error.

But why the penalty for using non-public addresses* in a Message-ID: string?

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?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Another evil number

[Grant Taylor]

On 6/25/21 1:12 PM, Bill Cole wrote:
There was also an old nomenclature system that mapped the local exchange 
prefix to 2 letters and a digit, with the 2 letters being an 
abbreviation of some word. For example, as a kid I had a "Parkview 1" 
number: 721-. Businesses would often put their numbers in print ads 


using those, e.g. PA1-1234. Parkview was not an actual place, but all 
the PAx exchanges in St. Louis were within a mile or two of Forest Park, 
i.e. people who might be able to have a view of the park from an 
adequately tall tree.


My understanding is the letters were (the first?) part of the phone 
switch / exchange name.  The following Wikipedia article supports this 
and has more details.


Link - Telephone exchange names - Wikipedia
 - https://en.wikipedia.org/wiki/Telephone_exchange_names



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Maybe it's time to revive EvilNumbers?

[Grant Taylor]

On 6/16/21 6:18 PM, Loren Wilton wrote:

Here are a handful of rules that work for me. Feel free to try them.
If you do, please let me know how they work for you.


Thank you Loren.  I'm marking your message for future use if these spam 
messages turn into a problem.



(Apologies for my mail client trashing the formatting.
Be sure to check for possible line wrap on some of the rules!)


*nod*nod*



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Maybe it's time to revive EvilNumbers?

[Grant Taylor]

On 6/15/21 10:11 AM, Mark London wrote:
My site is getting a lot of spam that is getting past spamassassin. 
Because it has a hone number to call, and rather than a link to login 
using username and password.   Mostly fake amazon purchases.   They are 
getting past a lot of URL block lists because of that.   FWIW. - Mark


I had one of these come in today.  Indeed a bogus apparent Amazon 
purchase, though I don't think it said Amazon, save for a graphic. 
Score was -0.9.  :-/  I'll save it for later to compare if I get more of 
them.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: all_spam_to

[Grant Taylor]

On 6/3/21 6:36 AM, Benny Pedersen wrote:

this change score with default -100 even for spammy msgs


This is a very critical point to me.

1)  it's not *all* spam.  It's spam with a score of up to 100+whatever 
cut off you're using.
2)  SpamAssassin still does it's spam processing.  Meaning it's not a 
way to skip spam checking for particular recipients.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: "Please send us a quote..."?

[Grant Taylor]

On 4/6/21 6:38 PM, Charles Sprickman wrote:
Not totally clear on the scam as it went no further than saying 
“yeah bud, we have the drives, how would you like to pay?”.


I've seen a few where they are asking for samples prior to -- 
purportedly -- submitting an order.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: OT: Re: Unsubscribe link at the bottom.

[Grant Taylor]

On 4/6/21 8:34 AM, John Hardin wrote:
What ticks me off is an unsubscribe link that goes to a javascript-heavy 
page and that *won't work* without javascript.


And an unsubscribe link with a huge identifying key on it, yet the 
unsubscribe page still asks you to enter your email address...


Ya

Those types of senders usually end up banned on my server with a custom 
comment to that effect.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

OT: Re: Unsubscribe link at the bottom.

[Grant Taylor]

On 4/5/21 8:41 PM, Peter West wrote:
I’d agree it’s address verification, as with the Unsubscribe link 
at the bottom.


I'm of the opinion that if I have any inclining of knowledge of the 
company sending the email, and SPF/DKIM/DMARC pass, I'll probably use 
the unsubscribe link.


Recently I ran into a 404 from the unsubscribe link from a company that 
my wife did business with.  *facepalm*




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: "Please send us a quote..."?

[Grant Taylor]

On 4/5/21 7:30 PM, John Hardin wrote:
Can anybody explain to me the reason behind the blind "please send us a 


quote for your product X" emails? I mean, I know they are somehow a 


scam, but I can't figure it out how it's supposed to work when the 
target isn't a business...


I chalk this up to list washing or similar address verification.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: URLs hidden in Morse code

[Grant Taylor]

On 2/10/21 9:17 AM, Kris Deugau wrote:
I would personally class any email with active Javascript as malware - 
it should never have been supported at all IMO - but the marketing 
departments have taken charge and I see all too much (ie, more than 
absolutely none) legitimate mail using it.


I'll reluctantly concede HTML email.  But I firmly believe that email 
does *NOT* /need/ JavaScript or any other active scripting / technology.


I even dislike animated GIFs in email.

If you /need/ that active scripting / technology, link to a web page. 
--  Yes, I know the folly of links in email.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Bypass RBL checks for specific address

[Grant Taylor]

On 12/22/20 4:56 PM, Grant Taylor wrote:

Is there a way to bypass RBL checks for a specific address?


Thank you all.

I believe I have been able to get the result I desired and learn a few 
things in the process.


TL;DR:  Setting scores to 0 in the specific recipient's 
~/.spamassassin/user_prefs file worked.


I learned that spamass-milter /does/ /apparently/ support 
personalization, something I wasn't aware of.


I learned that adding the "-x" option to spamass-milter will cause it to 
use sendmail -bv to try to identify the Unix account that needs to be 
passed to spamc via (spamc's) "-u" option.


I needed to tweak group membership so that the user spamass-milter ran 
as could read /etc/mail/virtusertable.db.


Now, things seem to be working.  spamd is setuid(ing) to the correct 
Unix user and reading the user_prefs file like I need.


Thank you again for all your help.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Bypass RBL checks for specific address

[Grant Taylor]

On 12/23/20 9:55 PM, John Hardin wrote:

Did you see my mention of this earlier?


Yes, I did see it.

That's a bit more invasive of a change than I was hoping to do for this 
task.


I had been waiting to reply to your earlier message to test some things 
that you recommended.


As you will see in my recent reply, I do believe that I've managed to 
achieve most of what I wanted to do.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Bypass RBL checks for specific address

[Grant Taylor]

On 12/23/20 2:15 PM, John Hardin wrote:
spamass-milter has a -u flag for a username to pass to SA. If these are 
single-recipient messages that may be enough to reliably tie into 
per-user config to disable the RBL check.


It seems as if spamass-milter is using the -u to specify a default user. 
 It also seems as if spamass-milter will attempt to discover the 
(first) recipient if -x is also used.  Spamass-milter will then use -u 
to pass the username default for first detected to spamc so that spamc 
can use personalized settings.


I am fairly sure that setting a rule score to zero bypasses the rule 
(vs. running it and ignoring the result) but you will probably want to 
test that to confirm whether the RBL is checked anyways. However, if the 
RBL check is written as a subrule then it can't be disabled this way as 
subrules don't have scores to set to zero.


ACK

This matches my tests.


That last option sounds to me like the first one you should explore.


Thankfully, and to my surprise, SpamAssassin / spamass-milter /is/ 
attempting personalization.


"-u spamass-milter" was already in place.

I added "-x" to cause spamass-milter to try to detect the first user, 
tweaked permissions (group membership) to allow spamass-milter to run 
sendmail -bv to detect some other users correctly, and now things seem 
to be working much closer to how I want.


Initial testing seems very promising use of heavily modified 
~/.spamassassin/user_prefs.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Bypass RBL checks for specific address

[Grant Taylor]

On 12/23/20 2:21 PM, Bill Cole wrote:

You definitely would know if it were.


One would think.

My head is in a different project at the moment, and I can't tell you 
exactly how things are configured without going back and looking.


/If/ things are configured to load per user settings from files in the 
recipient's home directory, then things are looking up.


I have not tested it, but I'm pretty sure that it actually disables the 
tests, as it does with any other type of rule.


ACK



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Bypass RBL checks for specific address

[Grant Taylor]

On 12/23/20 3:32 PM, Martin Gregorie wrote:
- In my case I run every message through SA, diverting spam into a 
quarantine directory and passing the rest to Postfix for delivery.


I don't quarantine anything on this system.

Spam is tagged if the score is between 5 and 15.

Spam is rejected /during/ the SMTP transaction if the score is 15 or higher.

- In your case you want to pass mail, which is being sent to a 
small set of recipients on your server directly to your local MTA 
for delivery.  The rest gets run through SA before being handed to 
your local MTA, again for local delivery.


Email only passes through the local MTA one time.  Sendmail is 
configured to interface with SpamAssassin via spamass-milter /during/ 
the SMTP transaction.  No looping.


This is also part of why I'm not 100% sure what user SpamAssassin is 
filtering the messages as.  I don't know if it's currently configured as 
a single user that the daemons are running as -or- if it's somehow 
changing users to the recipient Unix account.


I know that this particular system was never configured with SQL 
database for per-user settings.  Which I think I needed to do the last 
time I did per-user settings.  But that's been more than a decade ago.


I quite certain that I did not explicitly did anything to enable 
per-user settings on this system.  But I can't rule out some sort of 
option being default to look for per-user settings in home directories.


The logic needed to do both tasks would seem to be essentially 
the same:


read the names of all recipients that are NOT scanned by SA into a 
searchable no-scan recipients list.


for every message received
read the message into a buffer
look up its recipient in the no-scan recipients list
if the recipient is in the list
   pass the message on for delivery by writing it to stdout
else
   pass the message to SA for markup as ham or spam via spamc
   i.e, pipe the buffer content into spamc's stdin channel
   receive the marked-up message back from spamc
   i.e. read spamc's stdout channel into a buffer
fi

pass the marked-up message to your MTA for delivery
   i.e write the buffer content to stdout
clear the buffer
end-for


That's not how things work with the milter configuration.

Assuming that you're using Postfix as your MTA, you just replace 
spamc in the Postfix process chain with a program that does the above.


Nope.  As indicated multiple places, Sendmail, not Postfix.

In a little more detail: - This implies writing a program in C, 
Java or (possibly) Python or Perl.


- if your list of no-filter recipients has more than about ten 
entries, consider using a B-tree to efficiently search the list. 
In C use bsearch() and in Java use a TreeMap - both are very fast.


- the message buffer needs to be self-extending to match any received 
message. This is a no-brainer in Java (all Strings automatically 
resize to hold what is put in them, but needs a little more care if 
written in C because you don't know how big an incomming message is 
until you've read it.


- this approach doesn't need any modifications to your existing 
SA configuration


That's all considerably more complicated than I'm comfortable with at 
the moment.  It also seems to target an MTA that I'm not running.



I hope this gives you some useful ideas.


Eh   It's something to think about.  But I think it's elephants when 
I'm talking about trees.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Bypass RBL checks for specific address

[Grant Taylor]

On 12/23/20 1:37 PM, Dave Funk wrote:
If all you want is for a particular class of recipients (at the envelope 
RCPT level) not be passed to spamass-milter inside sendmail that can be 
done with a bit of hacking of your sendmail config and the milter.


Please elaborate.

I'm not opposed to reconfiguring Sendmail.  Though I'd prefer to do it 
through macros and not need to create custom ruleset(s).


I would prefer an option that does not require altering Sendmail's 
behavior /if/ it's possible to make SpanAssassin alter it's behavior.


I run my own customized miltrassassin milter which has support for 
custom macros handed to it from sendmail and it takes special action 
based on what it gets handed.


Yes, it's possible to pass different macros to different milter stages / 
action / check points / term???.  But that's just data, and not in and 
of itself conditional.


For example if the 'skip_check' is defined, the miter just returns a 
'OK' and doesn't call SA at all.


How are you conditionally passing that to a milter?  Does that involve a 
custom rule set to put 'skip_check' in a macro based on the envelope 
recipient and not for other recipients?


If the 'no_reject' macro is set then the milter will not generate a 
"550" SMTP status regardless of how high the SA score is. (needed for 
"postmaster" messages).


Same question as above, save for 'no_reject' vs 'skip_check'.


What version of sendmail are you using?


8.15.2  (It's an older Ubuntu install that is in need of an upgrade.)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Bypass RBL checks for specific address

[Grant Taylor]

On 12/23/20 12:40 PM, Benny Pedersen wrote:
if you want to disable RBL for one single ip, then add it to 
trusted_networks in local.cf


As indicated in the message you replied to, "I'm wanting to disable 
filtering for a recipient email address, which may receive messages from 
IP addresses all over the world."


if you want to disable one single recipient want all spam, then use 
all_spam_to in local.cf


As indicated elsewhere, using all_spam_to seems to still apply all 
normal filtering, including RBL checks, which I'm wanting to avoid. 
(See my reply to Dave F.'s message for more details as to what and why.)



dont make amavisd a spam content filter


Who said anything about Amavis?  It's not in context.

Context is Sendmail, spamass-milter, and SpamAssassin (spamd).

I didn't see any way to have spamass-milter bypass, much less 
conditionally bypass.  Nor did I see a way to have Sendmail 
conditionally bypass a milter.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Bypass RBL checks for specific address

[Grant Taylor]

On 12/23/20 1:01 PM, Dave Funk wrote:

That may not work for what the OP wanted.


O.o?

Because it's assumed that DNS related stuff may take some time those 
rules (if configured to run) are launched early in the processing of a 
message.


So if the OP wants to completely avoid running RBL checks (as opposed to 
just ignoring their scores/results) he may need to do some special tricks.


Yes, I want to completely avoid running the RBL checks for specific 
recipients.


One thing would be to have a separate SA instance with its own 
configuration which has the RBL stuff removed and then configure his MTA 
to select that particular SA filter when the special user address is 
detected.


Oy vey.  That sounds more complicated than I was hoping for.

This begs the question, what is the need to completely avoid running RBL 
checks for that special recipient?


Fair question.

I have about 2,000 messages a day that come in to my mail server for all 
recipients with the exception of one specific (set of) recipient(s). 
That (set of) recipient(s) receive 20,000 - 30,000 messages a day.  They 
are very specific messages for an automated communications system and 
they don't need any spam filtering, specifically RBL filtering.  (It's a 
matrix of about 20 different such parties sending between each other 
across the internet.)


I'm looking at implementing a new RBL from a service provider that 
offers a free tier of about 5,000 queries a day.  My personal messages 
are way under that limit.  The particular (set of) address(es) that I 
want to bypass RBL tests are way over that limit.  So I would like to 
bypass the RBL tests for that specific (set of) address(es).


What is supposed to happen when a message comes in that is addressed to 
multiple recipients, including the special recipient?


That is a fair question.  I think that it's exceptionally unlikely that 
the address(es) that I'm wanting to exclude co-mingling like you are 
asking about.  If that does happen, I think it's rare enough that I 
don't care what happens.  I would prefer that it not be filtered, but I 
expect the frequency would be low enough as to not push past the daily 
limit.



This could get messy.


Indeed.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Bypass RBL checks for specific address

[Grant Taylor]

On 12/22/20 11:56 PM, Axb wrote:

whitelist_to ?


My understanding is that whitelist_to, more_spam_to, and all_spam_to 
behave the same way and effectively just alter the scoring offset.


It seems as if the tests are still run, and it's just the score is 
artificially offset based on which setting is used.


I'm wanting to not run RBL tests for the specific recipient email address.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Bypass RBL checks for specific address

[Grant Taylor]

On 12/22/20 11:03 PM, Bill Cole wrote:
Do you have a setup that supports per-user preferences? e.g.: real 
system accounts.


Sort of.  The recipient is a real Unix account.  However I don't think 
my milter is configured to use per recipient filtering.


If so, you can disable off individual rules for a user by giving them a 
score of 0 in ~/.spamassassin/user_prefs if they have a real account or 
in whatever you use for per-user prefs if they are virtual users.


Would that truly disable the tests?  Or does SpamAssassin still run the 
tests but ignore the result?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Bypass RBL checks for specific address

[Grant Taylor]

Hi Rob,

On 12/22/20 6:40 PM, Rob McEwen wrote:
First, I'm NOT an expert on all of this - so somebody might be able to 
follow up with BETTER information, but this will hopefully point you in 
the right direction.


Fair enough.

Really big snip.

First, I agree with and like your idea.  For an IP address.  However

Second, I'm wanting to disable filtering for a recipient email address, 
which may receive messages from IP addresses all over the world.


So ANOTHER option might be to use the newer "response-policy" feature - 
my first idea was a sort of hack - but this "response-policy" might be 
more intended for exactly this purpose. So do a search on the following:


Response Policy Zone(s) are neat and can do a LOT of things.  But I 
don't think it's proper for my task at hand.


Thank you for your email Rob.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Bypass RBL checks for specific address

[Grant Taylor]

Is there a way to bypass RBL checks for a specific address?

I've tried the all_spam_to option, but it looks like it artificially 
lowers the score and still runs normal tests.


I'd like to disable RBL checks for one address.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Possible spam sign

[Grant Taylor]

On 12/8/20 11:18 AM, Loren Wilton wrote:

I just received a spam with this interesting From address:

From: "VA Rate Guide" 
 


Ew.

I wonder if it is worth checking for mail from more than one sender at 
once?


The BOFH in me would be tempted to add one point for each extra @.

I think that the strict RFC specification does allow for multiple 
senders, but I don't remember how it's done and it's so rare that I'd 
accept the false positive.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Apache SpamAssassin and Spammers 1st Amendment Rights

[Grant Taylor]

On 11/20/20 5:02 PM, Jay Plesset wrote:

You have a right to say what you want.


s/You have/You (largely) have/

There are specific things that are forbidden by law.  E.g. yelling fire 
in a movie theater when there isn't a fire.



I have a right to ignore you.


Hear! Hear!

Also, it's my /personal/ and /private/ email server.  /I/ will run it 
the way that /I/ want to.  If that means that I decide not to accept 
your email, then so be it.


I'm /not/ preventing you from sending your email to anyone else.  Ergo 
I'm in no way, shape, or form, infringing on on you.  Though it is sort 
of ironic that thousands of other email administrators also think like I 
do and are deciding not to accept your messages.


¯\_(ツ)_/¯


Spam filtering allows me to exercise my right to ignore you.


#truth



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: 1.6 FORGED_MUA_MOZILLA Forged mail pretending to be from Mozilla

[Grant Taylor]

On 9/23/20 1:52 PM, Jerry Malcolm wrote:
I don't doubt what you are saying.  But if AWS is so horrible and across 
the board everyone thinks anything coming from it is spam, SA isn't 
flagging it, and mail-tester.com isn't flagging it, and both have pretty 
extensive blacklist references (??).  I'm still confused.


I think that Amazon (rightfully) buckets various customers.  Bigger 
customers tend to get their own buckets.  Smaller customers, individuals 
like me, end up in a bucket with a bunch of other individuals.  I think 
it's these latter buckets that have the bad reputation.  The other fewer 
/ single customer buckets are probably much better.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: 1.6 FORGED_MUA_MOZILLA Forged mail pretending to be from Mozilla

[Grant Taylor]

On 9/23/20 1:22 PM, Jerry Malcolm wrote:
With all of the gyrations I had to go through to be able to use SES 
along the monitoring Amazon does with SES, I'm kinda surprised that 
it would be flagged as a spam source.


I don't know about SES specific, but I know that a LOT of spam comes out 
of the big cloud providers.  Both their crap and the crap that some ... 
questionable clients send therefrom.


Is there some trick I'm missing?  What do others do when mail 
keeps bouncing with no explanation and SA says everything's clean? 
There's got to be a way to make my mail more acceptable. Just give 
me a fighting chance to fix whatever is wrong.  But I have to know 
what is wrong before I can address it.


I'll bet you a drink at your local watering hole that the problem is the 
Amazon IP.  Likewise with SES.



Is there a 'right' solution?


If you're very serious about this and willing to spend some money on 
this, look into a Co-Lo or circuit provider that will provide a /24 to, 
get your own ASN, with WhoIs / SWIP that you can control.  Start warming 
it up.  You'll have a lot of work ahead of you.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: 1.6 FORGED_MUA_MOZILLA Forged mail pretending to be from Mozilla

[Grant Taylor]

On 9/23/20 1:06 PM, John Hardin wrote:
The rules are available in your local spamassasssin install, or in the 
public SVN under two places:


Thank you for the links.


The Message-ID rule itself is this:

  header __MOZILLA_MSGID    MESSAGEID =~ 
/^<(?:[a-f\d]{8}-(?:[a-f\d]{4}-){3}[a-f\d]{12}|[A-F\d]{8}\.[A-F1-9][A-F\d]{0,7})\@\S+>$/m 


Okay.  The regex is really only applying to the left hand side (the 
"local part" if you will) of the message id.  The right hand side 
("domain part") is just looking for more than one not-space character.


You'll need to be able to understand regular expressions to understand 
what it's looking for.


I'm not great it it, especially PCRE.  (I'm more vim & sed.)

But the first part looks like the same format that I see from uuidgen.

8 hexadecimal digits
hyphen
4 hexadecimal digits
hyphen
4 hexadecimal digits
hyphen
4 hexadecimal digits
hyphen
12 hexadecimal digits

I don't recognize the other format:

8 hexadecimal digits
period
0 to 7 not quite hexadecimal digits, missing the zero.

I can tell from that, that the setting in about:config that I'm using 
isn't going to be a problem as it is only the right hand ("domain") part 
of the Message-ID.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: 1.6 FORGED_MUA_MOZILLA Forged mail pretending to be from Mozilla

[Grant Taylor]

On 9/23/20 11:46 AM, John Hardin wrote:
It doesn't believe the Message-ID was generated by Thunderbird. What's 
the message ID?


This piques my interest because I tell Thunderbird to use a custom 
Message-ID domain.


Where can I read more about what SpamAssassin thinks is and is not a 
Message-ID generated by Thunderbird?  (Other than the source code.)




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Spamassassin not triggering on LMTP mail

[Grant Taylor]

On 8/5/20 3:19 AM, Guido Goluke, MajorLabel wrote:
Sorry, already found out. I use spamass-milter 
(https://linux.die.net/man/1/spamass-milter) which, out of the box, 
doesn't offer mails from 127.0.0.1 to spamassassin at all.


Can you re-configure spamass-milter to offer mail from 127.0.0.1 to 
spamassassin?


Alternatively, add an additional IP address to loopback (or compaable 
local / dummy) interface and reconfigure your web client to send using 
that IP.


As others have pointed out, you want to NOT reject (bounce) messages 
/after/ you have accepted them.


Though there is value in filtering messages and changing subsequent 
processing / routing based on spam scores.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Why the new changes need to be "depricated" forever

[Grant Taylor]

On 7/21/20 7:52 PM, Kevin A. McGrail wrote:
One data point disproves that.  The SA project made the choice 
months ago inspired by a decision in the United Kingdom: 
https://www.zdnet.com/article/uk-ncsc-to-stop-using-whitelist-and-blacklist-due-to-racial-stereotyping/


I'm okay if a group of people forms a consensus and collectively decides 
to make a change.  I think there are merits to how the change is made.


It doesn't matter what my personal opinion is of the change.  If that's 
what the community wants to do, then that's what's going to eventually 
happen.


Many smokers in my home town didn't like the smoking ban.  But it was 
decided by a town vote and it became obvious that the majority of the 
people wanted the smoking ban.


I'm okay and won't object as long as people are truthful in why they are 
doing something.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

OT: "...value judgement"

[Grant Taylor]

On 7/21/20 11:56 AM, Bill Cole wrote:
All answers: "NO!" In those cases, "black" and "white" all reference 
actual colors of physical things, not a metaphorical value judgment.


Hum.  Your "value judgement" statement is interesting.

The original meaning of blacklist that I found seems to be exactly that, 
a value judgement on if it was okay / safe to do business with people / 
businesses or not.  Specifically if someone (independent of race) was 
unsafe to do business with, they were added to the blacklist.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Why the new changes need to be "depricated" forever

[Grant Taylor]

On 7/21/20 9:09 AM, Peter L. Berghold wrote:
This is the first time this long time lurker has posted here and I'm 
probably going to offend a lot of people by what I have to say.


I don't think your post is offensive.  It is said as a statement of 
facts and does not seem to contain any malicious intent.  Sometimes 
facts hurt.  Sometimes they don't.


I really don't get why anyone would be offended by blacklistd and 
whitelist given neither have any sort of connection to race or skin 
color.


I think that many people are ~> some of society is hypersensitive to the 
two five letter strings "white" and "black".  Some people are so 
hypersensitive that they can't see the forest (meaning of the words 
containing said five letter strings) for the trees (said five letter 
strings).


It is absurd in my opinion that there is a population going about that 
is offended by seemingly everything and sees racism where none exists.


I agree and share your opinion that it is absurd where people are 
ascribing racism where none has historically exists.


Will we be asked to rename "blacktop", which is a specific subset of 
asphalt?  Or what about renaming the SR-71 Blackbird?  Or will White 
Castle need to rename, when the name was originally meant to reference 
clean and safe to eat at?  Or dare I say it, what about renaming the 
U.S.A.'s White House?


*NONE* of these three examples were named with any racism in them.  They 
were named based on the color of their appearance.


Sure, the White House may be associated with specific individuals, many 
of whom happened to be white, which have done some questionable things. 
But the occupant of the building has nothing to do with the building's 
naming.


What offends me more is the notion we have to wreak havoc in order 
to accommodate these thin skinned social warriors.


I am willing to consider new accepted norms for things going forward. 
(See below.)  I think that retroactively changing things because of a 
sub-string collision is fraught with errors.


Looking at a dictionary blog: 
https://www.macmillandictionaryblog.com/blacklist


there is no indication the term was racial at all.  A list of 
"objectionable or suspicious people" is not necessarily with regard 
to race.


I completely agree.

I wonder when these folks are going to want black and white as colors 
stricken from the English language?


IMHO completely removing the words is a very bad idea.  Lest we forget 
where we have been in the past, thus dooming us to repeat it in the future.


For better or worse, we are at an inflection point in society where 
society as a whole is deliberating the meaning and / or use of the terms 
"white" and "black".


"gay" had a significantly different meaning 100 years ago than it does 
today.  Language, much like society grows, changes, and evolves.


I think that it is generally a good thing to use the current accepted 
words when creating new things.  But creating new is decidedly different 
than retroactively changing things that exist today.  That being said, I 
think that the majority of people would agree that we have not yet 
crossed the tipping point for "white" and "black".


Even if the meaning changed overnight — something that I think is 
unlikely to happen — there will be years of cohabitation of the old 
meaning and the new meaning of the words.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Freshdesk (again)

[Grant Taylor]

On 6/26/20 7:01 PM, Bill Cole wrote:
I had a similar event 6/30 and poked them about it via both a public 
Tweet & a complaint to Sendgrid. Both entities responded *claiming* that 
they were looking into the problem. Assuming that yours also came via 
Sendgrid, it might help to add your complaint via ab...@sendgrid.com.


I looked after your message and sure enough, the message did come via 
Sendgrid.


I've got to say, between NANOG, SDLU, and SpamAssassin, I see a LOT of 
complaints about Sendgrid.


They had their chance 2+ years ago and appear to have resumed the 
obnoxious practice. They need to be gone.


Agreed.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Freshdesk (again)

[Grant Taylor]

I received an automated email from Freshdesk about five minutes after my 
post to the SpamAssassin mailing list earlier this afternoon.


I found an old thread about Freshdesk in the SpamAssassin Users archive 
[1].  This supports (confirms to me) that this is what happens.


I object to this type of behavior and would like for whomever is doing 
it to be unsubscribed from the SpamAssassin Users mailing list on principal.


Maybe give them one chance to come forward, admit the error of their 
ways, and to promise to cease and desist immediately.


[1] 
https://mail-archives.apache.org/mod_mbox/spamassassin-users/201710.mbox/thread




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: White listing messages processed by a previous milter

[Grant Taylor]

On 6/26/20 4:46 PM, Marc Roos wrote:

What would be the best practice to whitelist / not process, messages
that have already been processed by a previous milter.


I'm confused.  My knee jerk reaction is that's an MTA configuration 
issue.  But I don't think it can be that simple.  I can't think of a 
situation where the MTA would behave differently (under normal 
circumstances).  I would expect that messages coming in a path would 
always flow through the same set of milters.  Hence configuration issue. 
 But, maybe you're in a situation where messages make it to a mailbox 
through different paths and the LDA is invoking SpamAssassin.


Please help me understand the situation that you're asking about.

The only thing that comes to mind is to do something similar to what 
you're saying, add an artificial header before SpamAssassin, that you 
can have SpamAssassin filter on.  Then artificially lower the spam 
score, or see if there is a way to have SpamAssassin end early without 
any additional filtering.


Normal circumstances allows for situations where a milter earlier in the 
chain might fail open.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: spamc learning/reporting

[Grant Taylor]

On 5/16/20 8:16 AM, micah anderson wrote:
1. I cannot pass a full email address to -u, if I pass 'user' it works, 
but if I pass 'u...@example.com' it fails. How do people handle this 
with multiple domains?


It's been about 15 years, but I'd swear that I had full email address 
working like that.  Though I was pulling the entries from an SQL database.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: another extortion email check

[Grant Taylor]

On 5/4/20 3:59 PM, Martin Gregorie wrote:
The list of such passwords might get rather long, so using a 
database both makes maintenance easier, as you spotted, and also 
keeps a lot of junk out of the rule sets.


I absolutely agree.

I like the idea of keeping data outside of configuration files.


One Perl module and one or two rules triggering it seem a lot easier
to maintain than a whole heap of rules containing unreadable junk but
of course ymmv unless, of course you write code to autogenerate the
rules, but it still sounds like a good way to inflate the ruleset to
no good purpose.

Agreed.

I think $DatabaseTechnology's main benefit is keeping the password data 
outside of the configuration files.


As I write this, I may have thought of another idea.


However, I've long realised that not everybody is as keen on 
databases as I am.


I have absolutely nothing wrong with a database per say.  I just want to 
make sure that it's the proper thing and that the proper type of 
database is used for a given need.


   select count(*) where log.key = md5(key);

You can move the md5 generation into the SQL server.  Of course, you'd 
want to be mindful of the communications channel between SpamAssassin 
and the SQL server.


I'm not sure how to have SpamAssassin iterate all the words in the 
message through this routine.


If it requires a custom SpamAssassin module, then it might be better to 
do calculate the MD5 hash in SpamAssassin and avoid the security 
implications between SpamAssassin and SQL server.



Yep, not really a serious suggestion.


;-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: another extortion email check

[Grant Taylor]

On 5/4/20 3:09 PM, Jeff Mincy wrote:
You will have to write a perl plugin for SpamAssassin that finds 
passwords in an email message and MD5 hashes those passwords and 
compares against a list of previously saved hashed passwords.  The 
list of passwords could be stored in various ways.


ACK

Identifying what is and is not a password might be error prone.  I 
suspect it might be more efficient (for the programmer) to simply (salt 
and) hash every word (possibly over a specific length) in the message 
and compare that to the list of (salted) hashes.  Sure, it's somewhat 
brute force.  But if it's only applied to messages with the proper 
criteria, it might be acceptable.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: another extortion email check

[Grant Taylor]

On 5/4/20 2:51 PM, John Hardin wrote:
*if* they are being actively used for authentication, either by the 
security system (which is a glaring flaw in the design of the security 
system) or as a reference for accessing the secured resource (e.g. a 
plaintext passwords file on your desktop, which is user error).


Nope.  There is no qualification for if it's okay to store passwords 
unencrypted or not.


I would also suggest it's a bad idea if the user generates passwords 
using a pattern. A compromised password that is no longer in use 
anywhere could still potentially expose the pattern used to generate 
passwords that *are* currently in use.


This is one of the many reasons why any and all passwords should be 
stored in a secure manner.  You have no way of knowing / guessing if the 
passwords use such a pattern or not.  Ergo, default to storing them in a 
safe manner; encrypted / hashed.



...thus, the answer to your question is "no, there is not".


Fair enough.


You could potentially obfuscate the RE by doing something like:

   header   LEAKED_PASSWORD  Subject ~= 
/\x50\x40\x73\x73\x77\x30\x72\x7c\x29/


That is encoded, not encrypted.  It is trivially reversible.  So much so 
that SpamAssassin, et al., don't even need to reverse it.


"P@ssw0r|)" is better stored as base64 encoding UEBzc3cwcnwp in that at 
least binary bit manipulation is required.  It's trivial for scripts to 
do, but more difficult for humans to do.


Ideally, "P@ssw0r|)" would be stored as a hash from a one way trap 
function, c8fc4bce46291fd606914d8dcee45465.  It's neigh impossible 
reverse contemporary hashes.


...which would at least not have the password trivially visible in plain 
text for anyone who can read the config file. (You'd of course, not use 
a rule name that indicated it was about a password.)


Real security doesn't depend on the secrecy of the algorithm used.  You 
can have the rule named "LEAKED_PASSWORD" without any problem.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: another extortion email check

[Grant Taylor]

On 5/4/20 2:06 PM, Martin Gregorie wrote:
Encrypt them and put them in a single column database table that's 
also the prime key for the table?


Lookup by encrypting the item being checked before looking for an 
SQL hit count:


select count(*) where log.key = key;

0=miss, 1=hit, 2+ = error. Should run fast.


Yep.  We're describing similar concepts, encrypt / hash the known value 
(from the email) and check to see if it's encrypted counterpart is in 
the list.


Though, only encrypting the password and not associating the username 
could allow for collisions between users with the same password.  I 
think that the minimum needed is the the password and a username (in the 
form of an email address).



Of course, that would need an SA plugin, but Perl SQL interface code
isn't hard and is fairly compact. For added protection, keep the
database on an encrypted partition. Any database should do: MariaDB,
SQLite, PostgreSQL,...

Yep.

I see little benefit of an SQL database vs rules with the encrypted 
(hashed) passwords (possibly salted with the usernames / email address) 
in the SpamAssassin config file.  Well, save for possible ease of 
administration in that SA's config file doesn't need to be updated when 
passwords are compromised.


You get points for added security by obscurity it you can stick it in 
a corner of an existing, unrelated database.




I'd be afraid that would be like setting yourself up for failure in the 
future.  Sure, it's obscure.  But it's a ticking time bomb.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: another extortion email check

[Grant Taylor]

On 5/4/20 10:09 AM, Jeff Mincy wrote:
The best practice is to not use common or continue to use exposed 
passwords. Scripts are probably trying to log into your ssh using 
those passwords.

I completely agree on both accounts.


I think you are worrying about the wrong thing.


I obviously disagree.  I'm already worrying about not using exposed 
passwords.  I'm also worried about creating a list of plain text passwords.


I think you're only worrying about the former and not giving any 
consideration to the latter.


The exposed passwords being used in the extortion emails are already 
widely known and have already been exposed.
Yes, the example you cited, and many others, are quite well known.  But 
those aren't the only exposed passwords.


If you are still using the exposed password then you've got bigger 
problems.


I completely agree that (re)using exposed passwords is a problem. 
Bigger or not is a different debate.



If you are no longer using the exposed password then disclosing the
previously used password further is not going to make any
difference.


I disagree.

Storing any plain text passwords is a bad practice and should be avoided.

As such, storing plain text passwords /does/ make a difference.


But, if you are really worried about it, don't write a spamassassin
rule looking for your exposed passwords in the subject.


Which is why I have not.  It's also why I asked if there was a way to 
compare hashed text.  To quote:


"Is there any way to compare hashed strings of text?"

I'll note that my question hasn't been answered.  Instead, people have 
focused on something not germane to my question.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: another extortion email check

[Grant Taylor]

On 5/4/20 6:16 AM, John Wilcock wrote:
In the context of a list of passwords known to be compromised, it is 
hopefully fair to assume that they are no longer in current use, and 
thus no longer of any importance. If it isn't fair to assume that, then 
the organisation has bigger issues in any case!


None of that changes the fact that storing a list of clear text 
passwords is against current industry best practice.


Would you want to explain tot he board of directors / CEO that systems 
you administer were the source of passwords being compromised because 
you didn't encrypt / hash the passwords?


It does not matter where or how the passwords you put in the list came 
from or were previously exposed.  The fact remains that you are 
describing maintaining a list of clear text passwords.  This is plain 
and simply against current industry best practice.  Further, it would 
fail security audits at many companies I have worked for.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: another extortion email check

[Grant Taylor]

On 5/2/20 1:47 PM, Loren Wilton wrote:
The compromised password is already in plain text in the subject of the 
message; there isn't much point in hiding it other than embarassment.


What if the email server with the list of plain text passwords is 
compromised and said list of plain text passwords is released to a wide 
audience?  The list of previous compromised passwords could have been 
very private (known corporate hack or something like that) and not 
released to a wide audience.


Now, your list of plain text passwords on the email server is the source 
of a larger and more public release.


Why have that list of plain text passwords /anywhere/ if you don't have to?



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature