Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?

david20_at_alpha2.mdx.ac.uk
Date: 09/30/03 

Date: Mon, 29 Sep 2003 23:45:48 +0000 (UTC)

In article <3F789087.7B990DE0@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes:
>
>
>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?
>

4 is where the user's mail is actually delivered and stored. The mail may then
be picked up from that mail store via pop, imap etc
Typically the central mailhub will deliver the message to that mailstore via
SMTP.

eg

    mail from outside

      |
      | SMTP
     \ /

3) Middlesex university central mailhub - running PMDF

     | SMTP
     |
    \ /

    Internal systems holding users mailboxes
    eg

4) Sun System
    PMDF VMS system
    Microsoft Exchange server
    etc

>>
>> >> 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.
>

If the sender defines it then you can't insist it is random.
As I said above I'm not quite sure in your protocol who the sender and receiver
actually are.
If the sender is a desktop system in an organisation utilising NAT and firewall
rules then it is highly unlikely that outside systems will be able to connect
to port 25 on such systems. Furthermore the owner of the desktop system will
have NO control over this. The management of the organisation is not likely to
look favouribly on the idea of opening up an equivalent to port 25 on such
systems and if using dynamic NAT would probably find it impossible anyway.

>>
>> 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.
>
In that case I really don't see the point of having these two connections.
Setting up a new connection doesn't really give the receiver any more control.
After phase 1 completes it can just shutdown the connection if it doesn't want
to continue or continue using that same connection if it wants to continue.
This is what happens currently with ESMTP. The receiver can reject the message
after receiving the from, rcpt or data. It can inform the sender before
anything is sent that it will not accept messages above a certain size etc

>> (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.

Thats real great security. If you do a reverse lookup for a middlesex address
it will tell you absolutely nothing. We have a B class address which mostly
consists of a couple of NAT pools. All the addresses in those NAT pools are
registered in our external DNS with dummy names just so reverse lookups will
work. All it will tell you is that it came from some dynamic address at our
site. Now in our case we force all outgoing mail through our internal mailhub
(where we record the originating internal 10.x.x.x address) and then through
our external mailhub and thence to the outside world. Hence we can trace any
message that way.

>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.
>

As I described below they would just spoof the whole thing not just the phase 2
connection. IP numbers, DNS entries etc are easily spoofed. To be anything like
sure of identity you need to be dealing in certificates or shared secrets.
In the two protocols I mention below :-

SMTP AUTH generally uses a shared secret ( the user's username and password)
whereas
TSL/SSL uses certificates.

>>
>> 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)

Relevant Pages