On Sat, 09 Sep 2023 18:13:24 -0400, Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:

> Le 09-09-2023, David W. Hodgins <dwhodgins@nomail.afraid.org> a écrit :
>>
>> Keep in mind that uceprotect recommends that the level 3 list only be used
>> for scoring, not for blocking, and it may be that the merchant configured
>> their server to use spam scoring.
>
> The issue I saw with my email server, it's the reason I said it's
> maintained by morons and no-brainers, is that it's used for blocking and
> not for scoring. I agree with the purpose, but the fact is the reality
> is not to follow the purpose but the easy way in blocking and not
> scoring.

It may have been using scoring to determine when to block.

Having an ip address included in the level 3 list gives a likely hood of being
spam a core of X.

Having a generic customer dns name rather then having your own domain name (with
matching reverse dns) gives a likely hood of being spam a score of Y.

Neither X nor Y may exceed the level that they have configured there server to
reject, but the combination of X+Y does.

Regards, Dave Hodgins

On Sat, 09 Sep 2023 18:24:15 -0400, Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:

> Le 09-09-2023, David W. Hodgins <dwhodgins@nomail.afraid.org> a écrit :
>>
>> The ip address is obtained during the tcp connection to the server. That
>> cannot be forged (when tcp is implemented properly).
>
> I don't understand the parenthesis part. For me, it's easy to forge the
> ip, but if it works with udp, as you don't receive the answer, it won't
> work wit tcp.
>
> So you mean you can forge your ip address and it can work if tcp is not
> implemented properly? How so? By guessing the answer? Buy spying on the
> connection? Another way?

By not properly implemented, I'm referring to systems (if any still exist)
that do not implement RFC 1948.

https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Vulnerabilities

Regards, Dave Hodgins

Am 09.09.2023 um 15:05:08 Uhr schrieb David W. Hodgins:

> On Sat, 09 Sep 2023 09:47:19 -0400, Marco Moock
> <mm+usenet-es@dorfdsl.de> wrote:
>
> > Am 09.09.2023 um 07:43:51 Uhr schrieb bad sector:
> >
> >> I don't agree that there a is no other way to get to spammers; I
> >> don't wanna start a political sidebar but hadn't Osama been laid by
> >> team-6?
> >
> > Completely different situation.
> > How do you identify who (person) exactly sent the spam mails?
>
> There is no attempt to identify the person when blocking based on ip
> address.
>
> The ip address is obtained during the tcp connection to the server.
> That cannot be forged (when tcp is implemented properly).

I know this, but the question was about badsector´s idea to sue the
people sending spam.

> There is no way to guarantee which person did what when connecting
> over the internet. The best you can do is say it's a person who has a
> password or other identifying info, associated with a specific person.

Right.

> That's why voting over internet can never be secure. While the ip
> address can not be forged, there is no way to prove who is at the
> keyboard, or even if it is being controlled by the person at the
> keyboard.

True.

> Even if they are the person they claim to be, they may be under
> duress (for example, having a gun to their head), or the system may
> be remotely controlled.

The latter one is default for most spamming machines.

Am 09.09.2023 um 22:24:15 Uhr schrieb Stéphane CARPENTIER:

> Le 09-09-2023, David W. Hodgins <dwhodgins@nomail.afraid.org> a écrit
> :
> >
> > The ip address is obtained during the tcp connection to the server.
> > That cannot be forged (when tcp is implemented properly).
>
> I don't understand the parenthesis part. For me, it's easy to forge
> the ip, but if it works with udp, as you don't receive the answer, it
> won't work wit tcp.
>
> So you mean you can forge your ip address and it can work if tcp is
> not implemented properly? How so? By guessing the answer? Buy spying
> on the connection? Another way?

Forging the IP isn't possible when you want to receive packages.
IP forging is done to make somebody else receive the answers.
E.g. they use DNS, because the answers are sometimes much bigger than
the request.
You do that with many machines and the victim will receive all the
replies and maybe it goes down because of too much traffic.
The DNS operator cannot detect that the IP is forged.

For sending spam, people rent servers, use public networks or hack into
other peoples machines/use improperly configured servers.

Am 09.09.2023 um 18:40:22 Uhr schrieb David W. Hodgins:

> By not properly implemented, I'm referring to systems (if any still
> exist) that do not implement RFC 1948.
>
> https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Vulnerabilities

This makes it much harder to send a segment to the victim that the
victim accepts. All current systems should have it implemented.

Although, if the real system replies to the ACK packages sent in reply
to the forged packages, the TCP server should close/reset the connection
because the real server didn't establish it and replies with ACK RST.
Or is my guess wrong?

Am 09.09.2023 um 22:13:24 Uhr schrieb Stéphane CARPENTIER:

> I agree with the purpose, but the fact is the reality
> is not to follow the purpose but the easy way in blocking and not
> scoring.

