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, [EMAIL PROTECTED]
> 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
>
>
>
> -------------------------------------------------------
> 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
>
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
