lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5.1.0.14.2.20040617151253.06262cf0@127.0.0.1>
From: alavan at pangeatech.com (Alavan)
Subject: Spam Solution

Please correct me if I'm missing something here:

  Microsoft and POBOX.com support Caller ID and SPF to help thwart phishing 
and SPAM.

I can see it helping phishing (kind of) as the phishers won't be able to 
forge the FROM address. But, that won't stop naive users from entering 
their personal information onto the fake site even with some rogue FROM 
address. Also, the phishers can just claim to be from a hired consulting 
agency and send the SPAM from a hijacked PC on a domain that sounds 
somewhat technical (or something like that).

Also, if spammers can't forge, so what? They'll just grab the domain name 
from the PC they've hijacked and send away or go back to using the e-mail 
client on the machine. Once the spammers change their methodology (which 
they do all the time to counter anti-spam efforts), these measures will 
have little to no effect.

Plus, many people use a FROM address from one of their other POP accounts 
on other domains. For instance, let's say I'm sending an e-mail from home 
just before I leave to a business contact and I want them to see my 
corporate e-mail address instead. In order to accomplish this after Caller 
ID and SPF, all admins will have to get their users to switch to POP before 
SMTP to their corporate mail servers to avoid these returned e-mails (when 
the FROM address is intentionally forged).

 From what I've seen, most of the SPAM comes from hijacked machines - even 
the SPAM from other countries. So, port 25 blocking is good, but not the 
be-all end-all as some "users" will want to host their own mail.

It seems to me that if we make all MTA's register somehow (both SMTP and 
POST), this would eliminate the hijacked machine as spambot phenomenon. We 
already have MX records for SMTP, but a lot of providers use different 
machines to receive (via SMTP) and send mail (POST). So, maybe a new DNS 
record is introduced for POST. Your machine(s) could do both or not. When 
your server goes to accept a message, it looks to see if the IP of the 
sending machine is listed in this new DNS record. If not, return a 5XX error.

Didn't I read something somewhere about the possibility of this?

Thanks,

Alavan


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