Which other facts should be used for scoring?
Multiple dnsbl?

Le 10-09-2023, Marco Moock <mm+usenet-es@dorfdsl.de> a écrit :
> Am 09.09.2023 um 22:13:24 Uhr schrieb Stéphane CARPENTIER:
>
>> I agree with the purpose, but the fact is the reality
>> is not to follow the purpose but the easy way in blocking and not
>> scoring.
>
> Which other facts should be used for scoring?
> Multiple dnsbl?

I don't remember everything I did my configuration years ago. But there
are a lot of things to check when you configure your server. Those
checks could be done by the receiver, too. There are the DMARC, SPF and
DKIM for a start. There are some white lists which can be used. You can
see if you have the sender email in some address book on your side. You
can keep an history, to see if the IP is changing with every email for
example. The content of the mail can be checked too.

The grey list (ie: you ask the sender to send the email again in some
time) is pretty good too, even if it's not a score.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Le 10-09-2023, Marco Moock <mm+usenet-es@dorfdsl.de> a écrit :
> Am 09.09.2023 um 22:24:15 Uhr schrieb Stéphane CARPENTIER:
>
>> Le 09-09-2023, David W. Hodgins <dwhodgins@nomail.afraid.org> a écrit
>> :
>> >
>> > The ip address is obtained during the tcp connection to the server.
>> > That cannot be forged (when tcp is implemented properly).
>>
>> I don't understand the parenthesis part. For me, it's easy to forge
>> the ip, but if it works with udp, as you don't receive the answer, it
>> won't work wit tcp.
>>
>> So you mean you can forge your ip address and it can work if tcp is
>> not implemented properly? How so? By guessing the answer? Buy spying
>> on the connection? Another way?
>
> Forging the IP isn't possible when you want to receive packages.

I know that, it's why I was surprised by the content of his parenthesis
which imply otherwise.

> IP forging is done to make somebody else receive the answers.

Yes, it was the first part of his answer. The other parts imply the
sender is spying the receiver, so he doesn't need to receive the answer
because he can see its content. But if it's good to attack someone, it's
way too heavy (ie: the cost is too high) for a spammer.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

On 9/9/23 09:47, Marco Moock wrote:
> Am 09.09.2023 um 07:43:51 Uhr schrieb bad sector:
>
>> I don't agree that there a is no other way to get to spammers; I
>> don't wanna start a political sidebar but hadn't Osama been laid by
>> team-6?
>
> Completely different situation.
> How do you identify who (person) exactly sent the spam mails?
>
> There is NAT, CG-NAT, a whole /48 net for a customer that is being used
> by many people (family, guests, maybe neighbors).
> More efficient is to put put pressure on server operators that sent out
> spam, regardless from where it came to that server.
> This pressure will ensure that the operator takes care about it and
> tries to limit abuse. Nobody complains when 1 spam mail goes out, but
> if 100000 got out, it will be on blacklists.

I cannot step into the techno-tunnel; assuming that blanket blacklisting
is the only way then automated protocol should exist at he
blacklist-subscribers' (merchants or whoever) end to immediately
neutralize (unlist) email addresses of customers or such others that are
already in their address-book so to speak and who are therefore innocent
victims of THEIR irresposible subscription to carpet-bombing. If such
automated unlisting costs money then THEY should pay for it and pass it
on in prices as part of the cost of doing business in the freakin'
swamp. This could still feed an extorsion racket but at least it would
exempt those innocent victims who are already engaged in costly
processes, it being _theoretically_ less of a costwise injustice to be
blocked from an addressee that one is attempting to contact for a first
time. Then, if an extorsion racket grows it can be dealt with then.

>> Again the onus is on innocent victims to either wait or complain and
>> TRY to delist (often for extortion money).
>
> Fully agree, but that is the problem whit shared address ranges.
> Get your own ASN with your own nets and activity of others won't have
> impact on you.

That's waaaaay too much overhead for small operators and again it hits
exactly the wrong targets!

>> But if you look at it from a practical and functional point of view
>> and not from a that of a hobby-internaut prowling for virtual pussy
>> then even a few hours delay can be *devastating*. I've DUMPED isp's
>> because of frequent interruptions lasting only tens of minutes. This
>> is an extremely serious and offensive demonstration of arrogance the
>> result of which on innocent victims is equal to cutting their
>> electricity in the middle of winter (the internet is no longer just
>> another TV channel). We don't carpet-bomb any more either (I think).
>
> I agree that this situation is really, really bad for individual
> innocent customers.

It's gonna be worse for the subscribers, as I have just done to one.

