On Thu, 2007-02-22 at 13:22 +0000, Joe wrote: > It will be traceable to your IP address, and after a while you will > be blacklisted. Spam is invariably sent from somebody else's computer > after hijacking it, or through a mail server configured as an open > relay (yes, they still exist). > > But be even more amazed. Here is email at its simplest and most basic: > > http://support.microsoft.com/kb/153119
This is not RFC-822 compliant. I reject at SMTP time based on being non-compliant. In fact 95% of the "zombie" spam just follows this procedure and dumps its mail this way, without any "error checking". If it does not follow RFC-822 properly, I drop the connection. Yes, I know this breaks other RFCs on my part, but it also reduces the amount of traffic I see by a hundred fold. > Yes, this even works from Windows. No MTA, nothing beyond a telnet > client needed. Ignore the Windows-specific stuff, and the warnings. > This will work with any mail server that's willing to accept a > connection from you (see the dynamic IP address stuff in another > reply). It must of course be the mail server which handles mail for > that particular person. See my previous, but, it also works for "Open-Relays" or for your Windows machine that uses your ISP e-mail server to connect to. ISPs have much problems with supporting the SPAM from machines they service as an ISP. I have a close friend that works for Cox Communications. He is the one of (only dedicated to?) the primary mail systems architects. They are spending tremendous amounts of money to reduce the possible legal risks associated with SPAM cycling through their servers. Everyday, they are adding either machines, additional filters, services or anything else they can think of for mail outgoing. Incoming is another ball of wax... they have to classify and KEEP spam for their valid recipients, should they want to look through it... for false positives. This involves a whole other set of machines, storage, services, filters, options and whatnot. > There's a more complicated set of commands to send email to someone > through another mail server, if they won't accept email direct. It > involves having an account on the intermediate server and supplying > your user name and password. MTAs exist to deal with all the messy > details, particularly the bit about finding which mail server should > handle the mail for the recipient. The real problem I see now, is SPAM zombies delivering mail to the ISP mail server, then it becomes RFC-822 compliant. I fix that by slowing down the conversation in the beginning by using SA-Exim which scan for SPAM on SMTP time. If it detects SPAM, it rejects... or then drops if the sending server doesn't comply with the conversation rules. Again, I know I am breaking RFC compliance by rejecting at SMTP time. Once again though, I have reduced my traffic a hundred fold, from SPAM. Yes, I also know I use my e-mail address publicly and scraper-bots find my e-mail all the time. I just deal with the SPAM. My last problem is how-to whitelist murphy.debian.org, but still reject SPAM that gets through the Debian SPAM traps... I used to not whitelist murphy, but that got me auto-unsub'd from (most) Debian lists I subscribe to, for "bouncing" the SPAM. I guess it is a fine, fine line. -- greg, [EMAIL PROTECTED] Novell's Directory Services is a competitive product to Microsoft's Active Directory in much the same way that the Saturn V is a competitive product to those dinky little model rockets that kids light off down at the playfield. -- Thane Walkup -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
