Idea: IMAP verification system to stop spam

C

Cthulhux

While sitting in the office, we were discussing anti-spam solutions. We came to the conclusion that a good approach to fight spam would be if the receiving server would ask the "sending server" if the mail was actually sent from the address mentioned in the header. Fake senders could automatically be marked as spam then.

Is something like that available? If not, would it be much effort to teach our beloved mail server software to do so?
 
Cthulhux said:
While sitting in the office, we were discussing anti-spam solutions. We came to the conclusion that a good approach to fight spam would be if the receiving server would ask the "sending server" if the mail was actually sent from the address mentioned in the header. Fake senders could automatically be marked as spam then.

Is something like that available? If not, would it be much effort to teach our beloved mail server software to do so?
Click to expand...

mail/postfix got the configuration parameter reject_unverified_sender in the section smtpd_sender_restrictions.
 
And how is an "intermediate" server going to find out the sender is who he says he is?
 
SPF records are a static way of doing this but they are somewhat limited and not intended to provide absolute answers.
 
Cthulhux said:
While sitting in the office, we were discussing anti-spam solutions. We came to the conclusion that a good approach to fight spam would be if the receiving server would ask the "sending server" if the mail was actually sent from the address mentioned in the header. Fake senders could automatically be marked as spam then.
Click to expand...

Actually, this does not stop spam, it just stops address forgery. SPF and DKIM are supposed to do that. The problem is that spammers use real domains now, and can and do use these anti-forgery measures.
 
SirDice said:
And how is an "intermediate" server going to find out the sender is who he says he is?
Click to expand...

That's the point. The "intermediate" server should ask the initial server which should hold a copy of sent messages for one-time comparison.
 
Cthulhux said:
That's the point. The "intermediate" server should ask the initial server which should hold a copy of sent messages for one-time comparison.
Click to expand...

That server might not be available to query. It's quite common to find different servers for ingress and egress traffic. The egress servers usually aren't accessible from the outside world.

You will also introduce an enormous amount of overhead, every single email would have to be verified. That's going to be fun for companies like Hotmail or Gmail.
 
"Companies" like Gmail - having paid Pro services available - should disallow newly registered free accounts to send mass e-mail anyway.
 
I suggest you start by reading up on how email actually works. The classic is RFC 821 (Simple Mail Transfer Protocol). You will find this has been obsoleted by RFC 2821, which has been obsoleted by RFC 5321 (so read that one). Then you will be in a better position to help design the next worldwide email system.
 
SirDice said:
You will also introduce an enormous amount of overhead, every single email would have to be verified. That's going to be fun for companies like Hotmail or Gmail.
Click to expand...

Are you kidding? This would be only peanuts on the net. The verify tool of mail/postfix would do more or less the following:

Code: 
# host -t MX gmail.com
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
...

# telnet gmail-smtp-in.l.google.com 25
Trying 74.125.137.26...
Connected to gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP l41si65191676yhc.86
EHLO example.com
250-mx.google.com at your service, [177.80.245.37]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250 ENHANCEDSTATUSCODES
MAIL FROM:<recipient@example.com>
250 2.1.0 OK l41si65191676yhc.86
RCPT TO:<sender@gmail.com>
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 l41si65191676yhc.86
quit
221 2.0.0 closing connection l41si65191676yhc.86

In the 550 case from the remote mail service, postfix would drop also a 550. In a 4xx case, postfix could drop a 4xx status (try again later).
 
Sender verification will cause false positives sometimes; I have had emails from eBay bounce because of it. Yes, it is eBay's fault, but that doesn't mean that it isn't still an issue.

The only real way to fight spam that I think would have an even remote possiblity of working, is micropayments:
If the email is from a known sender (confirmed with a key of some sort), the message is transmitted for free.
If the email is from an unknown sender, the sender must pay the amount specified in the soft bounce message. The recipient receives this money and then the message. The sender can then be added to the receiver's white list at the receiver's discretion.