>> Offing onto the recipient with the copout that they are the ones who
>> close their mailbox is equivalent to "we give loaded guns to kids and
>> they do whatever it is that they do with them" (kids being a very good
>> analogy because most recipients haven't got a freakin' clue about
>> anything IT really).
>
> Thats SMTP. Mail is controlled by domains and the MX servers are
> related to the domain and not only the recipient.
> A good mail provider offers to control the spam filter per customer, so
> maybe it is possible to enable a setting "accept ALL mail to my
> address".

You mean "except all mail from addresses in my addressbook" as in
existing contacts or customers? Something like that COULD be part of a
solution. In a sense that's already available (based on what my
supplier's IT guy told me i.e that they receive every day a list of
blocked addresses sent to them). That's just ONE of my comments to the
supplier "you chose to expose me to your carpet-bombing and even when
you KNEW that I'd ben hit you AGAIN CHOSE not to immediately unlist me
so fuck you".

> Although, not all provider have such an option.
> Mail transfer agents like sendmail support such situations.

On 9/10/23 07:22, bad sector wrote:
> On 9/9/23 09:47, Marco Moock wrote:
>> Am 09.09.2023 um 07:43:51 Uhr schrieb bad sector:
>>
>>> I don't agree that there a is no other way to get to spammers; I
>>> don't wanna start a political sidebar but hadn't Osama been laid by
>>> team-6?
>>
>> Completely different situation.
>> How do you identify who (person) exactly sent the spam mails?
>>
>> There is NAT, CG-NAT, a whole /48 net for a customer that is being used
>> by many people (family, guests, maybe neighbors).
>> More efficient is to put put pressure on server operators that sent out
>> spam, regardless from where it came to that server.
>> This pressure will ensure that the operator takes care about it and
>> tries to limit abuse. Nobody complains when 1 spam mail goes out, but
>> if 100000 got out, it will be on blacklists.
>
> I cannot step into the techno-tunnel; assuming that blanket blacklisting
> is the only way then automated protocol should exist at he
> blacklist-subscribers' (merchants or whoever) end to immediately
> neutralize (unlist) email addresses of customers or such others that are
> already in their address-book so to speak and who are therefore innocent
> victims of THEIR irresposible subscription to carpet-bombing. If such
> automated unlisting costs money then THEY should pay for it and pass it
> on in prices as part of the cost of doing business in the freakin'
> swamp. This could still feed an extorsion racket but at least it would
> exempt those innocent victims who are already engaged in costly
> processes, it being _theoretically_ less of a costwise injustice to be
> blocked from an addressee that one is attempting to contact for a first
> time. Then, if an extorsion racket grows it can be dealt with then.
>
>
>>> Again the onus is on innocent victims to either wait or complain and
>>> TRY to delist (often for extortion money).
>>
>> Fully agree, but that is the problem whit shared address ranges.
>> Get your own ASN with your own nets and activity of others won't have
>> impact on you.
>
> That's waaaaay too much overhead for small operators and again it hits
> exactly the wrong targets!
>
>
>>> But if you look at it from a practical and functional point of view
>>> and not from a that of a hobby-internaut prowling for virtual pussy
>>> then even a few hours delay can be *devastating*. I've DUMPED isp's
>>> because of frequent interruptions lasting only tens of minutes. This
>>> is an extremely serious and offensive demonstration of arrogance the
>>> result of which on innocent victims is equal to cutting their
>>> electricity in the middle of winter (the internet is no longer just
>>> another TV channel). We don't carpet-bomb any more either (I think).
>>
>> I agree that this situation is really, really bad for individual
>> innocent customers.
>
> It's gonna be worse for the subscribers, as I have just done to one.
>
>
>>> Offing onto the recipient with the copout that they are the ones who
>>> close their mailbox is equivalent to "we give loaded guns to kids and
>>> they do whatever it is that they do with them" (kids being a very good
>>> analogy because most recipients haven't got a freakin' clue about
>>> anything IT really).
>>
>> Thats SMTP. Mail is controlled by domains and the MX servers are
>> related to the domain and not only the recipient.
>> A good mail provider offers to control the spam filter per customer, so
>> maybe it is possible to enable a setting "accept ALL mail to my
>> address".
>
> You mean "except

read "accept" :-)

> all mail from addresses in my addressbook" as in
> existing contacts or customers? Something like that COULD be part of a
> solution. In a sense that's already available (based on what my
> supplier's IT guy told me i.e that they receive every day a list of
> blocked addresses sent to them). That's just ONE of my comments to the
> supplier "you chose to expose me to your carpet-bombing and even when
> you KNEW that I'd ben hit you AGAIN CHOSE not to immediately unlist me
> so fuck you".
>
>
>> Although, not all provider have such an option.
>> Mail transfer agents like sendmail support such situations.
>
>
>
>
>
>
>
>

Am 10.09.2023 um 07:22:15 Uhr schrieb bad sector:

