Mailing List Archive

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.

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.

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

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.

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

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

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

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

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

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.

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

On 2022-08-12 at 23:43:48 UTC-0400 (Sat, 13 Aug 2022 13:43:48 +1000)
Noel Butler <noel.butler@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

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

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 <vincent@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)

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.

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.

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.

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 <vincent@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)

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

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.

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

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

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

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.