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
------------------------------------------------------- This SF.net email is sponsored by Dice.com. Did you know that Dice has over 25,000 tech jobs available today? From careers in IT to Engineering to Tech Sales, Dice has tech jobs from the best hiring companies. http://www.dice.com/index.epl?rel_code=104 _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
