-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of ryanag@zoominternet.net Sent: Friday, April 01, 2005 9:24 PM To: CentOS mailing list Subject: RE: [CentOS] postfix tightening
On Fri, 2005-04-01 at 21:04 -0600, Mark A. Lewis wrote:
Riight. Ever done a reverse lookup on a RR IP? Rogers? SBC? All of them will have valid reverse entries.
See below.
http://searchcio.techtarget.com/sDefinition/0,,sid19_gci917504,00.html
"Reverse DNS (rDNS) is a method of resolving an IP address into a domain name, just as the domain name system (DNS) resolves domain names into associated IP addresses. One of the applications of reverse DNS is as a spam filter. Here's how it works: Typically, a spammer uses an invalid IP address, one that doesn't match the domain name. A reverse DNS lookup program inputs IP addresses of incoming messages to a DNS database. If no valid name is found to match the IP address, the server blocks that message."
So, here is the problem.
Lets say that Acme Widget has their mail hosted with Hostco. Acme Widget would rather not have mail.hostco.com in the mail headers for whatever reason. So, hostco doesn't setup a ptr record for it. This does not make Acme Widget or Hostco any more likely to be spammers, it just makes you more likely to drop their mail.
Now, the other side of that...
Foospam wants to send out 87 bazillion mail messages to everyone about fooagra. So, they set their mail server to helo with fooco.com and set the ptr record to be mail.fooco.com and they just danced right by all of this with very minimal effort. For that matter, you can use whatever ptr your ISP sets up for you.
The whole accountablity thing is a fallacy. I can buy a domain right now for $8, put whatever I want in the whois info and just use that for the ptr record part, it could be a throwaway domain for all I care. At the end of the day, it bought the person reciving the spam nothing.
Reverse DNS or not, you can see what IP the mail came from, you can tell who is the owner of that IP and they can find out what user has that IP. The problem is that most of them are simply unwilling to do so, they ignore mail to the abuse address or just give you a canned answer.
My point is that relying on this only makes you more likely to drop legit mail and poses no problem to the spammers.
My point is that relying on this only makes you more likely to drop legit mail and poses no problem to the spammers.
I don't disagree with your points that: 1. It is a bad solution to rely soley upon. 2. If a spammer chooses to, it is fairly easy to bypass (although your example of buying a domain name poses some risk to a guy using trojaned boxes to send mail). 3. If everyone did reverse DNS checks there would still be spam.
I think of it like this....
At home I block ads using the hosts file. Have been doing it since forever. I use the hosts file below + my own additions): http://www.mvps.org/winhelp2002/hosts.txt
If ad banner farms would not push obvious names, and instead use extensions of the legitimate sites ( www.realfoosite.com/sleazeballad ), my way of blocking them fails. On top of that, I also accidentally block some legitimate sites once in awhile.
All that being said, I don't get pop-ups, pop-unders, or ads, and this easy-to-defeat method of blocking ads works very well, so long as I am willing to accept that I am occasionally blocking some things I wish I hadn't. ;-)
Just an <OT> response.
I've enjoyed reading about all the ins and outs of spam and methods of avoiding same, but I solved my problem about 8 months ago by getting a Gmail account. Gmail has excellent spam detection and isolation facilities, and all I have to do is scan the folder once a day to check for false hits (about 2 per week) and then whack the spam with 2 keystrokes. On the other side of the fence, I find that a few bits of spam make it to my inbox every few days, but once I mark that as spam, the spam filter learns quite quickly, and I don't see those type mails getting through again.
One interesting side note, 99.7% of all my spam comes from mail automatically forwarded from my comcast.net account. If I were to unhook forwarding those accounts, I would be almost spam free.
On Fri, 2005-04-01 at 21:35 -0600, Mark A. Lewis wrote:
So, here is the problem.
Lets say that Acme Widget has their mail hosted with Hostco. Acme Widget would rather not have mail.hostco.com in the mail headers for whatever reason. So, hostco doesn't setup a ptr record for it. This does not make Acme Widget or Hostco any more likely to be spammers, it just makes you more likely to drop their mail.
---- if they have the 'vanity' to want the mail server to have the smtp server that they use actually tag mail with their domain, they should be prepared to pay for the privilege. ----
Now, the other side of that...
Foospam wants to send out 87 bazillion mail messages to everyone about fooagra. So, they set their mail server to helo with fooco.com and set the ptr record to be mail.fooco.com and they just danced right by all of this with very minimal effort. For that matter, you can use whatever ptr your ISP sets up for you.
---- but you know and I know that they are gonna show up on RBL lists if they do ----
The whole accountablity thing is a fallacy. I can buy a domain right now for $8, put whatever I want in the whois info and just use that for the ptr record part, it could be a throwaway domain for all I care. At the end of the day, it bought the person reciving the spam nothing.
---- up to the point that they still need an smtp server whose ip address resolves via dns. ----
Reverse DNS or not, you can see what IP the mail came from, you can tell who is the owner of that IP and they can find out what user has that IP. The problem is that most of them are simply unwilling to do so, they ignore mail to the abuse address or just give you a canned answer.
---- this is a separate problem - some are responsive and concerned about what happens on their ip space and bandwidth ----
My point is that relying on this only makes you more likely to drop legit mail and poses no problem to the spammers.
---- every thing that you do to reduce spam makes you more likely to drop legit mail - that of course is the challenge facing us now.
I think that this very much poses problems for spammers - so does RBL's and greylisting - of course, combatting spam tends to be done like security, in layers and if you have a layer that picks off a percentage of emails, it all contributes to the benefit. This is but one tool at your disposal. Like using RBL's, this is not perfect.
Let's not forget that a large amount of spam is being spewed by compromised systems on dynamic broadband ip space and stopping this is a good thing.
Craig
"Mark A. Lewis" mark@siliconjunkie.net writes:
Lets say that Acme Widget has their mail hosted with Hostco. Acme Widget would rather not have mail.hostco.com in the mail headers for whatever reason. So, hostco doesn't setup a ptr record for it. This does not make Acme Widget or Hostco any more likely to be spammers, it just makes you more likely to drop their mail.
So they deliberately configure a non-compliant system, breaking the rules for connecting to the Internet, as set down in the RFCs? Then they will have problems sending email to a large number of sites, and rightly so. They need to fix their misconfigured email system. This is not a matter of opinion: they've set it up *wrong*.
Anyway, the point of checking that a system that's trying to deliver email to you has a name that resolves to the address it's using, that that address resolves back to the name, and that the HELO specifies the correct name as well, is that most privately owned Windows PCs don't fulfill those requirements. So, when they're infected with viruses that turn them into remote controlled, spam-sending robots, your email system can refuse to even talk to them. Please note that this is by far the major technique for distributing spam these days, and has turned into a huge business, where people who create viruses earn big money renting out zombie networks to spammers and other criminal scum.
-tih
On Sat, 2005-04-02 at 02:27, Tom Ivar Helbekkmo wrote:
Lets say that Acme Widget has their mail hosted with Hostco. Acme Widget would rather not have mail.hostco.com in the mail headers for whatever reason. So, hostco doesn't setup a ptr record for it. This does not make Acme Widget or Hostco any more likely to be spammers, it just makes you more likely to drop their mail.
So they deliberately configure a non-compliant system, breaking the rules for connecting to the Internet, as set down in the RFCs?
Please specify the requirement that you mean here.
Then they will have problems sending email to a large number of sites, and rightly so. They need to fix their misconfigured email system. This is not a matter of opinion: they've set it up *wrong*.
Anyway, the point of checking that a system that's trying to deliver email to you has a name that resolves to the address it's using, that that address resolves back to the name, and that the HELO specifies the correct name as well, is that most privately owned Windows PCs don't fulfill those requirements.
There is no requirement for the HELO to match anything else. It must be syntactically correct but it does not have to have anything to do with the particular interface you happen to be using. On the other hand the From: address does have to be resolvable - otherwise you wouldn't be able to reply anyway.
On Sat, Apr 02, 2005 at 03:54:37PM -0600, Les Mikesell wrote:
Anyway, the point of checking that a system that's trying to deliver email to you has a name that resolves to the address it's using, that that address resolves back to the name, and that the HELO specifies the correct name as well, is that most privately owned Windows PCs don't fulfill those requirements.
There is no requirement for the HELO to match anything else. It must be syntactically correct but it does not have to have anything to do with the particular interface you happen to be using. On the other hand the From: address does have to be resolvable - otherwise you wouldn't be able to reply anyway.
Wrong. RFC2821 says:
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command.
Cheers, Gavin
On Sat, 2005-04-02 at 21:14, Gavin Carr wrote:
On Sat, Apr 02, 2005 at 03:54:37PM -0600, Les Mikesell wrote:
Anyway, the point of checking that a system that's trying to deliver email to you has a name that resolves to the address it's using, that that address resolves back to the name, and that the HELO specifies the correct name as well, is that most privately owned Windows PCs don't fulfill those requirements.
There is no requirement for the HELO to match anything else. It must be syntactically correct but it does not have to have anything to do with the particular interface you happen to be using. On the other hand the From: address does have to be resolvable - otherwise you wouldn't be able to reply anyway.
Wrong. RFC2821 says:
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command.
A SHOULD is not a requirement. A MUST would be a requirement. Even if it did mention a requirement, there is nothing that says a host with multiple addresses should use the name matching the connected interface each time. There is certainly nothing there to override the earlier RFC (which I've forgotten) that specifies a similar recommendation but goes on to say that the receiver MUST NOT reject the message based on an address lookup mismatch for the HELO/EHLO name (obviously written by someone who realized that multi-homed servers are common and that corporate servers often live behind NAT firewalls and don't even know the address that will be used the public side).
On Sat, Apr 02, 2005 at 09:41:41PM -0600, Les Mikesell wrote:
On Sat, 2005-04-02 at 21:14, Gavin Carr wrote:
On Sat, Apr 02, 2005 at 03:54:37PM -0600, Les Mikesell wrote:
Anyway, the point of checking that a system that's trying to deliver email to you has a name that resolves to the address it's using, that that address resolves back to the name, and that the HELO specifies the correct name as well, is that most privately owned Windows PCs don't fulfill those requirements.
There is no requirement for the HELO to match anything else. It must be syntactically correct but it does not have to have anything to do with the particular interface you happen to be using. On the other hand the From: address does have to be resolvable - otherwise you wouldn't be able to reply anyway.
Wrong. RFC2821 says:
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command.
A SHOULD is not a requirement. A MUST would be a requirement. Even if it did mention a requirement, there is nothing that says a host with multiple addresses should use the name matching the connected interface each time. There is certainly nothing there to override the earlier RFC (which I've forgotten) that specifies a similar recommendation but goes on to say that the receiver MUST NOT reject the message based on an address lookup mismatch for the HELO/EHLO name (obviously written by someone who realized that multi-homed servers are common and that corporate servers often live behind NAT firewalls and don't even know the address that will be used the public side).
I agree with your specific point that using a HELO domain that does not match your ip address (if a literal) or your reverse mapping record does not mean you are in violation of the RFCs. And therefore, denying mail on that basis is bad.
But your initial:
There is no requirement for the HELO to match anything else.
is too strong. There *is* a general requirement (the SHOULD) that the HELO domain belongs to the client. Syntactic goodness is not sufficient.
I reject all mail where the sender HELO's with any of my ip address literals, for instance, which I do consider a violation of the RFCs, and removes a surprisingly large chunk of spam.
Cheers, Gavin
"Mark A. Lewis" mark@siliconjunkie.net writes:
Lets say that Acme Widget has their mail hosted with Hostco. Acme Widget would rather not have mail.hostco.com in the mail headers for whatever reason. So, hostco doesn't setup a ptr record for it. This does not make Acme Widget or Hostco any more likely to be spammers, it just makes you more likely to drop their mail.
Actually, the problem you're describing is routinely solved at any decent ISP *without* breaking any rules. If the above were a genuine scenario, I would conclude that Hostco is run by nincompoops. ;-)
-tih
-
Collins Richey -
Craig White -
Gavin Carr -
Les Mikesell -
Mark A. Lewis -
Ryan -
Tom Ivar Helbekkmo