You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by joe a <jo...@j4computers.com> on 2022/08/12 23:55:43 UTC
subscribe to blacklist for domains
I need to refresh my brain on using blacklists with SA, before looking
more deeply into why this got through.
Today a email slipped through with a very low score that was clearly
phishy. A url in question, posing as another, hits no less that 6
blacklists. I was going to look at clamav that is in use here, as I had
just been tuning that a bit and realized that that may be using a hammer
to drive a screw. so to speak.
Or are they passe these days?
Re: subscribe to blacklist for domains
Posted by Noel Butler <no...@ausics.net>.
On 14/08/2022 04:23, Bill Cole wrote:
> Not sure what you mean by that... There are a handful of rules that
> sidestep specific false positive cases because the hit being evaded
> isn't meaningful in specific cases. None of those are intended to
> 'whitelist' any domain, they exist to avoid incorrect hits.
RCVD_IN_DNSWL* and some trusted rules, as two examples, in years gone
by we've had obvious spam not binned because they were in those headers
taking away the sticks harshness, so we disable them and all like them.
I get it, small offices with no experienced IT on hand might find this
annoying, but enterprises and ISP world are able to fine tune this, but
we use a number of blacklists and complex milter-regex rules that stops
95% of the crud outright before hitting SA.
--
Regards,
Noel Butler
This Email, including attachments, may contain legally privileged
information, therefore at all times remains confidential and subject to
copyright protected under international law. You may not disseminate
this message without the authors express written authority to do so.
If you are not the intended recipient, please notify the sender then
delete all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.
Re: subscribe to blacklist for domains
Posted by Kris Deugau <kd...@vianet.ca>.
Bill Cole wrote:
> Not exactly. There are 2 distinct domain lists internal to SA that exist
> to reduce false positives.
>
> 1. The URIDNSBL 'skip' list of domains which are ignored in body URIs.
> These are known to not *per se* have any correlation to the ham/spam
> classification decision.
IIRC the basic policy for this list is "these domains are never going to
be listed in the major DNSBLs, so don't bother looking them up because
the result will ALWAYS be negative".
If you're brushing the edges of the free lookup limits, this may also
help you stay under those limits a bit longer.
-kgd
Re: subscribe to blacklist for domains
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 2022-08-12 at 23:43:48 UTC-0400 (Sat, 13 Aug 2022 13:43:48 +1000)
Noel Butler <no...@ausics.net>
is rumored to have said:
> Why are you not blocking with blacklists at the border, ie: MTA.
>
> Given its 0 resources for your MTA, with anti spam checking on SA
> often using significant resources (depending on traffic/number of
> tests/rules etc), its best to stop it getting to SA in the first
> place.
Absolutely true for sender and client host domains, but looking for
domains in mail body URIs as Joe described isn't possible in most MTAs
and is inherently costly.
> SA also has this by-default list of domains that it never checks,
Not exactly. There are 2 distinct domain lists internal to SA that exist
to reduce false positives.
1. The URIDNSBL 'skip' list of domains which are ignored in body URIs.
These are known to not *per se* have any correlation to the ham/spam
classification decision.
2. The default welcomelist, which provides a 15 point bonus when in a
sender address that has been authenticated with DKIM or SPF. In
comparison, explicit block/welcome listings (i.e. done locally) are
worth +/- 100 points. These are domains which the SA developers believe
*BASED ON HARD EVIDENCE* send only ham to the degree that is possible
for a large sender of commercial email.
The purpose of these is not to overrule conscious local admin choices,
but to minimize bad surprises.
> for along time I have disagreed with this, we are the ones to decide
> who gets whitelisted not SA, not some paid third party,
That's the ideal, but it is not universally feasible. Most sites won't
know what needs exemption from filtering until they have a false
positive. They may never figure it out. Both lists that are internal to
SA are intended to only reduce false positives, not to exempt anyone
from behavior norms.
> the option clear_uridnsbl_skip_domain however prevents this,
Yes, you can clear out the skip list in whole or piecemeal. You can also
remove sender domains from the default welcomelist or zero out the
score for USER_IN_DEF_WELCOMELIST entirely to disable that list.
> but then you have to locate and 0 all the general rulesets scores that
> are whitelists as well.
Not sure what you mean by that... There are a handful of rules that
sidestep specific false positive cases because the hit being evaded
isn't meaningful in specific cases. None of those are intended to
'whitelist' any domain, they exist to avoid incorrect hits.
>
> On 13/08/2022 09:55, joe a wrote:
>
>> I need to refresh my brain on using blacklists with SA, before
>> looking more deeply into why this got through.
>>
>> Today a email slipped through with a very low score that was clearly
>> phishy. A url in question, posing as another, hits no less that 6
>> blacklists. I was going to look at clamav that is in use here, as I
>> had just been tuning that a bit and realized that that may be using a
>> hammer to drive a screw. so to speak.
>>
>> Or are they passe these days?
>
> --
> Regards,
> Noel Butler
>
> This Email, including attachments, may contain legally privileged
> information, therefore at all times remains confidential and subject
> to copyright protected under international law. You may not
> disseminate this message without the authors express written authority
> to do so. If you are not the intended recipient, please notify the
> sender then delete all copies of this message including attachments
> immediately. Confidentiality, copyright, and legal privilege are not
> waived or lost by reason of the mistaken delivery of this message.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: subscribe to blacklist for domains
Posted by joe a <jo...@j4computers.com>.
And, of course, I must edit my last reply:
On 8/13/2022 10:21 AM, joe a wrote:
> My first thought was, the postfix stuff would work, because . . .
My first thought was, the postfix stuff would NOT work, because . . .
Re: subscribe to blacklist for domains
Posted by Noel Butler <no...@ausics.net>.
On 14/08/2022 23:15, David Bürgin wrote:
> To clarify: Backscatter is caused by 'rejecting' mail with a bounce
> message, after first accepting it.
This is what was being suggested by some, I think everyone here knows
what backscatter means, and what it is.
--
Regards,
Noel Butler
This Email, including attachments, may contain legally privileged
information, therefore at all times remains confidential and subject to
copyright protected under international law. You may not disseminate
this message without the authors express written authority to do so.
If you are not the intended recipient, please notify the sender then
delete all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.
Re: subscribe to blacklist for domains
Posted by David Bürgin <db...@gluet.ch>.
Martin Gregorie:
> On Sun, 2022-08-14 at 11:39 +1000, Noel Butler wrote:
> > On 14/08/2022 02:38, Martin Gregorie wrote:
> >
> > > 3) It would be rather trivial to return spam to sender with a
> > > suitable
> >
> > WTF, that has been a terrible idea since the 90s, given most spam is
> > spoofed, the end result of this will be your mail server getting the
> > poor reputation as source of backscatter and going into blacklists :)
> >
> greed - I don't do that, but almost as long as I've been on this list
> there have been advocates of it. As I said, I thought about it, but the
> effort of writing a filter to determine what, if anything should be
> bounced or rejected, has never seemed worth the effort for such a low
> volume mail used as myself.
To clarify: Backscatter is caused by ‘rejecting’ mail with a bounce
message, after first accepting it. Backscatter is not caused by
rejecting mail directly during the SMTP conversation.
The Wikipedia page explains this really quite well:
https://en.wikipedia.org/wiki/Backscatter_%28email%29
Depending on one’s goals it may be useful to reject spam, at least
obvious spam, early, eg using a milter.
Re: subscribe to blacklist for domains
Posted by Michael Grant via users <us...@spamassassin.apache.org>.
> WTF, that has been a terrible idea since the 90s, given most spam is
> spoofed, the end result of this will be your mail server getting the
> poor reputation as source of backscatter and going into blacklists :)
If you reject, you should reject on their SMTP connection. If you
return a DSN later, there's a high chance you are causing back-scatter
spam to the wrong place.
When you reject on the initial connection, if the spammer is abusing
someone else's infrastructure, you may cause errors to go back to the
owner of that infrastructure which will clue them into a problem they
need to clean up. Not always though.
Some ESPs track DSNs they get back and remove those addresses from
future mailouts. If the spammer reuses that ESP, your address may not
be used again with that account. This is really more useful for
fringe spam like things you didn't realize you signed up for or things
that weren't meant for you.
On the other hand, some ESPs let you report the account as spam, but
to do that you'd have had to received the message first to click on
some link in it. Mailchimp for example lets you click a box to be
removed and tell them you consider it spam and if they get sufficient
complaints, the account is blocked.
In short, I don't think it's bad to reject spam. Care needs to be
taken blanket blocking mail from ESPs though.
Re: subscribe to blacklist for domains
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>>On Sun, 2022-08-14 at 11:39 +1000, Noel Butler wrote: On 14/08/2022
>>3) It would be rather trivial to return spam to sender with a
>>suitable
>On 14/08/2022 22:37, Martin Gregorie wrote:
>>WTF, that has been a terrible idea since the 90s, given most spam is
>>spoofed, the end result of this will be your mail server getting the
>>poor reputation as source of backscatter and going into blacklists :)
On 15.08.22 12:00, Noel Butler wrote:
> greed - I don't do that, but almost as long as I've been on this list
>there have been advocates of it. As I said, I thought about it, but the
>effort of writing a filter to determine what, if anything should be
>bounced or rejected, has never seemed worth the effort for such a low
>volume mail used as myself.
IMHO if spam passes SPF and/or DKIM, bouncing it should at least result it
in being delivered to the correct sender (or they'll have to fix their SPF
records).
of course, only if you are willing to risk anger of misconfigured senders...
>When people advocate for it, it goes to show the only thing they have
>ever been responsible for is their own home mail server with accounts
>for them and maybe a friend or two on it, never for anything
>commercial, you've been around a great many years Martin, so I'm glad
>you resist the temptation of the fools.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
My mind is like a steel trap - rusty and illegal in 37 states.
Re: subscribe to blacklist for domains
Posted by Noel Butler <no...@ausics.net>.
On 14/08/2022 22:37, Martin Gregorie wrote:
> On Sun, 2022-08-14 at 11:39 +1000, Noel Butler wrote: On 14/08/2022
> 02:38, Martin Gregorie wrote:
>
> 3) It would be rather trivial to return spam to sender with a
> suitable
> WTF, that has been a terrible idea since the 90s, given most spam is
> spoofed, the end result of this will be your mail server getting the
> poor reputation as source of backscatter and going into blacklists :)
greed - I don't do that, but almost as long as I've been on this list
there have been advocates of it. As I said, I thought about it, but the
effort of writing a filter to determine what, if anything should be
bounced or rejected, has never seemed worth the effort for such a low
volume mail used as myself.
Martin
When people advocate for it, it goes to show the only thing they have
ever been responsible for is their own home mail server with accounts
for them and maybe a friend or two on it, never for anything commercial,
you've been around a great many years Martin, so I'm glad you resist the
temptation of the fools.
--
Regards,
Noel Butler
This Email, including attachments, may contain legally privileged
information, therefore at all times remains confidential and subject to
copyright protected under international law. You may not disseminate
this message without the authors express written authority to do so.
If you are not the intended recipient, please notify the sender then
delete all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.
Re: subscribe to blacklist for domains
Posted by Martin Gregorie <ma...@gregorie.org>.
On Sun, 2022-08-14 at 11:39 +1000, Noel Butler wrote:
> On 14/08/2022 02:38, Martin Gregorie wrote:
>
> > 3) It would be rather trivial to return spam to sender with a
> > suitable
>
> WTF, that has been a terrible idea since the 90s, given most spam is
> spoofed, the end result of this will be your mail server getting the
> poor reputation as source of backscatter and going into blacklists :)
>
greed - I don't do that, but almost as long as I've been on this list
there have been advocates of it. As I said, I thought about it, but the
effort of writing a filter to determine what, if anything should be
bounced or rejected, has never seemed worth the effort for such a low
volume mail used as myself.
Martin
Re: subscribe to blacklist for domains
Posted by Noel Butler <no...@ausics.net>.
On 14/08/2022 02:38, Martin Gregorie wrote:
> 3) It would be rather trivial to return spam to sender with a suitable
WTF, that has been a terrible idea since the 90s, given most spam is
spoofed, the end result of this will be your mail server getting the
poor reputation as source of backscatter and going into blacklists :)
--
Regards,
Noel Butler
This Email, including attachments, may contain legally privileged
information, therefore at all times remains confidential and subject to
copyright protected under international law. You may not disseminate
this message without the authors express written authority to do so.
If you are not the intended recipient, please notify the sender then
delete all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.
Re: subscribe to blacklist for domains
Posted by Martin Gregorie <ma...@gregorie.org>.
On Sat, 2022-08-13 at 14:05 -0400, joe a wrote:
> To add my comment, returning SPAM, assuming it even reaches the
> original sender, may serve only to assure them of the effectiveness of
> their campaign to reach valid addresses. In effect "helping" them.
>
Agreed - I've occasionally thought about returning spam, but never found
a good reason to do it.
Here's my reinforcement for doing nothing: a year or two back, I somehow
got added to some mailing list belonging to a Florida Hospital (as
useless a thing for somebody to do as can be imagined seeing I don't
live in the USA, let alone Florida, so probably a spammer infected their
mailing list or stole their list address). As usual, I added that
address to my personal blacklist: problem solved.
However, I was feeling helpful that day, so also emailed their 'abuse'
address to let them know they had a problem. Didn't bounce, so they must
have got it.
Did they do anything? Apparently not. I still get their spam, but at
least my system bins it automatically.
Martin
Re: subscribe to blacklist for domains
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2022-08-15 11:33:53 -0400, Greg Troxel wrote:
> Vincent Lefevre <vi...@vinc17.net> writes:
> > On 2022-08-13 14:05:43 -0400, joe a wrote:
> >> On 8/13/2022 12:38 PM, Martin Gregorie wrote:
> >> . . .
> >> > 2) There's no mandatory need to REJECT spam. It has always been up to
> >> > the recipient to decide whether to return it to the sender or not.
> >>
> >> Agreed in part. I see returning SPAM to sender as an exercise in futility
> >> or perhaps further enabling. But I do prefer labeling as SPAM to outright
> >> rejection in many cases.
>
> Be careful in "returning". There is replying with 550 and not accepting
> it, which ensures that *you* are not generating backscatter, and there
> is sending a bounce later. I think that if you're going to reject it,
> you should 550 it.
Yes, this is a 550 SMTP reply.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: subscribe to blacklist for domains
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2022-08-23 14:31:55 +0100, Martin Gregorie wrote:
> Fair enough: I did say that some of this was off the top pf my head at
> the end of a longish day.
>
> Would doing the lookup trick on the URL in the Message-ID header be any
> more reliable?
DNS Lookup checking is valid only for IP -> FQDN -> IP, not
FQDN -> IP -> FQDN, whatever the FQDN.
Note also that the Message-ID is not a URL, just some kind of
identifier with some syntax and that must be unique. In general,
you shouldn't assume anything on the right-hand side of a
Message-ID. RFC 5322 just says:
As with addr-spec, a liberal syntax is given for the right-hand side
of the "@" in a msg-id. However, later in this section, the use of a
domain for the right-hand side of the "@" is RECOMMENDED.
In particular, it doesn't need to be resolvable, and there are
good reasons for which this may not be the case. For instance,
the Message-ID may be generated on the machine from which the
message is sent, with some internal hostname on the right-hand
side (this is better to ensure unicity), thus is not resolvable.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: subscribe to blacklist for domains
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2022-08-13 19:09:26 -0400, joe a wrote:
> On 8/13/2022 4:52 PM, Vincent Lefevre wrote:
> > Well, if you don't reject the mail with the reason that the address
> > is invalid, the spammer could deduce that the address is valid
> > (at least potentially valid). By not rejecting spam, the spammer
> > could think that the spam arrived at its destination and would
> > validate the address.
>
> Rejecting mail for an invalid recipient was not my concern. In the case of
> an invalid email address is certainly proper to inform the sender of that
> fact.
>
> I could even agree that informing senders of "false positives" is useful as
> well, but doing that via a "REJECT" would seem burdensome. REJECT-ing email
> that is flagged by one of the DNS RBL thingies still seems to me to be
> wasted effort and possibly counter productive.
There may be false positives. For instance, the mail server
(smarthost) of my laboratory occasionally gets flagged by RBLs
because the accounts of some users gets compromised and start
to become a spam relay. But the smarthost still sends legitimate
mail and the sender should be able to know that mail he has sent
is rejected because of the blacklists.
> Why waste your own system resources to help a scoundrel? Drop them and be
> done.
The resources of the recipient are not wasted: the only difference
is the status code returned to the sender. The resources of the
sender may be "wasted", but:
* If the message is legitimate (false positive), this allows the
sender to know that the message has not been received.
* If the message is really spam, this may waste the resources of
the spammer, but who cares...
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: subscribe to blacklist for domains
Posted by Jared Hall <ja...@jaredsec.com>.
On 8/14/2022 2:55 PM, John Hardin wrote:
> On Sat, 13 Aug 2022, joe a wrote:
>
>> Why waste your own system resources to help a scoundrel? Drop them
>> and be done.
>
> I personally perfer to TCP tarpit repeat offenders.
>
>
+1
-- Jared Hall
Re: subscribe to blacklist for domains
Posted by John Hardin <jh...@impsec.org>.
On Sat, 13 Aug 2022, joe a wrote:
> Why waste your own system resources to help a scoundrel? Drop them and be
> done.
I personally perfer to TCP tarpit repeat offenders.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Human beings are born with different capacities.
If they are free, they are not equal. And if they are equal,
they are not free. -- Aleksandr Solzhenitsyn
-----------------------------------------------------------------------
Tomorrow: the 77th anniversary of the end of World War II
Re: subscribe to blacklist for domains
Posted by joe a <jo...@j4computers.com>.
I am far from an anti SPAM expert, but:
On 8/13/2022 4:52 PM, Vincent Lefevre wrote:
> On 2022-08-13 14:05:43 -0400, joe a wrote:
>> On 8/13/2022 12:38 PM, Martin Gregorie wrote:
>> . . .
>>> 2) There's no mandatory need to REJECT spam. It has always been up to
>>> the recipient to decide whether to return it to the sender or not.
>>
>> Agreed in part. I see returning SPAM to sender as an exercise in futility
>> or perhaps further enabling. But I do prefer labeling as SPAM to outright
>> rejection in many cases.
>
> Rejecting mail (instead of accepting it and dropping it) is useful
> in case of false positives.
That may be so and of use to a legitimate sender that actually cares
about such things. A true SPAM'er could not care less.
>>> 3) It would be rather trivial to return spam to sender with a suitable
>>> admonishment but I decided that its not worth my time to write such
>>> a discriminator and maintain yet another set of rules about what gets
>>> quarantined and what gets returned: better to quarantine it so
>>> it can be analysed with the mk 1 eyeball.
>>
>> To add my comment, returning SPAM, assuming it even reaches the original
>> sender, may serve only to assure them of the effectiveness of their campaign
>> to reach valid addresses. In effect "helping" them.
>
> Well, if you don't reject the mail with the reason that the address
> is invalid, the spammer could deduce that the address is valid
> (at least potentially valid). By not rejecting spam, the spammer
> could think that the spam arrived at its destination and would
> validate the address.
Rejecting mail for an invalid recipient was not my concern. In the case
of an invalid email address is certainly proper to inform the sender of
that fact.
I could even agree that informing senders of "false positives" is useful
as well, but doing that via a "REJECT" would seem burdensome.
REJECT-ing email that is flagged by one of the DNS RBL thingies still
seems to me to be wasted effort and possibly counter productive.
Why waste your own system resources to help a scoundrel? Drop them and
be done.
joe a.
Re: subscribe to blacklist for domains
Posted by John Hardin <jh...@impsec.org>.
On Tue, 23 Aug 2022, Vincent Lefevre wrote:
> On 2022-08-18 12:11:04 -0400, Kris Deugau wrote:
>> Mmm. So how would you, as sender or sender's mail provider, troubleshoot a
>> message rejected with "550 Too spammy"? I have seen several rejections that
>> were equally clear and to the point, without divulging any particular detail
>> about what, exactly, was objectionable.
>
> I doubt that spammers take 550 messages into account, or even read them.
Agreed.
Perhaps dumping the list of SA rules that hit, absent scores. That's not a
bad violation of opsec as there are public evaluation tools available that
would return much the same information, and that would give something
helpful to discuss with the site admin when trying to resolve the
situation.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Law is too dangerous a tool to leave in the hands of
opposing tribes who just want to use it to
bludgeon one another. -- J.D. Tuccile
-----------------------------------------------------------------------
Tomorrow: the 1943rd anniversary of the destruction of Pompeii
Re: subscribe to blacklist for domains
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2022-08-18 12:11:04 -0400, Kris Deugau wrote:
> Mmm. So how would you, as sender or sender's mail provider, troubleshoot a
> message rejected with "550 Too spammy"? I have seen several rejections that
> were equally clear and to the point, without divulging any particular detail
> about what, exactly, was objectionable.
I doubt that spammers take 550 messages into account, or even read them.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: subscribe to blacklist for domains
Posted by Noel Butler <no...@ausics.net>.
On 16/08/2022 01:33, Greg Troxel wrote:
> If you accept mail and then send it to /dev/null, then the recipient is
> unaware that it was sent, and the sender is unaware that it wasn't
> received,
Exactly what happens to high scored spam, if its high is very obvious
trash and the recipient wont want to know, and well who cares what those
senders want to know :)
> So I'm a firm believer that at SMTP time, you need to pick one of
>
> 550 and you're done
>
> accept and then sort into ham mailboxes and spam mailboxes, with the
> idea that the user should be checking all of them
or use both,
1 block the very obvious and non compliant; 95%
2 spam folder the "just triggering spam rules" - a problem with pop3
users (yes, speaking from an ISP world in Oceana they heavily outweigh
number of imap users) so the labelled as spam stuff is mixed in their
normal inbox ;0.1%
3 /dev/null the other obvious ; 0.0001% (ultra low becasue step 1
catches most)
4 inbox the rest
As for spam folder checking.... not even I bother with mine except for
once or twice a year
--
Regards,
Noel Butler
This Email, including attachments, may contain legally privileged
information, therefore at all times remains confidential and subject to
copyright protected under international law. You may not disseminate
this message without the authors express written authority to do so.
If you are not the intended recipient, please notify the sender then
delete all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.
Re: subscribe to blacklist for domains
Posted by Greg Troxel <gd...@lexort.com>.
Vincent Lefevre <vi...@vinc17.net> writes:
> On 2022-08-13 14:05:43 -0400, joe a wrote:
>> On 8/13/2022 12:38 PM, Martin Gregorie wrote:
>> . . .
>> > 2) There's no mandatory need to REJECT spam. It has always been up to
>> > the recipient to decide whether to return it to the sender or not.
>>
>> Agreed in part. I see returning SPAM to sender as an exercise in futility
>> or perhaps further enabling. But I do prefer labeling as SPAM to outright
>> rejection in many cases.
Be careful in "returning". There is replying with 550 and not accepting
it, which ensures that *you* are not generating backscatter, and there
is sending a bounce later. I think that if you're going to reject it,
you should 550 it.
> Rejecting mail (instead of accepting it and dropping it) is useful
> in case of false positives.
This is a key point. A lot of mail ends up in spam folders that are so
full they don't get looked at, at a number of ISPs that have a poor
email recipient experience. I know people at AOL/Yahoo/Verizon and
Comcast that have mail end up in spam and in practice do not cope with
looking at it. (Further, this mail is wrongly classified, and people
can't in practice fix that.)
By rejecting spam with 550, it doesn't end up in the spam folder, and
that folder becomes easier to scan. And if legit mail is rejected, at
least the sender knows it didn't get there, even if the ISP is
intractable.
If you accept mail and then send it to /dev/null, then the recipient is
unaware that it was sent, and the sender is unaware that it wasn't
received, other than by implementing a human-human ack protocol.
So I'm a firm believer that at SMTP time, you need to pick one of
550 and you're done
accept and then sort into ham mailboxes and spam mailboxes, with the
idea that the user should be checking all of them
By choosing 550 you can turn up the aggressiveness of checking a bit
compared to if you don't.
Re: subscribe to blacklist for domains
Posted by Martin Gregorie <ma...@gregorie.org>.
On Tue, 2022-08-23 at 12:11 +0200, Vincent Lefevre wrote:
> On 2022-08-18 19:40:33 +0100, Martin Gregorie wrote:
> > - if the reverse lookup fails, or the domain it retrieved does not
> > match the one in the From address, send a bare 550 REJECT because
> > the failed
> > reverse lookup implies the sending domain is a forgery.
>
> It doesn't. There are IPs that host several domains, e.g. in case
> of shared web hosting. For instance, I have 2 domains vinc17.net
> and vinc17.org, and both are handled by the same machine, thus
> with a single IP address. So, necessarily, the reverse lookup will
> not match for one of these domains.
>
Fair enough: I did say that some of this was off the top pf my head at
the end of a longish day.
Would doing the lookup trick on the URL in the Message-ID header be any
more reliable?
Martin
Re: subscribe to blacklist for domains
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2022-08-18 19:40:33 +0100, Martin Gregorie wrote:
> - extract the domain name from the incoming mail's From header and use
> it to find the domain IP. Use that IP to do a reverse domain lookup.
>
> - if the reverse lookup fails, or the domain it retrieved does not match
> the one in the From address, send a bare 550 REJECT because the failed
> reverse lookup implies the sending domain is a forgery.
It doesn't. There are IPs that host several domains, e.g. in case
of shared web hosting. For instance, I have 2 domains vinc17.net
and vinc17.org, and both are handled by the same machine, thus
with a single IP address. So, necessarily, the reverse lookup will
not match for one of these domains.
BTW, for spamassassin.apache.org, it resolves to 151.101.2.132, but
the reverse lookup fails.
And anyway, this is about mail, so the only thing that could really
be considered is the MX. But the MX domains may be different from
the "From:" domain, even if the domain has its own range of IP
addresses. For instance:
$ dig -t mx ens-lyon.fr
[...]
;; ANSWER SECTION:
ens-lyon.fr. 6754 IN MX 20 mxc.relay.renater.fr.
ens-lyon.fr. 6754 IN MX 20 mxd.relay.renater.fr.
ens-lyon.fr. 6754 IN MX 20 mxa.relay.renater.fr.
ens-lyon.fr. 6754 IN MX 20 mxb.relay.renater.fr.
[...]
The only thing that you may want to do is a reverse lookup of the
client IP, then check that the answer resolves back to the IP (among
the answers, as there may be several IP addresses).
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: subscribe to blacklist for domains
Posted by Martin Gregorie <ma...@gregorie.org>.
On Thu, 2022-08-18 at 12:11 -0400, Kris Deugau wrote:
> Mmm. So how would you, as sender or sender's mail provider,
> troubleshoot a message rejected with "550 Too spammy"? I have seen
> several rejections that were equally clear and to the point, without
> divulging any particular detail about what, exactly, was
> objectionable.
>
> What details should the receiving system include in that 550, such
> that legitimate senders can adjust or fix something in their message,
> that spammers can't also abuse to slip their glop through that filter
> as well?
The only reasonably foolproof way I can think of gently telling friendly
senders why their message is being treated as spam while not helping
spammers to send more believable and/or less obvious spam requires
something line the following:
You should maintain some form of mail archive. It needn't be all that
big or complex: for this purpose all it needs to contain is a list of
valid addresses that you have previously sent mail to. If you keep this
information set then, as an initial guess the spam response logic can be
as simple as:
- extract the domain name from the incoming mail's From header and use
it to find the domain IP. Use that IP to do a reverse domain lookup.
- if the reverse lookup fails, or the domain it retrieved does not match
the one in the From address, send a bare 550 REJECT because the failed
reverse lookup implies the sending domain is a forgery.
This is a manual check I often use if I suspect a message of being
spam and get curious about it for some reason or other. FWIW my next
step is to use Lynx to see what the associated website (if any) is
associated with the domain - an amazing amount of spam sources have an
associated website - and its almost always an off-the-peg generic
page. I use Lynx for this because it is a text-only browser that can
also disable all cookie handling, so is a relatively safe way of
looking at possibly dodgy websites.
- if the mail archive shows that we've previously sent mail to the
sender of this message, either send a bounce or a 550 rejection
together with a polite explanation of why you think their message
might be spam.
- if mail has NOT previously been sent to the sender of this message,
send a bare 550 REJECT because (a) they may well be a spammer and (b)
you don't know them and so don't (yet) have any need to be nice to
them.
This is pretty much off the top of my pointy head, after a warmish day
spent driving round part of SE UK, so probably obvious flaws, but this
would be my starting point if I was planning to reject spam and similar
dross rather than simply tossing it in the wastebasket and it does at
least suggest a way of not telling a spammer why you dejected his junk.
Martin
Re: subscribe to blacklist for domains
Posted by Kris Deugau <kd...@vianet.ca>.
Vincent Lefevre wrote:
> On 2022-08-16 12:05:43 -0400, Kris Deugau wrote:
>> And, quite reasonably, most rejections for spam include very little or no
>> detail, so aside from DNSBL-based rejections the sending platform has
>> essentially zero information beyond "the receiving system doesn't like us".
>> Which can't be troubleshot from the sending side without at least some kind
>> of feedback from the receiving side.
>
> Minimal information should at least be included with the 550 status.
> This is also useful for the receiving side in order to know whether
> the antispam rules are effective (by checking the logs).
Mmm. So how would you, as sender or sender's mail provider,
troubleshoot a message rejected with "550 Too spammy"? I have seen
several rejections that were equally clear and to the point, without
divulging any particular detail about what, exactly, was objectionable.
What details should the receiving system include in that 550, such that
legitimate senders can adjust or fix something in their message, that
spammers can't also abuse to slip their glop through that filter as
well? (TBH the spammers have the advantage here. For instance, if a
filter is rejecting on "miscellaneous terrifying MIME/HTML crap", the
spammer is going to have a FAR easier time tweaking their message than a
legitimate sender.... because the legitimate sender is just using
something like "Outlook stationery", which means they have basically
zero control over any MIME or HTML formatting that a filter might be
choking on.)
-kgd
Re: subscribe to blacklist for domains
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2022-08-16 12:05:43 -0400, Kris Deugau wrote:
> Vincent Lefevre wrote:
> > On 2022-08-15 10:39:05 -0400, Kris Deugau wrote:
> > > Vincent Lefevre wrote:
> > > > Rejecting mail (instead of accepting it and dropping it) is useful
> > > > in case of false positives.
> > >
> > > I'm a bit torn on this.
> > >
> > > On the one hand, yes, the sender now knows for sure their message didn't get
> > > through*.
> > >
> > > On the other hand, the sender now calls *their* outgoing mail provider to
> > > complain "You wouldn't let my message through!", and trying to explain to
> > > someone that no, really, we can't do anything about this because it's the
> > > recipient's system that doesn't like you is.... sometimes painfully tedious.
> >
> > Well, the outgoing mail provider (or IP address supplier) is sometimes
> > the culprit, e.g. by letting spam out.
>
> True. But if spam filters everywhere were perfect, spam wouldn't be such a
> big problem.
>
> And, quite reasonably, most rejections for spam include very little or no
> detail, so aside from DNSBL-based rejections the sending platform has
> essentially zero information beyond "the receiving system doesn't like us".
> Which can't be troubleshot from the sending side without at least some kind
> of feedback from the receiving side.
Minimal information should at least be included with the 550 status.
This is also useful for the receiving side in order to know whether
the antispam rules are effective (by checking the logs).
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: subscribe to blacklist for domains
Posted by Kris Deugau <kd...@vianet.ca>.
Vincent Lefevre wrote:
> On 2022-08-15 10:39:05 -0400, Kris Deugau wrote:
>> Vincent Lefevre wrote:
>>> Rejecting mail (instead of accepting it and dropping it) is useful
>>> in case of false positives.
>>
>> I'm a bit torn on this.
>>
>> On the one hand, yes, the sender now knows for sure their message didn't get
>> through*.
>>
>> On the other hand, the sender now calls *their* outgoing mail provider to
>> complain "You wouldn't let my message through!", and trying to explain to
>> someone that no, really, we can't do anything about this because it's the
>> recipient's system that doesn't like you is.... sometimes painfully tedious.
>
> Well, the outgoing mail provider (or IP address supplier) is sometimes
> the culprit, e.g. by letting spam out.
True. But if spam filters everywhere were perfect, spam wouldn't be
such a big problem.
And, quite reasonably, most rejections for spam include very little or
no detail, so aside from DNSBL-based rejections the sending platform has
essentially zero information beyond "the receiving system doesn't like
us". Which can't be troubleshot from the sending side without at least
some kind of feedback from the receiving side.
-kgd
Re: subscribe to blacklist for domains
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2022-08-15 10:39:05 -0400, Kris Deugau wrote:
> Vincent Lefevre wrote:
> > Rejecting mail (instead of accepting it and dropping it) is useful
> > in case of false positives.
>
> I'm a bit torn on this.
>
> On the one hand, yes, the sender now knows for sure their message didn't get
> through*.
>
> On the other hand, the sender now calls *their* outgoing mail provider to
> complain "You wouldn't let my message through!", and trying to explain to
> someone that no, really, we can't do anything about this because it's the
> recipient's system that doesn't like you is.... sometimes painfully tedious.
Well, the outgoing mail provider (or IP address supplier) is sometimes
the culprit, e.g. by letting spam out.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: subscribe to blacklist for domains
Posted by Kris Deugau <kd...@vianet.ca>.
Vincent Lefevre wrote:
> On 2022-08-13 14:05:43 -0400, joe a wrote:
>> On 8/13/2022 12:38 PM, Martin Gregorie wrote:
>> . . .
>>> 2) There's no mandatory need to REJECT spam. It has always been up to
>>> the recipient to decide whether to return it to the sender or not.
>>
>> Agreed in part. I see returning SPAM to sender as an exercise in futility
>> or perhaps further enabling. But I do prefer labeling as SPAM to outright
>> rejection in many cases.
>
> Rejecting mail (instead of accepting it and dropping it) is useful
> in case of false positives.
I'm a bit torn on this.
On the one hand, yes, the sender now knows for sure their message didn't
get through*.
On the other hand, the sender now calls *their* outgoing mail provider
to complain "You wouldn't let my message through!", and trying to
explain to someone that no, really, we can't do anything about this
because it's the recipient's system that doesn't like you is....
sometimes painfully tedious.
I have had a couple of cases where I tried to rephrase myself half a
dozen ways to explain this to a couple of senders; "you'll have to
contact them by some other method to get them to whitelist you, because
we literally CAN NOT force a message to be accepted". I'm pretty sure
that in one case I literally replied back "I don't know how else to put
this, we can't do anything because it's the recipient's mail system
that's rejecting the message".
On that basis I'm inclined to say that quarantining on the recipient end
is better, because the support burden then falls on the operator of the
misbehaving filter instead of the innocent sending platform.
I feel much the same about challenge-response filters; they offload the
problem from the person operating the filter onto everyone else.
-kgd
[*] Assuming they can make sense of the postmaster message in the first
place, which personal experience says "no, they really can't"... and
not just general end users, some "IT contractors" dealing with email
are, um, not entirely clued in to how SMTP works.
Re: subscribe to blacklist for domains
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2022-08-13 14:05:43 -0400, joe a wrote:
> On 8/13/2022 12:38 PM, Martin Gregorie wrote:
> . . .
> > 2) There's no mandatory need to REJECT spam. It has always been up to
> > the recipient to decide whether to return it to the sender or not.
>
> Agreed in part. I see returning SPAM to sender as an exercise in futility
> or perhaps further enabling. But I do prefer labeling as SPAM to outright
> rejection in many cases.
Rejecting mail (instead of accepting it and dropping it) is useful
in case of false positives.
> > 3) It would be rather trivial to return spam to sender with a suitable
> > admonishment but I decided that its not worth my time to write such
> > a discriminator and maintain yet another set of rules about what gets
> > quarantined and what gets returned: better to quarantine it so
> > it can be analysed with the mk 1 eyeball.
>
> To add my comment, returning SPAM, assuming it even reaches the original
> sender, may serve only to assure them of the effectiveness of their campaign
> to reach valid addresses. In effect "helping" them.
Well, if you don't reject the mail with the reason that the address
is invalid, the spammer could deduce that the address is valid
(at least potentially valid). By not rejecting spam, the spammer
could think that the spam arrived at its destination and would
validate the address.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: subscribe to blacklist for domains
Posted by joe a <jo...@j4computers.com>.
On 8/13/2022 12:38 PM, Martin Gregorie wrote:
. . .
>
> 2) There's no mandatory need to REJECT spam. It has always been up to
> the recipient to decide whether to return it to the sender or not.
Agreed in part. I see returning SPAM to sender as an exercise in
futility or perhaps further enabling. But I do prefer labeling as SPAM
to outright rejection in many cases.
> 3) It would be rather trivial to return spam to sender with a suitable
> admonishment but I decided that its not worth my time to write such
> a discriminator and maintain yet another set of rules about what gets
> quarantined and what gets returned: better to quarantine it so
> it can be analysed with the mk 1 eyeball.
>
> Martin
>
To add my comment, returning SPAM, assuming it even reaches the original
sender, may serve only to assure them of the effectiveness of their
campaign to reach valid addresses. In effect "helping" them.
Opinions vary, of course.
Re: subscribe to blacklist for domains
Posted by Martin Gregorie <ma...@gregorie.org>.
On Sat, 2022-08-13 at 17:46 +0200, Reindl Harald wrote:
> and the main downside is that you can't REJECT clear spam and if "This
> puts spam into a holding area, where A cron job deletes it after a
> week" nobody knows in case of false positives
>
1) OF COURSE I have a daily cron job that reports any mail that is
treated as spam and added to the quarantine area. There's no point in
having a quarantine area without reporting what goes into it. Equally
obviously, not being able to retrieve and read mis-identified spam
would be a really stupid omissjon: thats what a 7 day quarantine
period is for.
2) There's no mandatory need to REJECT spam. It has always been up to
the recipient to decide whether to return it to the sender or not.
3) It would be rather trivial to return spam to sender with a suitable
admonishment but I decided that its not worth my time to write such
a discriminator and maintain yet another set of rules about what gets
quarantined and what gets returned: better to quarantine it so
it can be analysed with the mk 1 eyeball.
Martin
Re: subscribe to blacklist for domains
Posted by Martin Gregorie <ma...@gregorie.org>.
On Sat, 2022-08-13 at 10:21 -0400, joe a wrote:
> This is a low volume system consisting of postfix, SA, clamav and
> fetchmail.
>
> The mailserver (postfix) is not exposed to the internet, mail traffic
> is sent to it by "fetchmail", which itself goes out to several
> providers where mail accounts reside.
>
I've been running a very similar small volume mail system for some time
and am happy with it. My mail handling pipeline has these steps:
- I use getmail, running on my house server, rather than fetchmail, to
fetch incoming mail. I don't read or write mail on the house server.
- All incoming mail is then passed to SA, which has quite a lot of
custom rules
- SA output is passed to a privately-written filter.
This puts spam into a holding area, where A cron job deletes it
after a week.
It calls the Postfix sendmail to pass ham to Postfix for delivery.
- I run Dovecot to pass incoming mail to systems on my local LAN:
- All mail sent on my LAN is sent via the Postfix instance on the house
server, so all system messages get forwarded to the laptop I use as my
main terminal device
- The house server sends outgoing mail directly to my ISP.
The main benefits of this setup are:
- since externally sourced mail is fetched from my mailbox on my ISP,
my firewall can be set to refuse all external connection requests.
- all non-spam mail (both external and from other systems on my LAN)
ends up in the mailbox on this 'ere laptop
- implementing a mail archive only needs a storage mechanism and
configuring Postfix on the house server to BCC everything to it.
Thats probably more than you wanted to know, but hopefully will show you
that this sort of mail handling system is both easy to set up and robust
in operation. Its been running with essentially no changes for over ten
years now.
Martin
Re: subscribe to blacklist for domains
Posted by joe a <jo...@j4computers.com>.
I'll be sure to look this over well to see what I can use or adapt, thanks.
On 8/13/2022 11:04 AM, Reindl Harald wrote:
>
>
> Am 13.08.22 um 16:21 schrieb joe a:
>> Ah, thanks for describing that. I am somewhat more brain fogged than
>> usual this morning, so am uncertain any of those would work in this
>> configuration. But I certainly need to look deeper. At least into my
>> coffee mug.
>>
>> This is a low volume system consisting of postfix, SA, clamav and
>> fetchmail.
>>
>> The mailserver (postfix) is not exposed to the internet, mail traffic
>> is sent to it by "fetchmail", which itself goes out to several
>> providers where mail accounts reside.
>>
>> My first thought was, the postfix stuff would work, because . . . then
>> I realized, I've not looked at those solutions for some time, if ever.
>> So, I should stop here and look them over.
>>
>> However, any real world "we did that" exists, please let me know
>
> if 8 years in production is enough for you look below and keep in mind
> that this is for a inbound-only server and must not be applied to
> submission
>
> postscreen_bare_newline_enable = no
> postscreen_bare_newline_action = enforce
> postscreen_pipelining_enable = no
> postscreen_pipelining_action = enforce
> postscreen_non_smtp_command_enable = no
> postscreen_non_smtp_command_action = enforce
>
> postscreen_dnsbl_min_ttl = 30s
> postscreen_dnsbl_max_ttl = 30s
> postscreen_dnsbl_threshold = 8
> postscreen_dnsbl_action = enforce
> postscreen_greet_action = enforce
> postscreen_greet_wait = 10
>
> postscreen_dnsbl_sites = dnsbl.sorbs.net=127.0.0.10*9
> dnsbl.sorbs.net=127.0.0.14*9
> zen.spamhaus.org=127.0.0.[10;11]*8
> dnsbl.sorbs.net=127.0.0.5*7
> zen.spamhaus.org=127.0.0.[4..7]*7
> b.barracudacentral.org=127.0.0.2*7
> zen.spamhaus.org=127.0.0.3*7
> dnsbl.inps.de=127.0.0.2*7
> hostkarma.junkemailfilter.com=127.0.0.2*4
> dnsbl.sorbs.net=127.0.0.7*4
> bl.spameatingmonkey.net=127.0.0.[2;3]*4
> dnsrbl.swinog.ch=127.0.0.3*4
> ix.dnsbl.manitu.net=127.0.0.2*4
> psbl.surriel.com=127.0.0.2*4
> bl.spamcop.net=127.0.0.2*4
> bl.mailspike.net=127.0.0.[10;11;12]*4
> bl.mailspike.net=127.0.0.2*4
> zen.spamhaus.org=127.0.0.2*3
> dnsbl.sorbs.net=127.0.0.6*3
> dnsbl.sorbs.net=127.0.0.8*2
> hostkarma.junkemailfilter.com=127.0.0.4*2
> dnsbl.sorbs.net=127.0.0.9*2
> dnsbl-1.uceprotect.net=127.0.0.2*2
> all.spamrats.com=127.0.0.38*2
> bl.nszones.com=127.0.0.[2;3]*1
> dnsbl-2.uceprotect.net=127.0.0.2*1
> dnsbl.sorbs.net=127.0.0.2*1
> dnsbl.sorbs.net=127.0.0.4*1
> dnsbl.sorbs.net=127.0.0.3*1
> hostkarma.junkemailfilter.com=127.0.1.2*1
> dnsbl.sorbs.net=127.0.0.15*1
> ips.backscatterer.org=127.0.0.2*1
> bl.nszones.com=127.0.0.5*-1
> wl.mailspike.net=127.0.0.[18;19;20]*-2
> hostkarma.junkemailfilter.com=127.0.0.1*-2
> ips.whitelisted.org=127.0.0.2*-2
> list.dnswl.org=127.0.[0..255].0*-2
> dnswl.inps.de=127.0.[0;1].[2..10]*-2
> list.dnswl.org=127.0.[0..255].1*-3
> list.dnswl.org=127.0.[0..255].2*-4
> list.dnswl.org=127.0.[0..255].3*-5
Re: subscribe to blacklist for domains
Posted by joe a <jo...@j4computers.com>.
Ah, thanks for describing that. I am somewhat more brain fogged than
usual this morning, so am uncertain any of those would work in this
configuration. But I certainly need to look deeper. At least into my
coffee mug.
This is a low volume system consisting of postfix, SA, clamav and
fetchmail.
The mailserver (postfix) is not exposed to the internet, mail traffic is
sent to it by "fetchmail", which itself goes out to several providers
where mail accounts reside.
My first thought was, the postfix stuff would work, because . . . then I
realized, I've not looked at those solutions for some time, if ever. So,
I should stop here and look them over.
However, any real world "we did that" exists, please let me know.
joe a.
On 8/13/2022 9:52 AM, Bert Van de Poel wrote:
> I think what Noel is referring to is Postfix configuration like this for
> example:
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated, reject_unauth_destination, reject_rbl_client
> zen.spamhaus.org, reject_rhsbl_reverse_client dbl.spamhaus.org,
> reject_rhsbl_helo dbl.spamhaus.org, reject_rhsbl_sender
> dbl.spamhaus.org, reject_non_fqdn_recipient,
> reject_unknown_recipient_domain
>
> Notice the spamhaus links for different blocklist settings.
>
> On 13/08/2022 15:38, joe a wrote:
>> On 8/12/2022 11:43 PM, Noel Butler wrote:
>>> Why are you not blocking with blacklists at the border, ie: MTA.
>>
>> I'm not familiar with how to do that or if it can be done. Since SA
>> offers this functionality, so did not even consider that. I'll look
>> into it.
>>
>>> Given its 0 resources for your MTA, with anti spam checking on SA
>>> often using significant resources (depending on traffic/number of
>>> tests/rules etc), its best to stop it getting to SA in the first place.
>>>
>>> SA also has this by-default list of domains that it never checks, for
>>> along time I have disagreed with this, we are the ones to decide who
>>> gets whitelisted not SA, not some paid third party, the option
>>> clear_uridnsbl_skip_domain however prevents this, but then you have
>>> to locate and 0 all the general rulesets scores that are whitelists
>>> as well.
>>>
>>
>> The configuration/usage of those lists causes me great frustration.
>> Semi retirement and infrequent "tech stuff" may be partly to blame.
>>
>>
>
Re: subscribe to blacklist for domains
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 13.08.22 15:52, Bert Van de Poel wrote:
>I think what Noel is referring to is Postfix configuration like this
>for example:
>smtpd_recipient_restrictions = permit_mynetworks,
>permit_sasl_authenticated, reject_unauth_destination,
>reject_rbl_client zen.spamhaus.org, reject_rhsbl_reverse_client
>dbl.spamhaus.org, reject_rhsbl_helo dbl.spamhaus.org,
>reject_rhsbl_sender dbl.spamhaus.org, reject_non_fqdn_recipient,
>reject_unknown_recipient_domain
>
>Notice the spamhaus links for different blocklist settings.
for using blocklists at MTA level with postfix, using postscreen is much
better variant.
with pregreet pause, it also drops big number of spambots.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Christian Science Programming: "Let God Debug It!".
Re: subscribe to blacklist for domains
Posted by Bert Van de Poel <be...@ulyssis.org>.
I think what Noel is referring to is Postfix configuration like this for
example:
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination, reject_rbl_client
zen.spamhaus.org, reject_rhsbl_reverse_client dbl.spamhaus.org,
reject_rhsbl_helo dbl.spamhaus.org, reject_rhsbl_sender
dbl.spamhaus.org, reject_non_fqdn_recipient, reject_unknown_recipient_domain
Notice the spamhaus links for different blocklist settings.
On 13/08/2022 15:38, joe a wrote:
> On 8/12/2022 11:43 PM, Noel Butler wrote:
>> Why are you not blocking with blacklists at the border, ie: MTA.
>
> I'm not familiar with how to do that or if it can be done. Since SA
> offers this functionality, so did not even consider that. I'll look
> into it.
>
>> Given its 0 resources for your MTA, with anti spam checking on SA
>> often using significant resources (depending on traffic/number of
>> tests/rules etc), its best to stop it getting to SA in the first place.
>>
>> SA also has this by-default list of domains that it never checks, for
>> along time I have disagreed with this, we are the ones to decide who
>> gets whitelisted not SA, not some paid third party, the option
>> clear_uridnsbl_skip_domain however prevents this, but then you have
>> to locate and 0 all the general rulesets scores that are whitelists
>> as well.
>>
>
> The configuration/usage of those lists causes me great frustration.
> Semi retirement and infrequent "tech stuff" may be partly to blame.
>
>
Re: subscribe to blacklist for domains
Posted by joe a <jo...@j4computers.com>.
On 8/12/2022 11:43 PM, Noel Butler wrote:
> Why are you not blocking with blacklists at the border, ie: MTA.
I'm not familiar with how to do that or if it can be done. Since SA
offers this functionality, so did not even consider that. I'll look into it.
> Given its 0 resources for your MTA, with anti spam checking on SA often
> using significant resources (depending on traffic/number of tests/rules
> etc), its best to stop it getting to SA in the first place.
>
> SA also has this by-default list of domains that it never checks, for
> along time I have disagreed with this, we are the ones to decide who
> gets whitelisted not SA, not some paid third party, the option
> clear_uridnsbl_skip_domain however prevents this, but then you have to
> locate and 0 all the general rulesets scores that are whitelists as well.
>
The configuration/usage of those lists causes me great frustration.
Semi retirement and infrequent "tech stuff" may be partly to blame.
Re: subscribe to blacklist for domains
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 13.08.22 13:43, Noel Butler wrote:
>Why are you not blocking with blacklists at the border, ie: MTA.
one can block at MTA level, but blocklists are usable on multiple headers,
not just on the incoing IP address.
>On 13/08/2022 09:55, joe a wrote:
>>I need to refresh my brain on using blacklists with SA, before
>>looking more deeply into why this got through.
>>
>>Today a email slipped through with a very low score that was clearly
>>phishy. A url in question, posing as another, hits no less that 6
>>blacklists. I was going to look at clamav that is in use here, as I
>>had just been tuning that a bit and realized that that may be using
>>a hammer to drive a screw. so to speak.
>>
>>Or are they passe these days?
show us the headers and possibly the IP. not here, use pastebin or similar
service.
you may need to have trusted_networks and internal_networks configured
properly.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Save the whales. Collect the whole set.
Re: subscribe to blacklist for domains
Posted by Noel Butler <no...@ausics.net>.
Why are you not blocking with blacklists at the border, ie: MTA.
Given its 0 resources for your MTA, with anti spam checking on SA often
using significant resources (depending on traffic/number of tests/rules
etc), its best to stop it getting to SA in the first place.
SA also has this by-default list of domains that it never checks, for
along time I have disagreed with this, we are the ones to decide who
gets whitelisted not SA, not some paid third party, the option
clear_uridnsbl_skip_domain however prevents this, but then you have to
locate and 0 all the general rulesets scores that are whitelists as
well.
On 13/08/2022 09:55, joe a wrote:
> I need to refresh my brain on using blacklists with SA, before looking
> more deeply into why this got through.
>
> Today a email slipped through with a very low score that was clearly
> phishy. A url in question, posing as another, hits no less that 6
> blacklists. I was going to look at clamav that is in use here, as I
> had just been tuning that a bit and realized that that may be using a
> hammer to drive a screw. so to speak.
>
> Or are they passe these days?
--
Regards,
Noel Butler
This Email, including attachments, may contain legally privileged
information, therefore at all times remains confidential and subject to
copyright protected under international law. You may not disseminate
this message without the authors express written authority to do so.
If you are not the intended recipient, please notify the sender then
delete all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.