Question about Data Safety and VPN

On 28.09.2010 20:43, Didi wrote:

> The only way to for the sender to know the recipient has received
> its message is to talk directly to it - only in this case it will
> get instant feedback from the recipient.

That way is rather a theory-only possibility these days, though.

No ISP without a serious death-wish allows private end-users to send 
SMTP to anyone but the ISP's own servers any more.  Zombie botnets used 
as spam dispensers took care of making that a practical impossibility.

On Sep 29, 12:28=A0am, Hans-Bernhard Br=F6ker <HBBroe...@t-online.de>
wrote:
> On 28.09.2010 20:43, Didi wrote:
>
> > The only way to for the sender to know the recipient has received
> > its message is to talk directly to it - only in this case it will
> > get instant feedback from the recipient.
>
> That way is rather a theory-only possibility these days, though.
>
> No ISP without a serious death-wish allows private end-users to send
> SMTP to anyone but the ISP's own servers any more. =A0Zombie botnets used
> as spam dispensers took care of making that a practical impossibility.

I know this is how most ISPs work, mine used to be this way until
recently as well. They will probably restrict it again (they had a
corporate reshuffle recently and some accompanying chaos, probably
this is part of it).
So it is indeed a method I would not recommend in todays world,
it takes unrestricted internet access in order to work -  which is
unfortunately far from widely available. We have really no way to
verify email delivery within less than a week or so in most cases,
which can be a pretty major inconvenience.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

On Sep 28, 4:28=A0pm, Hans-Bernhard Br=F6ker <HBBroe...@t-online.de>
wrote:
> On 28.09.2010 20:43, Didi wrote:
>
> > The only way to for the sender to know the recipient has received
> > its message is to talk directly to it - only in this case it will
> > get instant feedback from the recipient.
>
> That way is rather a theory-only possibility these days, though.
>
> No ISP without a serious death-wish allows private end-users to send
> SMTP to anyone but the ISP's own servers any more. =A0Zombie botnets used
> as spam dispensers took care of making that a practical impossibility.


I've dealt with several (home/residential/personal) ISPs that have
allowed ordinary outbound SMTP (port 25) on request.  It's very
frequently a setting on the router they put in your house, or sometime
at their end, and their tech support can usually turn it on.
Obviously not a guarantee, but I've done it several times.  I=92ve also
seen some cases where the normal authenticated SMTP/POP ports (from
memory, 587/487??) are open by default.  And even if they weren=92t,
changing those on your mail server is generally easy enough.  And you
probably don=92t want to open port 25 for a special purpose like this
(unless you=92re using your existing mail server).

But business class internet access never has such a restriction.

On 2010-09-28, Didi <dp@tgi-sci.com> wrote:

