full-disclosure - Spam Solution

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]

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