Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?
From: Don Sykes (anonymous_at_pacbell.net)
Date: Mon, 29 Sep 2003 20:02:36 GMT
> In article <3F74CF7F.9D265CA@pacbell.net>, Don Sykes <email@example.com> writes:
> >firstname.lastname@example.org wrote:
> >> In article <email@example.com>, "John Vottero" <John@mvpsi.com> writes:
> >> ><firstname.lastname@example.org> wrote in message
> >> >news:email@example.com...
> >> >> In article <3F71D664.D92AAC37@pacbell.net>, Don Sykes
> >> ><firstname.lastname@example.org> writes:
> >> >> >
> >> >> >email@example.com wrote:
> >> >> >>
> >> >> >> In article <3F70934A.3C36DD45@pacbell.net>, Don Sykes
> >> ><firstname.lastname@example.org> 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)
> 1 -> 3 -> 4 (1st organisation doesn't have central mailhub or doesn't
> force mail to pass through it)
> 1 -> 2 -> 4 (2nd organisation does not have a central mailhub or
> doesn't force mail to go through it)
> 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 22.214.171.124 port 7521 on the public side of his home
> >> NAT/firewall. (126.96.36.199 is the single public address given out to this user by
> >> his ISP).
> >> This connection connects to the IPS's receiver on 188.8.131.52 (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 (184.108.40.206) attempts to open connection to 220.127.116.11 on port 1398.
> >> Attempt fails. There is either no entry in the NAT mapping table for
> >> 18.104.22.168 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
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
> 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
> (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
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
> 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
> Middlesex University
> >Have VMS, Will Travel
> >Wire paladin, San Francisco
-- Have VMS, Will Travel Wire paladin, San Francisco (paladinATalphaseDOTcom)