> On 9/9/23 09:47, Marco Moock wrote:
> > Am 09.09.2023 um 07:43:51 Uhr schrieb bad sector:
> >
> >> I don't agree that there a is no other way to get to spammers; I
> >> don't wanna start a political sidebar but hadn't Osama been laid by
> >> team-6?
> >
> > Completely different situation.
> > How do you identify who (person) exactly sent the spam mails?
> >
> > There is NAT, CG-NAT, a whole /48 net for a customer that is being
> > used by many people (family, guests, maybe neighbors).
> > More efficient is to put put pressure on server operators that sent
> > out spam, regardless from where it came to that server.
> > This pressure will ensure that the operator takes care about it and
> > tries to limit abuse. Nobody complains when 1 spam mail goes out,
> > but if 100000 got out, it will be on blacklists.
>
> I cannot step into the techno-tunnel; assuming that blanket
> blacklisting is the only way then automated protocol should exist at
> he blacklist-subscribers' (merchants or whoever) end to immediately
> neutralize (unlist) email addresses of customers or such others that
> are already in their address-book so to speak and who are therefore
> innocent victims of THEIR irresposible subscription to
> carpet-bombing.

Some provider offer that service, others don't. The only way out of
that is operating the server yourself or look for a company that
provides a service where decisions can be made per recipient address.

> If such automated unlisting costs money then THEY should pay for it
> and pass it on in prices as part of the cost of doing business in the
> freakin' swamp.

I agree.
> This could still feed an extorsion racket but at
> least it would exempt those innocent victims who are already engaged
> in costly processes, it being _theoretically_ less of a costwise
> injustice to be blocked from an addressee that one is attempting to
> contact for a first time. Then, if an extorsion racket grows it can
> be dealt with then.
>
>
> >> Again the onus is on innocent victims to either wait or complain
> >> and TRY to delist (often for extortion money).
> >
> > Fully agree, but that is the problem whit shared address ranges.
> > Get your own ASN with your own nets and activity of others won't
> > have impact on you.
>
> That's waaaaay too much overhead for small operators and again it
> hits exactly the wrong targets!

True, it is a huge task, although this is the ONLY way to prevent
overblocking because of bad or non-existent abuse management.

I run my own mail server at home with a small ISP. They have abuse
management.

> >> Offing onto the recipient with the copout that they are the ones
> >> who close their mailbox is equivalent to "we give loaded guns to
> >> kids and they do whatever it is that they do with them" (kids
> >> being a very good analogy because most recipients haven't got a
> >> freakin' clue about anything IT really).
> >
> > Thats SMTP. Mail is controlled by domains and the MX servers are
> > related to the domain and not only the recipient.
> > A good mail provider offers to control the spam filter per
> > customer, so maybe it is possible to enable a setting "accept ALL
> > mail to my address".
>
> You mean "except all mail from addresses in my addressbook" as in
> existing contacts or customers?

Would be possible too, but it is also possible to simply exclude
recipient address from mail filtering.

On 2023-09-09 07:59, Marco Moock wrote:
> Am 09.09.2023 um 07:41:45 Uhr schrieb Carlos E. R.:
>> On 2023-09-09 07:18, Marco Moock wrote:
>>> Am 07.09.2023 um 22:36:30 Uhr schrieb Carlos E. R.:
>>>> On 2023-09-07 20:01, bad sector wrote:
>>>>> On 9/7/23 15:24, J.O. Aho wrote:
>>>>>> On 07/09/2023 18:09, bad sector wrote:

....

>>>> Also, the received headers can be investigated. The last one is
>>>> always true, because it is your own mail server.
>>>
>>> Only this one can be trusted, the rest can be forged.
>>
>> Not a problem. You investigate each of them one by one, going
>> backwards, determining which are true and which is the first forged
>> one.
>
> You cannot log everything. E.g. a restaurant operates a public wifi.
> Any customer can abuse it for sending spam, hacking other computers
> with it and using them for sending spam.

That's not a problem.

There is a good server somewhere, possibly badly configured, which
accepted the mail from the compromised machine. And this good server
would log the event.

That good server would be fined. And the IP of the compromised machine
would be logged, then located by the police, and fined or confiscated
(even if the IP is dynamic).

(with the assumption of full international cooperation and intent on
killing spam, which we know will not happen)

>> (with the assumption of full international cooperation and intent on
>> killing spam, which we know will not happen)
>
> It also doesn't work on a national basis, as long as there is no 100%
> surveillance of EVERY network, even home networks.
> And then you still have problems because you need to identify the user.
> Think about public access points.

Not a problem.

You don't even need 100% surveillance.

--
Cheers,
Carlos E.R.

