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

From: John Santos (JOHN_at_egh.com)
Date: 09/27/03 

Date: Fri, 26 Sep 2003 22:20:33 -0400

On Fri, 26 Sep 2003 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:
> >> >> >
> >> >
> >> >At this point I'm fairly convinced that the implementation of fees via
> >> >central gateways &/or routers is not workable. So I have come up with a
> >> >protocol that implements e-mail in 2 phases: a meta phase and a data
> >> >phase. In phase 1, all the info about the email is sent to the open,
> >> >listening port of the receiver. Then the link is dropped, by both.
> >> >Phase 2 must be initiated by the receiver, so they are in complete
> >> >control of the transmission and final delivery and at that point they
> >> >can also charge a fee.
> >> >
> >> >A first draft is available at http://alphase.com/vms/FBEProtocol.html
> >> >
> >> >Serious suggestions are more than welcome, but please no nit-picking.
> >> >This is a early, early draft. A suggestion, if you will
> >> >
> >>
> >> I haven't had a chance to look at your link yet but one thing strikes me
> >about
> >> your suggestion straight away. How are you going to deal with Natt'd
> >clients ?
> >> If you drop the connection then there is no guarantee that the public
> >address
> >> that the sender first used will still be valid when the receiver tries to
> >> reopen the connection.
> >>
> >
> >There is no need to be concerned about NAT. This proposal is a replacement
> >for SMTP servers. They already need special consideration when used with
> >NAT, as do all listening servers.
> >
> >
>
> It does matter because your example which uses a client on the 10 address space
> (10.11.12.1) contacting a server on the 21.22 network will not work in general.
>
> (As an aside the address of the receiver 21.22.0.0 is invalid since it is a
> network address - you should never use .0 or .255 in the final octet).
>
> The 10 address is a private address hence must use NAT to contact systems on
> the public internet.
>
> 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.

I don't think I understand the point of the second, reverse connection[1],
but in any case, there is an alternate method that might work.

Instead of negotiating a port number for the 2nd connection, you could
use a well-known port that the NAT firewall forwards to the client
system, and negotiate a magic key (perhaps encrypted). The client
listens on the well-known port, the server establishes the call-back,
and sends the key. The client can accept the key and continue or
reject it and close the connection.

Both ends could be behind NAT'ing firewalls, and this would still
work, since the client could accept connections from anywhere, then
immediately close those that didn't provide a valid outstanding
key.

Both sides would know who they were talking to because of the key
exchange.

If you have multiple systems behind a NAT firewall, each could be
permanently assigned a port, which would be port-forwarded to its
well-known port, and that port could be included in the negotiations,
so the server would know what port to connect to. That port could
be statically configured in the NAT box and the client system, or
could be configured dynamicly using an extension to DHCP.

[1] Is ths second reverse connection just so the client and server
can go away for awhile to meditate on whether to allow the message
to propagate, or is it so the actual data message can be postponed
to a less busy time, if necessary (middle of the night), or is it
just to allow the server some measure of "control" over the connection?
If the last, why can't it just send a "no way" message at any point
during the negotiations, and close the socket? If a spamming client
is persistent, the server could just put it on a local black-list,
and refuse all connections from it for a while. 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

Relevant Pages

  • Re: Processs PreciseMail AntiSpam Gateway - any experience so far ?
    ... Client sending system ... >> ISP using dynamic NAT with port overloading. ... >> 10.11.12.1 is the clients real address and it opens a connection from its port ...
    (comp.os.vms)
  • 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)