With this system:
-Senders must send emails with discretion or lose money. If one spam message was 10 cents, and they wanted to send 1,000 of them, they would be out $100.
-Receivers effectively "get paid" to receive emails from unknown senders.
-Communication between trusted individuals is unaffected.
-If you have an email account that is intended as support/contact for the general public, and thus has numerous senders who would be unknown, keep the price low, such as 1 cent, which no one would realistically complain about. Again, any spam is only going to earn you money (even if it's only 1c each).
 
Cthulhux said:
While sitting in the office, we were discussing anti-spam solutions. We came to the conclusion that a good approach to fight spam would be if the receiving server would ask the "sending server" if the mail was actually sent from the address mentioned in the header. Fake senders could automatically be marked as spam then.

Is something like that available? If not, would it be much effort to teach our beloved mail server software to do so?
Click to expand...


This is bad. Why?

Because much spam comes from forged real e-mail addresses. So you're just loading up someone else's e-mail server to validate valid e-mail addresses instead of doing your own filtering.

If some spammer sends 2 million e-mail messages using forged addresses from my organisation, why should I have to put up with what is effectively a denial of service against my infrastructure?

rolfheinrich said:
Are you kidding? This would be only peanuts on the net. The verify tool of mail/postfix would do more or less the following:
Click to expand...

See above.

If you have a 20,000 host botnet doing your email sending, "just a little bit" of load multiplied a few million times can easily end up being a denial of service.

Why should *I* pay (in terms of bandwidth, CPU, etc.) to verify email you received did not come from me?

You can already validate originating path for email via SPF records in any case.

Push for more widespread adoption of SPF, not retarded schemes that offload the cost of the recipient's filtering to innocent third parties.


edit:
Never mind that many don't run IMAP, and plenty who do don't expose it to unauthenticated access over the internet.
 
ad eBay: have you considered reporting the issue?

ad "doing your own filtering": How should my client verify the validity of a sender address without asking the server?

An optional header flag should be enough, I don't think about enforcing validity check for all e-mail anyway.
 
Cthulhux said:
ad "doing your own filtering": How should my client verify the validity of a sender address without asking the server?
Click to expand...

SPF will tell you whether or not it came from the IP range or mail host that is registered in DNS for that domain, which is cached in DNS (i.e., it doesn't impact innocent third party's infrastructure excessively), and is as much as you need to know.

If the legitimate mail host for that domain is sending you spam, blacklist it. Contact the admin. Whatever, you have options.

If it didn't come from the host(s) registered in DNS via SPF as being valid for that domain, drop it.


Sending queries repeatedly into the IMAP server, which is actually not cached and scaled/intended to support the users of my network is being hostile.


And even if this "validation" succeeds - verifying the user exists won't help anyway.

Example:

- I harvest your address.
- I set up my own spam server/botnet to send email, faking from your address (let's say - to 10 million users). The IMAP-verifying recipient mail server consults DNS, checks that your email exists by logging into your server, which may or may not exist, as not everyone exposes IMAP.
- Let's say it exists. Your IMAP server (if it is not DOSed into submission by 10 million connections from hosts mailed from my botnet) replies "yup, it is a real user" (10 million times, potentially 10 million LDAP lookups to your internal LDAP server, 10 million firewall state connections, etc.)
- My email goes through, even though it is garbage


(As per many others, I don't run/expose IMAP anyway, but am simply arguing the point that doing this sort of thing is retarded. There are already workable, scalable options out there that don't DOS innocent people's servers if a spammer fakes a heap of email headers as being from their domain. They are also more likely to actually give you information that is relevant.)



edit:
Yes, sure, SPF is not widespread. However, if it was more widespread, it would work a lot better than this new, not implemented "solution".

The tools to fight spam are already there. They need to be rolled out. Making more tools is not the solution...
 
Pushrod said:
The only real way to fight spam that I think would have an even remote possiblity of working, is micropayments:
If the email is from a known sender (confirmed with a key of some sort), the message is transmitted for free.
If the email is from an unknown sender, the sender must pay the amount specified in the soft bounce message. The recipient receives this money and then the message. The sender can then be added to the receiver's white list at the receiver's discretion.
Click to expand...

You'll just end up with spammers using stolen money, spamming themselves along with everyone else in an attempt to launder it.
 
As already explained in post #5 in this thread SPF doesn't work. Why? Because the spammers use it.
So, everyone - back to the drawing board.
When you get a new idea, get back here with it, and the folks here will help you find out what's wrong with it.
 
You must log in or register to reply here.
Back
Top