On 2023-09-09 09:29, Stéphane CARPENTIER wrote:
> Le 09-09-2023, Marco Moock <mm+usenet-es@dorfdsl.de> a écrit :
>> Am 09.09.2023 um 07:41:45 Uhr schrieb Carlos E. R.:
>>
>>> Not a problem. You investigate each of them one by one, going
>>> backwards, determining which are true and which is the first forged
>>> one.
>>
>> You cannot log everything. E.g. a restaurant operates a public wifi.
>> Any customer can abuse it for sending spam, hacking other computers
>> with it and using them for sending spam.
>
> Yes, but people won't spend hours to go hundreds kilometers between each
> email. So, you can find a few public points in a restricted area where
> all emails are sent to discover the sender.
>
> For email spams, it's a lot of work, but say in a murder case, the work
> would be done. As he says, it's really a matter of choice. I'm not
> saying the spam should be consider more important than murders. I'm only
> saying a lot of effort are put to resolve murders, and nothing is done
> against spam. I just agree with him it's a choice. I'm not saying the
> choice is wrong.
>
>> And then you still have problems because you need to identify the user.
>> Think about public access points.
>
> That's his main point: it's not a problem for him. As he rightly stated,
> the beneficiary must have a way to be contacted, if he doesn't the spam
> is useless.
>
> There are two things to consider.
>
> The first one: if I want to harm someone, I could sent spam making
> believe this someone did it. It's a little bit tricky. I know: in the
> actual spamming system it just doesn't exist. But if more effort would
> be made against spam it could arrise. So, it must be taken care off.
>
> The second one: all spam is about money. They sent spam to win money. So
> the cost of sending spam must be less than the money received. And it's
> the all point. As nothing is done against spammers, the cost is very
> low. I know, when you receive spam, you know what it is and you aren't a
> bait. But if only one people in ten thousand is naive enough to believe
> it, once they sent one hundred thousand emails, then ten people must be
> answering them. And the ten people must pay for the cost of sending the
> nine hundred and ninety thousand lost emails. So, if you increase the
> cost of the sending emails, the ten people are stupid enough to believe
> it, but they are not rich enough to compensate your costs.
>
> And it's his point, with which I agree: the spammers need to be sure the
> ten people are able to sent them money. Without this certainty, the all
> money for sending spam is lost. And remember: the ten people are naive
> enough to believe the spam, so the way to send money must be easy enough
> to be useful. You can't ask people to be naive enough to believe in your
> mail and to be smart enough to find difficult ways to send you money.
>
> On it, I agree with him: if everyone would want to stop spam, spammers
> could be prosecuted, it's only a matter of choice. But as he said, you
> will never find someone willing to do whatever it takes to prosecute all
> spammers. And for me, there is no reason to, I understand there are more
> important issues at the same time.
>
> But, for me, just increasing the cost of the spammers would be enough to
> stop it. I don't believe only if it becomes the first priority it will
> be stopped.

Yes, that is it.

>
> What I can tell is: when a spam network begins to be huge, it's stopped
> and I can see a decrease in spam. It's impressive, sometime I see less
> attack on my computer. I'm afraid I've being hacked and my computer is
> used behind my knowledge. And then I learn a massive network has been
> arrested and that explains it.
>
> So for the actual part, the little guys in their basement are safe and
> the effort is put on big companies (even if it's unofficial, we can call
> them that, the structure is the same).
>

--
Cheers,
Carlos E.R.

Am 10.09.2023 um 10:30:56 Uhr schrieb Carlos E. R.:

> On 2023-09-09 07:59, Marco Moock wrote:
> > Am 09.09.2023 um 07:41:45 Uhr schrieb Carlos E. R.:
> >> On 2023-09-09 07:18, Marco Moock wrote:
> >>> Am 07.09.2023 um 22:36:30 Uhr schrieb Carlos E. R.:
> >>>> On 2023-09-07 20:01, bad sector wrote:
> >>>>> On 9/7/23 15:24, J.O. Aho wrote:
> >>>>>> On 07/09/2023 18:09, bad sector wrote:
>
> ...
>
> >>>> Also, the received headers can be investigated. The last one is
> >>>> always true, because it is your own mail server.
> >>>
> >>> Only this one can be trusted, the rest can be forged.
> >>
> >> Not a problem. You investigate each of them one by one, going
> >> backwards, determining which are true and which is the first forged
> >> one.
> >
> > You cannot log everything. E.g. a restaurant operates a public wifi.
> > Any customer can abuse it for sending spam, hacking other computers
> > with it and using them for sending spam.
>
> That's not a problem.
>
> There is a good server somewhere, possibly badly configured, which
> accepted the mail from the compromised machine. And this good server
> would log the event.
>
> That good server would be fined. And the IP of the compromised
> machine would be logged, then located by the police, and fined or
> confiscated (even if the IP is dynamic).

A really bad idea. Nobody could no operate a server anymore without
a huge risk. Just remember how many Exchange servers are going to be
hacked or people have bad passwords that are being cracked.

