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

david20_at_alpha1.mdx.ac.uk
Date: 10/02/03 

Date: Thu, 2 Oct 2003 12:35:45 +0000 (UTC)

In article <3F7B8754.3623EC0F@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes:
>
>
>david20@alpha2.mdx.ac.uk wrote:
>>
>> In article <3F79CE46.5E40D800@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes:
>> >
>> >
>> >david20@alpha2.mdx.ac.uk wrote:
>> >>
>> >> In article <blag7c$kfg$1@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes:
>> >> >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 receiver is in compete control. If it doesn't like something it sends back
>> a 5xx response and closes the connection.
>
>The receiver can set aside accepting an email until a time more
>convenient to them. They're not required to accept mail at the
>convinience of the sender. This allows options that are impossible in a
>one phase protocol, like retrieving large or low priority emails during
>slow times and sending a pre-email notification to the user - e.g.
> I have a request from smutpeddler@legitdomain.com, do you want to
>accept a 2MB avi file? do you want to charge him? If so, how much?
>that sort of thing. A one phase protocol requires a continuous
>interaction until the mail is rejected or accepted.
>

You are at least one level away from the sender or receiver at the central
mailhub level. Your default policy is you are going to delay all mail not
explicitly requested by the user ?
My mail users complain that mail is not instantaneous. They expect it to all be
instantaneous. Adding extra delays is not acceptable. Even if a simple method
is supplied for them to update what they want to delay on the central mailhub
they won't immediately update it after they get off the phone to that new
contact who is going to mail them - that is if they remember to get his email
address rather than just telling him theirs.
Anyone running a central mailhub will immediately turn off any such delays.

>>
>>
>> >> At the moment there does exist a small possiblity of spoofing however your
>> >> system is exactly as vulnerable as the current standards
>> >
>> >I don't agree, because in phase 2 the receiver initiates the connection.
>> >So unless the spoofer can control the DNS I don't see how they will ever
>> >get their message delivered.
>> >And if they can control the DNS, they can jolly well force all of us to
>> >a smut site when we try to http to Google.com.
>>
>> Yes as I say a small chance of spoofing which is exactly the same for the
>> current protocol since it can do exactly the same DNS lookup.
>> Since this is at the central mailhub rather than the desktop sender level the
>> chances of anyone wanting to spoof this are pretty remote anyway. Any spoofing
>> would be done between the desktop system and the central mailhub.
>
>Give me an example of what you mean. I don't see it. When the desktop
>user goes to retrieve his mail he logs onto a POP or IMAP server, passes
>his userid & password and downloads the mails that are waiting for him.
>Where would the spoofing occur?
>

I'm talking about in sending the mail from the desktop to the central server
in order to avoid being charged.

>>
>> As to controlling the DNS and redirecting to smut sites - yes it happens all
>> the time. Though the preference is usually to redirect to their own version
>> of a companies site so they can gather credit card and other details.
>>
>> >
>> >> - this can be improved
>> >> in the future by use of server certificates and SSL/TSL to provide more
>> >> trustworthy mutual authentication.
>> >>
>> >> The problems of identity are to do with tracking within organisations, with
>> >> non-compliant and badly configured mail systems and with open relays.
>> >> These are NOT protocol issues. Nobody should be running an open-relay -
>> >> there is even an RFC which states this - RFC 2505.
>> >
>> >I don't run an open relay and I can't stop the 100's of spams per day or
>> >force anyone to pay if I deliver a spam message to an end user.
>> >
>>
>> But apart from the fee paying idea which won't work unless you really know who
>> to charge the fee to your protocol doesn't provide anything extra which will
>> control spammers.
>
>Apart from that, Mrs Lincoln, how was the play?
>The fee IS the pertenient point.
>
>>
>> >I agree that identity problems WITHIN an organisation are not solved by
>> >this, but that' by design. IMO all those problems are implementation
>> >issues, ones, I might add, that are just as likely to cause problems
>> >using any protocol.
>> >
>>
>> What I am saying is your protocol is irrelevent. Communications between central
>> mailhubs are already adequately controlled. It is the injection of spam into
>> the sending central mailhubs and direct sending of mail bypassing central
>> mailhubs which need controlling.
>
>How can you bypass the receiving ESP? Example please.

