On 02/16/2014 11:32 AM, Wicus Roets wrote:
That explains is quite nicely.
One more question though ;)
Quoting from "http://gmane.org/post.php"; - " People who do not have valid
email addresses in their From or Reply-To headers can't use Gmane to post to
mailing lists."
That's (primarily) because gmane doesn't have accounts with passwords.
It uses the From/Reply-To to verify that an address exists, when the
first message from an account is sent to the list. This is akin to
adding an account.
From my earlier mail, qmail accepts mail based only on the "rcpt to:" of the
header. As an interim, would inclusion of verification on the "mail from:"
be easier/quicker ?
I'm not sure what you mean by this. qmail accepts mail (for relay) based
on authentication (valid account/pw pair).
I don't think that verifying the "mail from" is always practical, but I
know that SamC is considering adding some such capability to spamdyke. I
think we should wait and see what he comes up with for that. QMT doesn't
presently use spamdyke on port 587, but it soon will. spamdyke v5.0 was
just released, and once it's deemed stable (by me), QMT will use it to
handle authentication (on port 587).
--
-Eric 'shubes'
Thanks
-----Original Message-----
From: Eric Shubert [mailto:[email protected]]
Sent: 16 February 2014 08:14 PM
To: [email protected]
Subject: [qmailtoaster] Re: Spamming via valid vpopmail account
On 02/16/2014 10:20 AM, Wicus Roets wrote:
In favour of myself and some else referring to this mail list in
future, would you mind elaborating on qmail-remote throttling? (until
the "offending/spamming user" feature gets implemented)
Presently, qmail-remote has no throttle other than the concurrencyremote
setting, which simply limits the number of external connections that can
happen at once.
In the event that a spammer (or perhaps even a legitimate user) submits a
boatload of messages, qmail-remote dutifully processes messages as quickly
as it possibly can (given the concurrencyremote constraint). I think
everyone would agree that qmail-remote is not well behaved when this occurs.
The idea of a throttle for qmail-remote came to me from gmane.org, the list
to news gateway (which I use and highly recommend).
http://gmane.org/post.php says:
4. No more than one message is sent per user per five minutes. If you post
more than one message per five minutes, the messages are spooled and sent
out later. No action is required from you.
IMO, this is brilliant. While it doesn't block spam entirely, it prohibits a
spam flood, while providing the ability to automatically detect an "event"
and take corrective action.
The qmail-remote throttle I have written a spec for would simply have a rate
limit, being the number of seconds required to elapse between sending out
messages from the same account. qmail-remote would keep track of the when
the last message was sent for each account, and would only send the next
message from each account after the rate limit has been reached (as
gmane.org presently does). The rate limit would be specified by host,
domain, and/or user account. It could also be unlimited (as things are now).
Once the qmail-remote throttle is in place, it'd be a relatively simple
matter (for some of us) to write a script which would detect an event, block
the account, and clean up the queue. The key (and more
complicated) part of all this is the patch for qmail-remote though, which
would need to be written in C. I could do this, but it would take some doing
(it's been a while since I've written much C code).
So there you have it. Questions?
--
-Eric 'shubes'
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
