[Dovecot] help on writing a rule for perventing spam
Hi I used qmail + dovecot-1.1.7 + dovecot-sieve + .... now everything works well but there are many spam in Bulk folders from every user address to their address for example from user1@mydomain to user1@mydomain in the real the sender and reciever are the same . they are spam but since everyday , everyvirtual user has many of these spams in their Bulk i need a rule in dovecot.sieve to prevent them Can anybody help me for writing this rule.
with regards Sophia Alikhani WorkPhone: +98-21-8497057 Mobile : +98-912-3361036
On W 21 Jan, 2009, at 06:34 , Sophia Alikhani wrote:
Hi I used qmail + dovecot-1.1.7 + dovecot-sieve + .... now everything works well but there are many spam in Bulk folders from every user address to their address for example from user1@mydomain to user1@mydomain in the real the sender and reciever are the same . they are spam but since everyday , everyvirtual user has many of these spams in their Bulk i need a rule in dovecot.sieve to prevent them Can anybody help me for writing this rule.
you are much better off rejecting those even before seing the DATA, if
that address is in the envelope sender, or after, if it is only in the
From: message header. No need to accept them, so no need for dovecot
to even see them.
So this is an issue you should take, if necessary, to the mailing list
of your MTA of choice.
Giuliano
On 1/21/2009, Giuliano Gavazzi (dev+lists@humph.com) wrote:
you are much better off rejecting those even before seing the DATA, if that address is in the envelope sender, or after, if it is only in the From: message header.
? If he did that, then he wouldn't see his own messages to this list.
But I agree that fighting this kind of spam is best done at the MTA level, and isn't really a dovecot (or sieve) issue.
The postfix backscatter readme is a good start, esppecially is you are using postfix - and if you aren't, why aren't you? ;) ... but the concepts can be applied to any MTA...
http://www.postfix.org/BACKSCATTER_README.html
--
Best regards,
Charles
On W 21 Jan, 2009, at 12:25 , Charles Marcus wrote:
On 1/21/2009, Giuliano Gavazzi (dev+lists@humph.com) wrote:
you are much better off rejecting those even before seing the DATA, if that address is in the envelope sender, or after, if it is only in the From: message header.
? If he did that, then he wouldn't see his own messages to this list.
you are quite right. Indeed I never check the From: header, but the
MAIL FROM. I extended the rule for the benefit of the list, and it
came out wrong...
But I agree that fighting this kind of spam is best done at the MTA level, and isn't really a dovecot (or sieve) issue.
The postfix backscatter readme is a good start, esppecially is you are using postfix - and if you aren't, why aren't you? ;) ... but the concepts can be applied to any MTA...
I don't use postfix, because I use exim...
g
On 1/21/2009, Giuliano Gavazzi (dev+lists@humph.com) wrote:
The postfix backscatter readme is a good start, esppecially is you are using postfix - and if you aren't, why aren't you? ;) ... but the concepts can be applied to any MTA...
I don't use postfix, because I use exim...
And as I said... the CONCEPTS can be applied to ANY MTA...
On T 22 Jan, 2009, at 11:49 , Charles Marcus wrote:
On 1/21/2009, Giuliano Gavazzi (dev+lists@humph.com) wrote:
The postfix backscatter readme is a good start, esppecially is you
are using postfix - and if you aren't, why aren't you? ;) ... but the concepts can be applied to any MTA...I don't use postfix, because I use exim...
And as I said... the CONCEPTS can be applied to ANY MTA...
well, first of all backscatter is not really the issue of this thread.
Secondly the concepts are not all that good. In particular the one
entitled:
Blocking backscatter mail with forged sender information
that states:
"Like many people I still have a few email addresses in domains that I
used in the past. Mail for those addresses is forwarded to my current
address. Most of the backscatter mail that I get claims to be sent
from these addresses. Such mail is obviously forged and is very easy
to stop."
From what I understand he is rejecting backscatter that is sent to
some of his old addresses (with an identical forged sender, but this
is irrelevant) and from there forwarded to his mail server. Very bad.
If you have configured forwarding somewhere you must be prepared to
accept anything from there, or else you will be the cause of
backscatter as the peer server is a genuine server and not a spambot.
The old Postel rule Be conservative with what you send and liberal
with what you receive (or something on those lines) might be too
liberal in the current internet, but certainly should not be relaxed
on the conservative part... The first thing an administrator should
look for is to avoid generating spam of any sort, then he can think of
ways to stop it (and even more responsibly to place a further burden
on spammers with delays and the like, but this is something you can
only do on an MTA).
Giuliano
On 1/22/2009, Giuliano Gavazzi (dev+lists@humph.com) wrote:
"Like many people I still have a few email addresses in domains that I used in the past. Mail for those addresses is forwarded to my current address. Most of the backscatter mail that I get claims to be sent from these addresses. Such mail is obviously forged and is very easy to stop." From what I understand he is rejecting backscatter that is sent to some of his old addresses (with an identical forged sender, but this is irrelevant) and from there forwarded to his mail server.
No... you're reading it wrong.
He is talking about domains of HIS... so he CONTROLS them... in other words, the same server that is receiving the backscatter is the one rejecting the forged backscatter.
You would be right if you were talking about an old hotmail account or something like that, but we're not.
--
Best regards,
Charles
Giuliano Gavazzi a écrit :
On T 22 Jan, 2009, at 11:49 , Charles Marcus wrote:
On 1/21/2009, Giuliano Gavazzi (dev+lists@humph.com) wrote:
The postfix backscatter readme is a good start, esppecially is you are using postfix - and if you aren't, why aren't you? ;) ... but the concepts can be applied to any MTA...
I don't use postfix, because I use exim...
And as I said... the CONCEPTS can be applied to ANY MTA...
well, first of all backscatter is not really the issue of this thread.
agreed.
Secondly the concepts are not all that good.
They are ;-p
In particular the one entitled:
Blocking backscatter mail with forged sender information
that states:
"Like many people I still have a few email addresses in domains that I used in the past. Mail for those addresses is forwarded to my current address. Most of the backscatter mail that I get claims to be sent from these addresses. Such mail is obviously forged and is very easy to stop." From what I understand he is rejecting backscatter that is sent to some of his old addresses (with an identical forged sender,
Note the "from" in "claims to be sent FROM...".
but this is irrelevant) and from there forwarded to his mail server. Very bad. If you have configured forwarding somewhere you must be prepared to accept anything from there, or else you will be the cause of backscatter as the peer server is a genuine server and not a spambot.
you misunderstooood ;-p
the idea is:
if I get a bounce caused by a message sent with joe@example.com as sender, and I know joe@example.com is never used as a sender (because I own that address and I don't use it as a sender), then I can block the message.
here's another example. while my Reply-To is set to mouss+nobulk@netoyen.net, I don't use this address in From: or envelope sender. so if someone bounces a mail supposedly sent from this address, _I_ know the "original" message was a forgery and I can reject the bounce.
[snip]
On S 24 Jan, 2009, at 21:45 , mouss wrote:
From what I understand he is rejecting backscatter that is sent to
some of his old addresses (with an identical forged sender,Note the "from" in "claims to be sent FROM...".
but this is irrelevant) and from there forwarded to his mail server. Very bad. If you have configured forwarding somewhere you must be prepared to
accept anything from there, or else you will be the cause of backscatter
as the peer server is a genuine server and not a spambot.you misunderstooood ;-p
whoops! I wrote "with an identical forged sender, but this is
irrelevant", clearly that was NOT irrelevant. I should have paid more
attention to that. Anyway, your document should not be just called
"backscatter how-to", as backscatter will have (if really such), most
of the time, an empty sender. The only exception are some idiotic
virus scanners.
g
participants (4)
-
Charles Marcus
-
Giuliano Gavazzi
-
mouss
-
Sophia Alikhani