On 2023-09-09 08:42, Stéphane CARPENTIER wrote:
> Le 09-09-2023, Marco Moock <mm+usenet-es@dorfdsl.de> a écrit :
>>> There are many kinds of spam.
>>>
>>> On the spam that tries to sell you "something", there is always a way
>>> to identify them, because obviously you need to contact them somehow
>>> to buy whatever. BUT, you need international cooperation, police
>>> forces and courts. ALL countries.
>>>
>>> So, if all governments wanted, they could kill spam by simply putting
>>> in prison every spammer they find, one by one.
>>
>> This doesn't work, because IP addresses can be used by multiple people,
>> machines can be hacked, etc..
>
> He doesn't spoke about the IP of the sender, but of the way to contact
> him. And somehow, he's right about it. If the IP of the sender is the
> only way to contact him, then if I wait to long before getting in touch
> with him, I wouldn't be able to, so the sender lost a potential client.
>
> So the sender would need a valid and permanent link to be able to be
> contacted by the receiver.
>
> The issue with his argument is: I could sent spam with a link toward
> someone else and the someone else would be prosecuted instead of me.
> There are some ways around it, but it's a good start.

Yeah, well, that's what good police work is about :-)

>
>>> Also, the received headers can be investigated. The last one is
>>> always true, because it is your own mail server.
>>
>> Only this one can be trusted, the rest can be forged.
>
> Yes, it's the starting point from the next move.
>
>>> So you trace backwards, one by one... at some point, you need police
>>> and court cooperation from the countries traversed by the mail, you
>>> need the police going to that server and demanding the logs by force.
>>> In the end, after a lot of money, you can find someone to put in
>>> prison.
>>
>> These headers are no evidence, they can be forged like mail addresses
>> or display names.
>
> As he said the last IP is real, if you forge your IP, you won't receive
> answer. So it could work with UDP but not with TCP and emails are only
> with TCP.
>
> So you don't look at the IP before the last one. But you get in touch
> with the last one and ask him for logs to know who was the before the
> last one. And one by one, you can go back to the sender. The last issue
> is the sender can be in a public place, like a MacDo, using a free IP
> unable to know who used his service. Another issue, every intermediate
> server can be in different countries, not all wanting to cooperate at
> the same level.

Exactly, so killing spam needs international cooperation.

In any case the spam post will have a true email address, URL, mail
address, phone... something that is true in order to place the purchase
order. You only need to go for that one and ignore the rest.

It may be valid for a limited time, though. Even so, if the police of
the country accesses that mail server, they might track the "merchant".

>
>>> Certainly, it may be coming from a compromised machine of some poor
>>> sod. Well, he must be fined for having a machine compromised, for not
>>> paying maintenance, for having faulty providers like M$.
>>
>> Have fun fining millions of people with malware on their machines.
>
> It's not only fun, it's a lot of money: you don't want to secure your
> computer? You pay, and if a million people have to pay it can be a lot
> of money in the end.
>
> It's what France tried to do with the hadopi law. In the beginning, the
> law was: you are downloading a lot illegal stuff, it comes from your IP
> so we don't need to know more about it, we remove your internet access.
>
> But, happily, it was blocked by the EU and the law was changed. Now it's:
> you have not secured the access to your connection, so someone used it
> to download illegal stuff, so you are charged. It's not better, but the
> law changed to acknowledge it. Happily, it's not used as much as it
> could.

Right.

>
>>> But we will not get that level of international cooperation.
>>
>> You cannot do that even in the same country.
>
> As he said, it's a choice. Nobody consider spam as important as other
> crimes. For other crimes, countries are cooperating. Not for spam, but
> it's only a choice.

Right.

--
Cheers,
Carlos E.R.

On 9/9/23 09:29, Stéphane CARPENTIER wrote:
> Le 09-09-2023, Marco Moock <mm+usenet-es@dorfdsl.de> a écrit :

> On it, I agree with him: if everyone would want to stop spam, spammers
> could be prosecuted, it's only a matter of choice. But as he said, you
> will never find someone willing to do whatever it takes to prosecute all
> spammers. And for me, there is no reason to, I understand there are more
> important issues at the same time.
>
> But, for me, just increasing the cost of the spammers would be enough to
> stop it. I don't believe only if it becomes the first priority it will
> be stopped.

THAT is the bottom line, authority simply doesn't care
so while I don't oppose hunting the spamers (with minimal
colateral) I'm not optimistic. The present crusade is
going to fail as more innocent people get hit so it's
fix the issue or forget it. The listers should get subscribers
to sign that they (in their OWN interest) will directly
and each time unlist addresses in good standing in their
database or they get no service (if this is doable).

On Sun, 10 Sep 2023 02:50:01 -0400, Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
> Which other facts should be used for scoring?
> Multiple dnsbl?

There are different levels of spam handling that can be done.

