Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?
From: Don Sykes (anonymous_at_pacbell.net)
Date: 09/29/03
- Next message: briggs_at_encompasserve.org: "Re: BACKUP Throughput measurement"
- Previous message: Paul Sture: "Re: BACKUP Throughput measurement"
- In reply to: david20_at_alpha2.mdx.ac.uk: "Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?"
- Next in thread: david20_at_alpha2.mdx.ac.uk: "Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 29 Sep 2003 20:02:36 GMT
david20@alpha2.mdx.ac.uk wrote:
>
> In article <3F74CF7F.9D265CA@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes:
> >
> >
> >david20@alpha2.mdx.ac.uk wrote:
> >>
> >> In article <vn5s22g2nrds0e@news.supernews.com>, "John Vottero" <John@mvpsi.com> writes:
> >> ><david20@alpha2.mdx.ac.uk> wrote in message
> >> >news:bkuhsq$dk3$1@news.mdx.ac.uk...
> >> >> In article <3F71D664.D92AAC37@pacbell.net>, Don Sykes
> >> ><anonymous@pacbell.net> writes:
> >> >> >
> >> >> >david20@alpha2.mdx.ac.uk wrote:
> >> >> >>
> >> >> >> In article <3F70934A.3C36DD45@pacbell.net>, Don Sykes
> >> ><anonymous@pacbell.net> writes:
> >> >> >> >
> >> >> >
> >> The 10 address is a private address hence must use NAT to contact systems on
> >> the public internet.
> >>
> >
> >I don't think your seeing this correctly. Which tells me I'll need to be
> >clearer in the next update.
> >This protocol is designed to be used between domain Email Service
> >Providers (ESPs), which must be resolveable thru a DNS lookup, which
> >IIRC MUST be a staic IP or range of static IPs.
> >
>
> Obviously not.
>
> You need to be a lot more clear.
I agree. Please read the latest update.
> As far as I am concerned their are upto 4
> parties involved in sending and receiving an email.
>
> 1) Client sending system
>
> 2) Client's ISP's mailhub
>
> 3) Receiver's ISP's mailhub
>
> 4) Receiver's mailbox holding system
>
> (I am ignoring the fact that within organisations there may well be other
> mailhubs through which a mail message may pass between 1 and 2 or between
> 3 and 4).
>
> With current protocols mail may transverse
>
> 1 -> 2 -> 3 -> 4 (mail passes between organisations central mailhubs)
>
> or
>
> 1 -> 3 -> 4 (1st organisation doesn't have central mailhub or doesn't
> force mail to pass through it)
>
> or
>
> 1 -> 2 -> 4 (2nd organisation does not have a central mailhub or
> doesn't force mail to go through it)
>
> or
>
> 1 -> 4 (Neither organisation has a central mailhub or neither
> force mail to go through them)
Not sure I understand this one. Is #4 listening on port 25?
>
> >> So in the real world you have a client on a small home network connecting to an
> >> ISP using dynamic NAT with port overloading.
> >>
> >> 10.11.12.1 is the clients real address and it opens a connection from its port
> >> 32100 this is mapped to 21.22.5.20 port 7521 on the public side of his home
> >> NAT/firewall. (21.22.5.20 is the single public address given out to this user by
> >> his ISP).
> >>
> >> This connection connects to the IPS's receiver on 21.22.0.10 (10 rather than 0
> >> to make it a valid address) for your phase 1.
> >>
> >> Negotiation proceeds as you describe on your link and the receiver sends back to
> >> say it will contact the sender on port 1398. Then the link is dropped.
> >>
> >> 10.11.12.1 listens on port 1398.
> >>
> >> Receiver (21.22.0.10) attempts to open connection to 21.22.5.20 on port 1398.
> >> Attempt fails. There is either no entry in the NAT mapping table for
> >> 21.22.5.20 port 1398 or if there is it would be accidental and might point at
> >> another machine or port on the user's home network.
> >> The connection is dropped.
> >>
> >> With dynamic NAT with port overloading (which is the most common form of NAT
> >> used on home networks where the home user has multiple machines hiding behind
> >> one external address) there is no preservation of port numbers - unless a port
> >> number has been placed in the NAT mapping table by an internally initiated
> >> connection to an external machine having been made or by the user explicitly
> >> setting up a manual mapping then an externally initiated connection cannot
> >> be made to it.
> >>
> >> Your system falls apart.
> >
> >Only if you're not the registered owner of the domain you're trying to
> >implement this on.
> >Basically, if you can run your own SMTP service (ie direct inbound port
> >25 connections to find their way to port 25 on a specific computer), you
> >can also run this.
> >As I said in a previous response, this is an implementation issue, which
> >will be resolved differently by different users.
> >
>
> I misread your protocol specification. I was assuming that the receiver
> randomly generated the port number and communicated that back to the sender
> before closing the connection. Instead you have the sender picking the port
> number. That makes it simpler for the spammer to send to multiple systems they
> can always specify the same port which they will listen on for the phase 2
> connections.
The sender defines the port number, because he has to be listening on it
for the phase 2 transfer. Wheather it's randomly generated or not is an
implementation issue. I would expect it to be random, or assigned from a
list, if the receiver ESP can make that work. If not, they can define a
fixed one, but even so, it's no more spam-easy then the current port 25
expectation.
>
> The other thing I don't understand is why you think closing down the connection
> stops the spammer impersonating another system.
I don't think that. Closing the connection in phase 1, just ends the
meta phase. Phase 2, as far as the receiver ESP is concerned, is
optional.
> (Though at the moment I doubt any spammer really impersonates another system
> anyway - they try to obfurscate received lines but I seriously doubt any
> actually spoof ip addresses - why should they when they can get a free account
> from tons of ISPs no question asked)
>
> For a fee based system you would have to be 100% certain of the senders
> identity. Your protocol is based on the IP address this is inherently
> unreliable.
Yes. This was addressed. It now uses the domain name. Now if the
receiver wants to "pick up" the message that was defined in phase 1, he
does a DNS lookup for the domain name and requests a connection to the
port defined by the sender. If a spammer connected to that port they
would have to know the mailid of a pending email. Unlikely and of course
they still wouldn't be able to send anything.
>
> For instance
>
> client connects to his ISP and gets address a.b.c.d
>
> Client uses public domain tool like dsniff to poison the local routers arp
> cache so that packets to and from a.b.c.e are directed to his system.
>
> Client then sends mail as if from a.b.c.e
>
> All responses, opening of new connections to a.b.c.e etc go to the machine at
> a.b.c.d
>
> As far as proving identity of users sending mail there do already exist
> protocols which could do this - unfortunately they suffer from the problem of
> not being implemented by everybody.
>
> 1) SMTP AUTH and SASL provide for authentication between the sender and the
> ISP's central mailhub. Note this is based on the user sending the mail
> message NOT on the IP address of the client.
>
> 2) SMTP over SSL/TSL.
> This primarily provides for encryption between mail systems. However as a by
> product the certificates involved provide for mutual authentication between
> central mail servers.
>
>
> But as stated above as long as ISPs give out free accounts without requiring
> proof of the identity of the person who is going to use that account then no
> amount of technical identification of the IP address or user account used will
> have any effect on the amount of spam sent.
>
> David Webb
> VMS and Unix team leader
> CCSS
> Middlesex University
>
> >--
> >
> >Have VMS, Will Travel
> >Wire paladin, San Francisco
> >
> >(paladinATalphaseDOTcom)
-- Have VMS, Will Travel Wire paladin, San Francisco (paladinATalphaseDOTcom)
- Next message: briggs_at_encompasserve.org: "Re: BACKUP Throughput measurement"
- Previous message: Paul Sture: "Re: BACKUP Throughput measurement"
- In reply to: david20_at_alpha2.mdx.ac.uk: "Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?"
- Next in thread: david20_at_alpha2.mdx.ac.uk: "Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|