9 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Email hijacking
FromSent OnAttachments
tros...@juniper.netAug 19, 2003 5:01 pm 
Mitch (WebCob)Aug 19, 2003 9:39 pm 
Mark TrostlerAug 19, 2003 10:57 pm 
James A BakerAug 19, 2003 11:16 pm 
Mitch (WebCob)Aug 20, 2003 12:44 am 
Theo Cabrerizo DiemAug 20, 2003 1:29 am 
list...@serv.chAug 20, 2003 6:51 am 
Mark TrostlerAug 21, 2003 8:10 pm 
Mitch (WebCob)Aug 21, 2003 8:57 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [courier-users] Email hijackingActions...
From:Mark Trostler (tros@juniper.net)
Date:Aug 21, 2003 8:10:44 pm
List:net.sourceforge.lists.courier-users

There needs to be a generalized way to correctly associate the address given in the MAIL FROM with the sending client. Given the current infrastructure of a lot of ISPs perhaps that's currently not possible as I had hoped - which SUCKS. Sure running SpamAssasin or Bogofilter is fine & dandy & works really well but now there's got to be a solution to stop endless email hijacking. If that means a total redo of the email infrastructure then I'm all for it. Mark (this is what happens when I reach my wit's end)

On Tue, 19 Aug 2003, James A Baker wrote:

On Tuesday, Aug 19, 2003, at 16:41 US/Central, tros@juniper.net wrote:

After having email addresses in my domains hijacked (both users that exist & those that don't) left, right, and center I can't take it anymore! Is it possible/insane to have esmtpd (& any other MTA) do a reverse DNS check on the MAIL FROM address to ensure that the domain specified there match the domain of the sending machine? I don't care if it takes a couple extra seconds to do that check, endless email hijacking is totally ridiculous & HAS to stop. I'm stick of seeing zillions of bounces from spam emails no one in my domain ever sent. SO someone please tell me what's so horrible about:

1. client connects & sends MAIL FROM address 2. server reverse DNSs the client's IP 3. if the domain doesn't match the domain in the FROM address or the IP is not resolvable the email is rejected

Lots of mail would NEVER get delivered to you in this situation. Take mine for instance.

My mail host is set up to allow me to send with any of several different From: addresses (to support multiple accounts) as long as I'm submitting it from my LAN or via an authenticated connection. However, because I send all my mail through that server (regardless of the From: addresses' domains) this solution would block those mails -- because the From: domain doesn't match my server's domain name in a reverse lookup.

This would also be the case with mail that EVER got relayed from one domain to another before final delivery. And also would stop all mail from anyone else who -- like me -- uses one server to send mail from multiple accounts on various domains. ... Think of a Bellsouth user who sends mail from their Yahoo! address, using their mail client instead of the Yahoo! web interface.

Also, what about the cases (such as this list at Sourceforge) where the address is in a sub-domain, but the IP of the client (i.e. the sending/relaying server) is in a different sub-domain. You couldn't even get mail from this list using this method, I don't think.

OR

1. client connects & sends MAIL FROM address 2. server DNSs the MX record for the domain in the FROM address 3. if the IP of client does NOT match one of the MX records for that domain the email is rejected. If domains want to allow other machines than their mail servers to be able to send emails using their domain they can add them with a very high MX priority so they never actually get used as a mail server BUT do show as legtimate sources of mail traffic for that domain

of course everyone across the internet would have to do this BUT if they DID then we REALLY cut down on spam - & virtually totally eliminate email hijacking.

...And you kill off any chance I had of debugging connection problems to your domain, when I can't manually telnet to port 25 and talk SMTP from a random workstation, instead of logging into a server listed in my domain's MX records. Though that's more of an annoyance than anything, of course, since there'd be ways around the problem.

But much more seriously -- and just like in the first case -- you also rule out any relaying of mail between domains (those along the way to you) with this kind of restriction in place.

Personally, I consider that a big disadvantage. =)

Again who really cares about the extra 1 second or so the DNS lookups will take - & of course most likely they're cached locally anyway after the first hit.

Currently our mail infrastructure is setup to first accept and THEN see if there's something wrong with the message - HOWEVER with the tidal wave of spam that now is more numerous than legit email this paradigm needs to be switched: email should first be REJECTED UNLESS there's compelling reasons to be accepted...

Of course these same checks could also be done the 'From:' & 'Reply-To:' headers - which I also think is a good idea but requires more intervention & maybe someone has a problem with looking into the headers BUT with spam being WAY out of control we gotta take more serious steps to stem the tide.

whatcha'll think? Mark

I agree in *theory* that proactive filtering is better than reactive filtering. However, most solutions of a proactive nature are flawed in that they attempt to still use non-trustworthy mechanisms such as SMTP.

IMHO, you simply cannot trust the SMTP service *at all* if you want to stop SPAM. Someday, people will (probably/hopefully?) find a way to stop SPAM... but I seriously doubt that it will include using SMTP to transfer mail. There quite simply is no way to set up a "trust" network -- other than using SSL for all connections which is "non-trival" at best, assuming that you don't want to *seriously* limit the number of domains that can talk to you... particularly since not all domains will ever bother with installing a "trusted" SSL cert on their systems while they cost as much as they typically do.

Just my $.02 worth.

-jab

_______________________________________________ courier-users mailing list cour@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users