Before the connection attempt to the smtp server is made, every firewall on
every router in between the source and destination has to allow the traffic.

The firewalls can use a list of ip addresses to allow or to block, or on a lists
of other data related to the ip address such as the register, isp (asn level,
netblock level, etc), country, etc.

Think "Great firewall of China".

Once a connection to the smtp server is allowed by the firewalls, there
are three levels of checking, with increasing overhead at each level.
Those levels are ip address, header content, and body content.

The ip level checking can do the same checks as are possible at the firewall
level, and can also do checks based on things like teergrubing, sender callout
Verification ( see https://tldp.org/HOWTO/Spam-Filtering-for-MX/smtpdelays.html ),
forward/reverse dns lookups, being listed in uceprotect or other dnsbl,

If the connection to the mail server isn't blocked at the ip level checks, then
the headers of the message are transferred and processed. Header content checking
may include ...
- from address based rules or lists
- things like number of addresses in the to/cc headers.
- dkim
- spf

If the connection passes the header checking level, the body of the message is
transferred and checked. That checking may include things like malware detection,
specific urls being present, Having nothing but a url, etc.

At the smtp server each level may be used for scoring only, allow/blocking only,
or allow/blocking based on scoring. It can also impose limits on the number of
messages allowed in a given time period from any given source.

Regards, Dave Hodgins

On Sun, 10 Sep 2023 02:48:22 -0400, Marco Moock <mm+usenet-es@dorfdsl.de> wrote:

> Am 09.09.2023 um 18:40:22 Uhr schrieb David W. Hodgins:
>
>> By not properly implemented, I'm referring to systems (if any still
>> exist) that do not implement RFC 1948.
>>
>> https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Vulnerabilities
>
> This makes it much harder to send a segment to the victim that the
> victim accepts. All current systems should have it implemented.
>
> Although, if the real system replies to the ACK packages sent in reply
> to the forged packages, the TCP server should close/reset the connection
> because the real server didn't establish it and replies with ACK RST.
> Or is my guess wrong?

If it's working properly it should not be possible to forge the ip address
without cracking parts of the network (such as routers) in between the person's
system and and the system that owns the source address.

So implementing tcp properly means having the networking software up-to-date
not just on the person's computer and the source address, but on every router
in between them.

If any of them have 0day or unpatched bugs that allows the manipulation of the
data, then the ip address can still be forged.

With https://www.bgp.org/blog/vulnerabilities-of-bgp manipulation, re-direction
is still possible. The ip address isn't actually being forged in the tcp packet.
The ip address is just duplicated on a system that isn't supposed to that ip
address, and the traffic redirected. The real owner of that ip address never
sees the syn packet, or the rest of the traffic.

Regards, Dave hodgins

On Sun, 10 Sep 2023 15:07:45 -0400, bad sector <forgetski@_invalid.net> wrote:
> THAT is the bottom line, authority simply doesn't care
> so while I don't oppose hunting the spamers (with minimal
> colateral) I'm not optimistic. The present crusade is
> going to fail as more innocent people get hit so it's
> fix the issue or forget it. The listers should get subscribers
> to sign that they (in their OWN interest) will directly
> and each time unlist addresses in good standing in their
> database or they get no service (if this is doable).

While it's bad for the innocent people at the spam supporting isp, it's good
for the innocent people at the good isp that blocks the spam from the bad
isp who don't want spam filling their inboxes.

While the customer of the isp that blocked your messages has lost you as a
customer, their staff have much less spam to have to spend time sorting through
to find the email they do want. If they value your business more than they value
the time they have to spend dealing with spam, they are free to switch to a
different email provider.

Regards, Dave Hodgins

On 9/10/23 18:48, David W. Hodgins wrote:
> On Sun, 10 Sep 2023 15:07:45 -0400, bad sector <forgetski@_invalid.net>
> wrote:
>> THAT is the bottom line, authority simply doesn't care
>> so while I don't oppose hunting the spamers (with minimal
>> colateral) I'm not optimistic. The present crusade is
>> going to fail as more innocent people get hit so it's
>> fix the issue or forget it. The listers should get subscribers
>> to sign that they (in their OWN interest) will directly
>> and each time unlist addresses in good standing in their
>> database or they get no service (if this is doable).
>
> While it's bad for the innocent people at the spam supporting isp, it's
> good
> for the innocent people at the good isp that blocks the spam from the bad
> isp who don't want spam filling their inboxes.
>
> While the customer of the isp that blocked your messages has lost you as a
> customer, their staff have much less spam to have to spend time sorting
> through
> to find the email they do want. If they value your business more than
> they value
> the time they have to spend dealing with spam, they are free to switch to a
> different email provider.
>
> Regards, Dave Hodgins

The can do whatever they like, I already have.

Am 10.09.2023 um 16:03:58 Uhr schrieb David W. Hodgins:

> On Sun, 10 Sep 2023 02:50:01 -0400, Marco Moock
> <mm+usenet-es@dorfdsl.de> wrote:
> > Which other facts should be used for scoring?
> > Multiple dnsbl?
>
> There are different levels of spam handling that can be done.
>
> Before the connection attempt to the smtp server is made, every
> firewall on every router in between the source and destination has to
> allow the traffic.
>
> The firewalls can use a list of ip addresses to allow or to block, or
> on a lists of other data related to the ip address such as the
> register, isp (asn level, netblock level, etc), country, etc.

I think that is much worse than using dnsbl and rejecting with a
message that tells that the IP is listed.
I would only use that for servers that try to create a DoS.

Am 08.09.2023 um 06:21:45 Uhr schrieb Jasen Betts:

> Thus it's much better to refuse at SMTP time, read the refusal
> message there's usually enough data there.

Good server operators give back the information in which dnsbl the IP
is listed in the SMTP reject message, so the server operator can check
why he is listed there.

On Mon, 11 Sep 2023 09:44:03 -0400, Marco Moock <mm+usenet-es@dorfdsl.de> wrote:

> Am 08.09.2023 um 06:21:45 Uhr schrieb Jasen Betts:
>
>> Thus it's much better to refuse at SMTP time, read the refusal
>> message there's usually enough data there.
>
> Good server operators give back the information in which dnsbl the IP
> is listed in the SMTP reject message, so the server operator can check
> why he is listed there.

That adds overhead for the smtp server. If you don't expect to ever need to be
sending traffic to or getting traffic an ASN that generates a lot of spam,
blocking that ASN at the firewall level cuts down the load.

It's not nice if there are any people using that ASN if they have a valid reason
to send ip traffic to/from to you, but if there isn't anyone where that's true,
it cuts the load on the server.

I wouldn't be surprised of all of ovh (AS16276) is already blocked in many
firewalls due to their support of spam.

Regards, Dave Hodgins

David W. Hodgins wrote:
> I wouldn't be surprised of all of ovh (AS16276) is already blocked in
> many firewalls due to their support of spam.

The UCEProtect vs ASNs w/ a 'problem' reputation is 'widespread'.

That blocklist policy is that a listed comes off 'spontaneously' in a
week if the 'spam count' improves sufficiently -OR- there is a 'for pay'
express delisting which is faster, but it doesn't keep a big block
holder from getting re-listed quickly.

As a result of the payola aspect and the 'readiness' to list, those
whose IPs are affected want to call UCEProtect a 'scam'.

In the 'extensive' wp article comparing blocklists, UCEProtect is listed
in the 'suspect' group.

> Suspect RBL providers are those who employ well-documented
> patterns[3] of questionable or reckless practices[4] or have
> questionable actors based on statements or communications from the
> RBL's principal management to official forums.

https://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists

Naturally their tables of 'non-suspect' is MUCH more extensive than
those of suspect.

Of course, the old adage of 'my server, my rules' prevails here.

--
Mike Easter

On 2023-09-11 14:53, Mike Easter wrote:
> David W. Hodgins wrote:
>> I wouldn't be surprised of all of ovh (AS16276) is already blocked in
>> many firewalls due to their support of spam.
>
> The UCEProtect vs ASNs w/ a 'problem' reputation is 'widespread'.
>
> That blocklist policy is that a listed comes off 'spontaneously' in a
> week if the 'spam count' improves sufficiently -OR- there is a 'for pay'
> express delisting which is faster, but it doesn't keep a big block
> holder from getting re-listed quickly.
>
> As a result of the payola aspect and the 'readiness' to list, those
> whose IPs are affected want to call UCEProtect a 'scam'.
>
> In the 'extensive' wp article comparing blocklists, UCEProtect is listed
> in the 'suspect' group.
>
>> Suspect RBL providers are those who employ well-documented
>> patterns[3] of questionable or reckless practices[4] or have
>> questionable actors based on statements or communications from the
>> RBL's principal management to official forums.
>
> https://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists
>
> Naturally their tables of 'non-suspect' is MUCH more extensive than
> those of suspect.
>
> Of course, the old adage of 'my server, my rules' prevails here.
>

I put you on a blacklist, you buy yourself off it, THAT's a variant of
maffioso style extorsion. But that's not all..

"exploit: ...compromised, infected, proxies, or VPN or TOR exit nodes"

It's a declared war on privacy, just as I suspected. Now doesn't that
say it all? I only have one question left: which of the following are
behind it?

- zukerbarf
- googlegoons
- bezoos
- Billy
- all of the above

I just got off the list BTW.

--
Anonymity is the sole reliable witness of real society, be the image
good or bad, and of free speech, two things without which the truth
cannot be known but the intent of those opposing them can.