> If you want it to be "real time", only the email address is
> insufficient. As larwe explained the message can travel through many
> relaying stations, timing out possibly after days (so the sender
> won't know whether the message was delivered or failed for days). The
> only way to for the sender to know the recipient has received its
> message is to talk directly to it - only in this case it will get
> instant feedback from the recipient.

Even that doesn't work.

Some mail servers will accept+discard mail to unknown addresses. [That
way you can use the SMTP server as a way to test for valid usernames
or email addreses.]

The message might also be discarded as spam, lost because a parition
or quota is full, or just plain dropped down the drain by the user's
MUA.

The only way you know an e-mail was received is when you get a _reply_
from the person to whom you sent it.

-- 
Grant

On Sep 29, 2:59=A0am, Grant Edwards <inva...@invalid.invalid> wrote:
> On 2010-09-28, Didi <d...@tgi-sci.com> wrote:
>
> > If you want it to be "real time", only the email address is
> > insufficient. As larwe explained the message can travel through many
> > relaying stations, timing out possibly after days (so the sender
> > won't know whether the message was delivered or failed for days). The
> > only way to for the sender to know the recipient has received its
> > message is to talk directly to it - only in this case it will get
> > instant feedback from the recipient.
>
> Even that doesn't work.
>
> Some mail servers will accept+discard mail to unknown addresses. [That
> way you can use the SMTP server as a way to test for valid usernames
> or email addreses.]
>
> The message might also be discarded as spam, lost because a parition
> or quota is full, or just plain dropped down the drain by the user's
> MUA.
>
> The only way you know an e-mail was received is when you get a _reply_
> from the person to whom you sent it.
>
> --
> Grant

I said "delivered", not received. Once the smtp transaction is
complete
with no error, the sender knows it has delivered the message.

What the recipient will do with the message it has accepted is
another matter, it may delete it instantly or carve it in
stone, someone may then read the stone or use it to bang someones
head with it.

For the not quite sane application under discussion (delivering
some kind of control messages over email, which is pretty much
nonsense nowadays), some knowledge of both sides will
be anyway needed and how the incoming message is dealt with will
be part of the system design job.
Then if the purpose of using email is just to have the messages
archived on some readily available system (which might even be
a sane choice), setting that particular machine up correctly
won't be such a huge issue.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

On 28/09/2010 23:28, Hans-Bernhard Br�ker wrote:
> On 28.09.2010 20:43, Didi wrote:
>
>> The only way to for the sender to know the recipient has received
>> its message is to talk directly to it - only in this case it will
>> get instant feedback from the recipient.
>
> That way is rather a theory-only possibility these days, though.
>
> No ISP without a serious death-wish allows private end-users to send
> SMTP to anyone but the ISP's own servers any more. Zombie botnets used
> as spam dispensers took care of making that a practical impossibility.

Haven't you noticed the amount of spam that is flooding the internet? 
Almost all ISP's /do/ allow end-users to send SMTP to anyone.

The unfortunate reality is that there a vast numbers of misconfigured 
Exchange servers out there that are sending SMTP directly to receiving 
mail servers rather than via their ISP's mail relay servers, and the 
Exchange server administrators don't have proper routing, mx records, 
reverse DNS, etc., set up.

(I blame Exchange explicitly here, since it is almost always Exchange 
servers that are incorrectly configured and/or are missing DNS 
information.  People who install Linux (or other *nix) mail servers 
typically know much more about what they are doing.  The problem is with 
companies that are big enough to have their own servers, but too small 
to employ or hire in competent administrators.)

This means there is a great deal of legitimate SMTP traffic around which 
ISP's have very little control over.  There is no way to check it for 
legitimacy based on the sender addresses and domains.

Add to that the perfectly legitimate use of SMTP from client 
applications to non-local servers (for example, connecting from a laptop 
to the company server).


So if an ISP blocks arbitrary SMTP communication, email collapses for 
their customers.  It /could/ be done much better - if server 
administrators were required to set their dns records appropriately 
(easy to do, and easy to check), and all servers required user names and 
passwords (and preferably SSL) for all non-local client connections, 
then the world could be free of spam and email viruses.

In article <02f9602a-5c1e-4a9f-9614-
5156779067ad@d17g2000yqm.googlegroups.com>, dp@tgi-sci.com says...
> 
> On Sep 29, 2:59&#4294967295;am, Grant Edwards <inva...@invalid.invalid> wrote:
> > On 2010-09-28, Didi <d...@tgi-sci.com> wrote:
> >
> > > If you want it to be "real time", only the email address is
> > > insufficient. As larwe explained the message can travel through many
> > > relaying stations, timing out possibly after days (so the sender
> > > won't know whether the message was delivered or failed for days). The
> > > only way to for the sender to know the recipient has received its
> > > message is to talk directly to it - only in this case it will get
> > > instant feedback from the recipient.

That is only true if you know 100% that the receiving machine is only
ONE actual machine, that does not forward to yet another machine as a
cluster/forest/etc..

Also that the machine is not the general machine used for other things
as well (even that locations mailstore).

> > Even that doesn't work.
> >
> > Some mail servers will accept+discard mail to unknown addresses. [That
> > way you can use the SMTP server as a way to test for valid usernames
> > or email addreses.]
> >
> > The message might also be discarded as spam, lost because a parition
> > or quota is full, or just plain dropped down the drain by the user's
> > MUA.
> >
> > The only way you know an e-mail was received is when you get a _reply_
> > from the person to whom you sent it.
> >
..
> I said "delivered", not received. Once the smtp transaction is
> complete
> with no error, the sender knows it has delivered the message.

Deleivered, only means accepted by the front facing part of the email
server, and may not be really delivered and still can be bounced.

Fully delivered means accepted and barring special filtering rules
(spam/blocked sender) is guaranteed to be stored at that MTA.

For many years Exchange (and a few others) have the nasty habit of
accepting message and depending where the final mailstore of the server
is do "Oh shit drop this email into the bit bucket". Most notably for
the situations of

   Disk drive full
   Mailbox over quota.

If you are lucky you might get a bounce message, more often than not
it drops into a bit bucket. Basically because the actual storing
of the message is a secondary phase, after the smtp transaction has 
closed.

This is quite common, and I have rarely come across good Exchange 
setups, as management sees "anything on Windows can be setup using
wizards".
 
> What the recipient will do with the message it has accepted is
> another matter, it may delete it instantly or carve it in
> stone, someone may then read the stone or use it to bang someones
> head with it.

After actual delivery, anything can happen.

> For the not quite sane application under discussion (delivering
> some kind of control messages over email, which is pretty much
> nonsense nowadays), some knowledge of both sides will
> be anyway needed and how the incoming message is dealt with will
> be part of the system design job.
> Then if the purpose of using email is just to have the messages
> archived on some readily available system (which might even be
> a sane choice), setting that particular machine up correctly
> won't be such a huge issue.

But often archives get forgotten and when someone goes to look at
it then finds, we have not had any new messages for 'n' months to
find out the disk/mailstore is full or mailbox over quota.


-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

On Sep 29, 10:44=A0am, Paul <p...@pcserviceselectronics.co.uk> wrote:
> In article <02f9602a-5c1e-4a9f-9614-
> 515677906...@d17g2000yqm.googlegroups.com>, d...@tgi-sci.com says...
>
>
>
> > On Sep 29, 2:59=A0am, Grant Edwards <inva...@invalid.invalid> wrote:
> > > On 2010-09-28, Didi <d...@tgi-sci.com> wrote:
>
> > > > If you want it to be "real time", only the email address is
> > > > insufficient. As larwe explained the message can travel through man=
y
> > > > relaying stations, timing out possibly after days (so the sender
> > > > won't know whether the message was delivered or failed for days). T=
he
> > > > only way to for the sender to know the recipient has received its
> > > > message is to talk directly to it - only in this case it will get
> > > > instant feedback from the recipient.
>
> That is only true if you know 100% that the receiving machine is only
> ONE actual machine, that does not forward to yet another machine as a
> cluster/forest/etc..

Well yes, knowledge of both sides was implied, perhaps not clearly
enough, in my original post.

> ...
> Deleivered, only means accepted by the front facing part of the email
> server, and may not be really delivered and still can be bounced.
>
> Fully delivered means accepted and barring special filtering rules
> (spam/blocked sender) is guaranteed to be stored at that MTA.
>
> For many years Exchange (and a few others) have the nasty habit of
> accepting message and depending where the final mailstore of the server
> is do "Oh shit drop this email into the bit bucket". Most notably for
> the situations of
>
> =A0 =A0Disk drive full
> =A0 =A0Mailbox over quota.

 This can occur, but since knowledge of both sides is necessary
anyway it should not be a problem. Then - to completely
madden things up - the sender can be made to
receive emails (again as a direct server to avoid days' delays) and
thus see the bouncing messages... (how far can we push that nonsense
I am guilty of originating is yet to be seen :-) )

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/