With all the virus emails around at present, I wonder if it might be a good idea to have a way of using a list all the valid local recipients, and comparing that with the addresses incoming emails are sent to.
If the recipient does not match the whitelist, Fluffy could include the address in a list in the Training Centre. The user then can choose whether to add that to the valid recipients kist, add it to the spamtrap list, or ignore it. Optionally, all non-valid recipients would automatically be added to the spamtrap list.
Alternatively, what about making it so that ALL addresses are made into spamtraps, unless specifically excluded?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually I don't think this would help much and it would be really bad if (as happens often for me) someone makes a typo in an email address.
The real "cure" would be if fluffy remember the from and to address for a wait state -- then when mydoom came back later with a different address (mydoom did not resend to the same address or from the same address in the wait period -- for me 10 mins) it would be rejected because it is clearly a virus.
Once an email has been validated (they came back with the same from address after the wait period) then it could accept all mail from that address -- this would fix the mydoom problem and have the system act basically as it does now.
What do ya think wayne?
Hogan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here are my thoughts submitted with due humility. I'm open to criticisms and other ideas:
1. Maybe typos aren't such an issue given that Fluffy would generate an immediate SMTP response - that email address is not known here, so the sender would get an almost immediate bounce and could correc. It is, after all, their fault. Of course I add common typos to mappings.
2. I think you are proposing, Hogan, that defer be based on mail from/rcpt to pairs rather than just IP address at present. That has potential. Of course MyDoom uses its own SMTP engine if it can but the local SMTP one if it can't. I suspect that in general it has used ti's own, but it's worth noting that if it uses a valid local mail server (or another virus does) then that good local mail server will in fact retry until it delivers
3. I'm thinking, to keep things simple, that maybe I should first try an _explicit_ tar pit. Ceryainly I know a lot of spam engines will time out after 20 seconds. I have a feeling that the same applies to virus writers - they want to send out many emails quickly, so have a short time-out. Real mail servers follow the internet standards with a timeout of 5 minutes. So I'm thinking of adding an option for a timeout of 0-4 minutes. I shall see if that stops MyDoom in its tracks.
4. As far as spam traps go, I'm thinking of the following for email addresses:
a) a list of valid users (including common misspelling)
b) a list of invalid users (and perhaps former users) - we don't accept mail for them, but we don't block the sending IP
c) a list of invalid users that will trigger a block (the current spam trap list)
d) a list of addresses that Fluffy has seen that aren't in any of the lists - they can be transferred to any of the other 3
The lists would be processed in order from a to b to c, so you could use a wildcard in lists b or c to achieve the logical outcome of rejecting anything not in a or rejecting and henceforth blocking anything not in a.
So a * in column c would make all addressesd spam trap unless explicitly excluded, but you'd have other options as well.
6.
>Right now, I'd like all mail from a particular address to be forwarded to abuse@demon.net,
says theHairydog
So the idea here is an option to redirect all email from IP address a.b.c.d to email address y@z ?
Have I got that right?
Yup, I could add that.
5.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For every typo'd email, I get a thousand spams and viruses, but I do take your point.
That's why I suggested that Fluffy lists them for user confirmation as the best bet.
Right now, I'd like all mail from a particular address to be forwarded to abuse@demon.net, who have still done nothing about their customer who has been sending me (and probably others) viruses every few minutes for over five days.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is a "whitelist" of internal email addresses necessary?
Surely Fluffy is able to talk to the local SMTP server behind it and asks if the TO address verifies as legit. If the local SMTP server says accept, then that is effectively the same thing as a whitelist.
Otherwise everytime I add or delete another user into the server's email software, I also have to edit that email address into Fluffy. No thank you!
Minimum maintenance hassle please
Or am I wrong and Fluffy can't ask the local server. it could always be cached for a while? Can't be cached or "auto-added" as if someone leave and the address is deleted, Fluffy will never auto-delete it's copy. It would need to be a cache with a forced timeout, say check once a day?
Some good ideas though!
Also see my RFE about adding the lack of a rDNS as a weighted test. I get a lot of SPAM with no rDNS. most legit email servers have a rDNS.
Therefore, I could set it to say "no rDNS, weight 5"
Ron.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Rontouw: Yes you are right. IF your SMTP server has it's own whitelist, and rejects anything else, then Fluffy interacting with it will achieve the desired result. That's why Fluffy says it is PROVIOSIONALLY accepting mail - it's up to the local SMTP server to make the final determination. HOWEVER many people have their SMTP server set to accept ALL email for a domain (to catch typos on mail addresses) and often one mailbox that catches everything not specifically addressed to another mailbox. In this latter case the proposed changes would be useful, and in the former case do no harm and could be ignored. In this former case the only list you'd be interested in is the current one - the spam trap addresses.
rDNS test is a good idea and will be added.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In addition to the first option on the local email tab ("Only accept these recipients (prevent relaying), unless the connecting SMTP server is on the local network") - it would be nice to have the following option:
"Reject emails that are allegedly FROM these senders, unless the connecting SMTP server is on the local network"
This would also get rid of those viruses and spammers that come in pretending to originate from someone in the local domain. A few of my users opened a Mydoom email (the first day, when it wasn't yet detected by the virus scanner) because it appeared to be from a collegue. It was rather emberassing to admit that I cannot stop emails with these forged sender addresses.
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
rkeur: There are two types of From: address. One is sent as part of the SMTP conversation (mail from), and the other is included in the body of the mail message as a From: header line.
The first is easy to deal with. The second is far more complicated and may not even be desirable (some mailing lists use you own address as the address in the To line). We'd want to think that through precisely.
Can you tell me what you note viruses do - is it Mail From or the From: header line. A copy of the message should tell you. I shall try to find one. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With all the virus emails around at present, I wonder if it might be a good idea to have a way of using a list all the valid local recipients, and comparing that with the addresses incoming emails are sent to.
If the recipient does not match the whitelist, Fluffy could include the address in a list in the Training Centre. The user then can choose whether to add that to the valid recipients kist, add it to the spamtrap list, or ignore it. Optionally, all non-valid recipients would automatically be added to the spamtrap list.
Alternatively, what about making it so that ALL addresses are made into spamtraps, unless specifically excluded?
Actually I don't think this would help much and it would be really bad if (as happens often for me) someone makes a typo in an email address.
The real "cure" would be if fluffy remember the from and to address for a wait state -- then when mydoom came back later with a different address (mydoom did not resend to the same address or from the same address in the wait period -- for me 10 mins) it would be rejected because it is clearly a virus.
Once an email has been validated (they came back with the same from address after the wait period) then it could accept all mail from that address -- this would fix the mydoom problem and have the system act basically as it does now.
What do ya think wayne?
Hogan
Here are my thoughts submitted with due humility. I'm open to criticisms and other ideas:
1. Maybe typos aren't such an issue given that Fluffy would generate an immediate SMTP response - that email address is not known here, so the sender would get an almost immediate bounce and could correc. It is, after all, their fault. Of course I add common typos to mappings.
2. I think you are proposing, Hogan, that defer be based on mail from/rcpt to pairs rather than just IP address at present. That has potential. Of course MyDoom uses its own SMTP engine if it can but the local SMTP one if it can't. I suspect that in general it has used ti's own, but it's worth noting that if it uses a valid local mail server (or another virus does) then that good local mail server will in fact retry until it delivers
3. I'm thinking, to keep things simple, that maybe I should first try an _explicit_ tar pit. Ceryainly I know a lot of spam engines will time out after 20 seconds. I have a feeling that the same applies to virus writers - they want to send out many emails quickly, so have a short time-out. Real mail servers follow the internet standards with a timeout of 5 minutes. So I'm thinking of adding an option for a timeout of 0-4 minutes. I shall see if that stops MyDoom in its tracks.
4. As far as spam traps go, I'm thinking of the following for email addresses:
a) a list of valid users (including common misspelling)
b) a list of invalid users (and perhaps former users) - we don't accept mail for them, but we don't block the sending IP
c) a list of invalid users that will trigger a block (the current spam trap list)
d) a list of addresses that Fluffy has seen that aren't in any of the lists - they can be transferred to any of the other 3
The lists would be processed in order from a to b to c, so you could use a wildcard in lists b or c to achieve the logical outcome of rejecting anything not in a or rejecting and henceforth blocking anything not in a.
So a * in column c would make all addressesd spam trap unless explicitly excluded, but you'd have other options as well.
6.
>Right now, I'd like all mail from a particular address to be forwarded to abuse@demon.net,
says theHairydog
So the idea here is an option to redirect all email from IP address a.b.c.d to email address y@z ?
Have I got that right?
Yup, I could add that.
5.
For every typo'd email, I get a thousand spams and viruses, but I do take your point.
That's why I suggested that Fluffy lists them for user confirmation as the best bet.
Right now, I'd like all mail from a particular address to be forwarded to abuse@demon.net, who have still done nothing about their customer who has been sending me (and probably others) viruses every few minutes for over five days.
Is a "whitelist" of internal email addresses necessary?
Surely Fluffy is able to talk to the local SMTP server behind it and asks if the TO address verifies as legit. If the local SMTP server says accept, then that is effectively the same thing as a whitelist.
Otherwise everytime I add or delete another user into the server's email software, I also have to edit that email address into Fluffy. No thank you!
Minimum maintenance hassle please
Or am I wrong and Fluffy can't ask the local server. it could always be cached for a while? Can't be cached or "auto-added" as if someone leave and the address is deleted, Fluffy will never auto-delete it's copy. It would need to be a cache with a forced timeout, say check once a day?
Some good ideas though!
Also see my RFE about adding the lack of a rDNS as a weighted test. I get a lot of SPAM with no rDNS. most legit email servers have a rDNS.
Therefore, I could set it to say "no rDNS, weight 5"
Ron.
Rontouw: Yes you are right. IF your SMTP server has it's own whitelist, and rejects anything else, then Fluffy interacting with it will achieve the desired result. That's why Fluffy says it is PROVIOSIONALLY accepting mail - it's up to the local SMTP server to make the final determination. HOWEVER many people have their SMTP server set to accept ALL email for a domain (to catch typos on mail addresses) and often one mailbox that catches everything not specifically addressed to another mailbox. In this latter case the proposed changes would be useful, and in the former case do no harm and could be ignored. In this former case the only list you'd be interested in is the current one - the spam trap addresses.
rDNS test is a good idea and will be added.
Can I suggest to add one more option.
In addition to the first option on the local email tab ("Only accept these recipients (prevent relaying), unless the connecting SMTP server is on the local network") - it would be nice to have the following option:
"Reject emails that are allegedly FROM these senders, unless the connecting SMTP server is on the local network"
This would also get rid of those viruses and spammers that come in pretending to originate from someone in the local domain. A few of my users opened a Mydoom email (the first day, when it wasn't yet detected by the virus scanner) because it appeared to be from a collegue. It was rather emberassing to admit that I cannot stop emails with these forged sender addresses.
Robert
rkeur: There are two types of From: address. One is sent as part of the SMTP conversation (mail from), and the other is included in the body of the mail message as a From: header line.
The first is easy to deal with. The second is far more complicated and may not even be desirable (some mailing lists use you own address as the address in the To line). We'd want to think that through precisely.
Can you tell me what you note viruses do - is it Mail From or the From: header line. A copy of the message should tell you. I shall try to find one. :-)