I'm talking abiout the current setup. Not everybody has central mailhubs,
not everybody has firewall rules blocking direct sending from desktop machines.

>
>> Unfortunately even after solving those problems we will still be left with
>> open-relays and misconfigured or non-compliant systems. The systems which were
>> being put in place to handle those - blacklists - have been hounded out of
>> existence by court proceedings and latterly by targeted denial of service
>> attacks.
>>
>> >> I note in passing that your protocol is actually pretty weak on this :-
>> >>
>> >> "The receiving ESP has no obligation to relay messages outside of its own
>> >> domain"
>> >
>> >The point of this statement is to clarify that this protocol doesn't
>> >deal with issues of routing beyond the receiver ESP. If they want to
>> >route beyond their domain, that's their business.
>> >
>>
>> NO system should ever be configured as an open-relay.
>>
>> >>
>> >> The only features of your protocol different from current ESMTP implementations
>> >> are :-
>> >>
>> >> 1) Two separate connections - As stated above this is pretty pointless.
>> >
>> >Not at all pointless as I mentioned. Control of the mail receipt is in
>> >the hands of the receiver.
>>
>> Control in the current protocol is in the hands of the receiver without any
>> need for a second connection.
>
>Partial control in the current protocol. Full control in a 2 phase
>protocol.
>

I get the impression that your model is the telephone system and dialback
modems. IP has always had a super charged version of caller-id display.
It knows what number called it and can do a lookup in it's equivalent of
yellow pages - the DNS - to confirm validity of that address.
Dialback gains you nothing - Many companies still use it but the major reason
nowadays is so that the Company is paying for the phonecall.

>>
>> >
>> >> 2) The provision of attachment numbers, sizes and mime types up front before
>> >> the actual data is passed.
>> >> I'm not sure of the point of this.
>> >
>> >The point is to allow the receiver ESP to use this info in deciding
>> >whether to accept this message. Maybe a policy is not to accept msword,
>> >due to the infection possibilities. Or maybe an organization doesn't
>> >want avi or other video.
>> >
>> >> Virus writers and Microsoft products
>> >> either lie or ignore this information.
>> >
>> >Yes, they can, but if you try to launch an msword attachment as an exe
>> >it's not going to work. Mail readers use the MIME info to decide
>> >whether, and how, to launch it. So lying isn't going to get you what you
>> >want.
>> >
>> Microsoft products ignore the MIME type they use the file extension.
>> This is why most mailhubs have a large - ever growing - list of banned file
>> extensions.
>
>That's Microsoft's problem. Maybe they'll be more MIME compliant in the
>future if they see it's better for them to do so.
>

No it's your (and everybody elses) problem. Why should Microsoft change ?
People have been complaining about Microsoft's attitude to standards for years.
But so long as they have a dominent desktop position and can use their
tweaking/ignoring of standards to allow them to leverage that for dominence in
other areas they aren't likely to stop.
Microsoft are standards compliant - it's just it's their version of the
standard.

>>
>> >> Mime is also not the only encoding
>> >> mechanism used in mail messages - eg uuencoded mail, pgp encrypted mail etc
>> >> Also since this is at the central mailhub level only organisational level
>> >> checks and blocks can be done anyway.
>> >
>> >That depends completely on your implementation. For businesses like HP,
>> >they probably would use organizational-wide parameters. AOL on the other
>> >hand will defininately not. They will allow each user to specify all the
>> >options for themselves, including price.
>> >
>> How ? Your protocol is central mailhub to central mailhub it says nothing about
>> any mechanism for a user to request these options.
>
>Of course it doesn't. Why should it? SMTP doesn't tell you to do an RBL
>lookup, or to go check a user list when you get a RCPT_TO:
>anybody@abc.com. That's up to whoever is implemting the receiver
>service. E.G. HP's TCPIP SMTP Service doesn't even give you the option
>to check a user's list.
>
SMTP never touted these as advantages to it's protocol - you are.
Hence you need to provide something more than handwaving.

