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

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

Date: Sun, 28 Sep 2003 17:47:15 +0000 (UTC)

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

>> 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 other thing I don't understand is why you think closing down the connection
stops the spammer impersonating another system.
(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.

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)

Relevant Pages

  • Re: interfaces lo:1 lo:2 lo:3? (for remote ssh tunnels)
    ... That's the problem tunneling (port forwarding) solves. ... >>can't get past the client firewall. ... > I don't understand why the server would be making the ... server initiates another connection to the client -- in this ...
    (Debian-User)
  • Re: Using Remote Desktop From an SBS Domain
    ... when you tried to RDP while attached directly to a port on your router? ... So if 3389 needs forwarded on the client end too then that is what the ... Hopefully next week I can attempt a connection while my ISP watches the ...
    (microsoft.public.windows.server.sbs)
  • RE: Telnet/ftp problems SBS2000
    ... Please make sure your client computers are configured as both Firewall ... will find two options "Enable folder view for FTP sites" and "Use Passive ... that the control connection has been successfully established, ... (other than port 21) ...
    (microsoft.public.windows.server.sbs)
  • Re: One workstation cant access email from ISP - CROSSPOST
    ... Remove or disable the ISA Firewall client. ... Ethernet adapter Wireless Network Connection: ... Switch is nothing more than a patch panel; ... port - same result. ...
    (microsoft.public.exchange.admin)
  • Re: Processs PreciseMail AntiSpam Gateway - any experience so far ?
    ... >> another machine or port on the user's home network. ... >> connection to an external machine having been made or by the user explicitly ... > use a well-known port that the NAT firewall forwards to the client ...
    (comp.os.vms)