To get people to buy into your new protocol you need to prove it is better
than the existing protocols. People have spent a lot of money on systems using
the existing protocols - they will need a bl**dy good reason to move to
something else. So far I don't see anything which improves on existing
protocols.

>>
>> >> I cannot see any reason for wanting to
>> >> specify individual size blocks for different Mime types.
>> >
>> >Options. Just because you can't see it now, doesn't mean you won't see a
>> >reason for it in the future. The "cost" to provide it is zero, so why
>> >not give the option.
>> >
>> >> ESMTP can already apply blocks up front for actual size of messages, numbers
>> >> of recipients etc
>> >>
>> >> 3) The provision of fee charging.
>> >>
>> >> Assuming that 100% identification could be achieved which is a prerequisite
>> >> for any charging system.
>> >> Firstly the costs per MB or whatever should be up front before any sending
>> >> of from or recipient addresses. THis could be achieved with ESMP with costs
>> >> being relayed back to the sender in response to the EHLO command.
>> >> Rather than providing a new protocol the additional commands required for a
>> >> feebased system could be added to ESMTP - thats the whole point of ESMTP it
>> >> is extensible.
>> >
>> >Unless ESMTP provides that 2nd phase, it's not going to be effective.
>> >
>>
>> As I have said time and time again your second connection provides absolutely
>> nothing.
>
>See previous responses.
>
>>
>> >>
>> >> In short I don't see that this protocol provides anything not already
>> >> available in the existing protocols (or which could not be added - in the
>> >> case of charging). In particular it does not provide any additional help
>> >> in identifying the sender of a piece of mail.
>> >>
>> >
>> >That's the beauty, I don't have to care who the sender is if I can
>> >collect a fee for receiving it!
>> >
>>
>> Good luck in trying to collect that fee. The lawyers will make a lot of money
>> I doubt you will.
>
>I'm not trying to make a lot of money on this. If there is continuing
>trouble collecting fees from an ESP they will be marked as such by
>eosawki.org.
>

Sorry I didn't mean you personally. Just saying that any fee based system
which doesn't provide full end to end accountability will be open to all sorts
of legal challenges.

David Webb
VMS and Unix team leader
CCSS
Middlesex University

>
>
>--
>
>Have VMS, Will Travel
>Wire paladin, San Francisco
>
>(paladinATalphaseDOTcom)

Relevant Pages

  • Re: Processs PreciseMail AntiSpam Gateway - any experience so far ?
    ... But the key phrase here is "The receiver CAN". ... In my model, the priority would not ... > you don't need any new protocol to stop spam - a very simple mail filter will ... > Not every organisation has a single central mailhub. ...
    (comp.os.vms)
  • Re: Processs PreciseMail AntiSpam Gateway - any experience so far ?
    ... >> Ok I've now read the latest version of your protocol. ... >> connection from the receiver to the sender adds nothing to this. ... The sender "central mailhub" may have one port opened for listening - but since ... Please tell me where the extra control for the receiver from this second ...
    (comp.os.vms)
  • Re: Processs PreciseMail AntiSpam Gateway - any experience so far ?
    ... >>allow end receivers to charge a fee for questionable email. ... If the meta data doesn't pass muster, the receiver leaves the ... > Please tell me where the extra control for the receiver from this second ... A one phase protocol requires a continuous ...
    (comp.os.vms)
  • Re: Processs PreciseMail AntiSpam Gateway - any experience so far ?
    ... That's up to what the domain (ESP) wants to do. ... >> is supplied for them to update what they want to delay on the central mailhub ... The receiver can set aside accepting an email until a time more ... you don't need any new protocol to stop spam - a very simple mail filter will ...
    (comp.os.vms)
  • Re: Processs PreciseMail AntiSpam Gateway - any experience so far ?
    ... >} However until a majority have signed up it pays for an ISP NOT TO charge. ... As the second version of this makes clear this protocol is central mailhub to ... Neither the sender or receiver are the desktop user. ...
    (comp.os.vms)