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/
Reply by Paul●September 29, 20102010-09-29
In article <02f9602a-5c1e-4a9f-9614-
5156779067ad@d17g2000yqm.googlegroups.com>, dp@tgi-sci.com says...
>
> On Sep 29, 2:59�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.
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.
Reply by Didi●September 28, 20102010-09-28
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/
Reply by Grant Edwards●September 28, 20102010-09-28
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
Reply by robe...@yahoo.com●September 28, 20102010-09-28
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.
Reply by Didi●September 28, 20102010-09-28
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/
Reply by ●September 28, 20102010-09-28
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.
Reply by like2learn●September 28, 20102010-09-28
On Sep 28, 1:53=A0pm, David Brown
<david.br...@hesbynett.removethisbit.no> wrote:
> On 28/09/2010 18:46, like2learn wrote:
>
>
>
>
>
> > I would like to develop a smart sensor, which is an embedded device
> > running linux. The sensors collect the data from the field, then pass
> > the data to the server at the office. To avoid hack and protect data
> > safety, I am thinking about implementing VPN at both the sensor side
> > and server side. Now I have a few questions?
>
> > 1. Is VPN the best solution for data security about this type of
> > applications? My application will require about typically 10 sensors,
> > (ax. 100), to be connected to one server, and the data volume is
> > moderate (possibly 10MB data from a sensor per day.
>
> > 2. There are quite several VPN technologies available for Linux, say
> > IPSec VPNs (Openswan, KAME), SSL-Based VPNs (OpenVPN), PPTP-Based VPNs
> > (PoPToP), etc. Which seems the best solution for my application in
> > terms of the development cost and maintaince cost?
>
> > 3. Does VPN cast any restriction on the Internet protocols used for
> > data communication? For example, HTTP, TELNET, SOCKET, etc. I don't
> > think so, but I want to confirm.
>
> > 4. Does email can be used as a cheap replacement of VPN solutions?
> > This way we possibly can take advantage of the security measure of
> > commercial email system, and it is free. What are the pros and cons?
>
> > Thank you!
>
> A VPN makes sense if you want to make many different connections over
> the link, or if the connection you want to make has lots of ports. =A0For
> example, a VPN is useful if the sensor is looking for DNS information
> from the server as well as passing sensor data back and forth, or if it
> has to use awkward protocols like NFS or CIFS. =A0It also makes it easy t=
o
> contact the sensor via telnet or ssh since it is effectively attached to
> the server's local network.
>
> If you only need a single connection, using an SSL-based protocol is
> probably the easiest solution (either a custom protocol or a standard
> one). =A0You can also use ssh as a simple way to tunnel another protocol
> over a secure connection. =A0If you only have a port or two to tunnel, an=
d
> it's all tcp/ip, then this is a "lighter" method.
>
> If you choose to go for a VPN then I strongly recommend OpenVPN. =A0It is
> easy to configure, the client (and server) can run on practically any
> system, and it has no problem passing through NAT or other routers that
> can be a challenge with IPSEC VPNs.- Hide quoted text -
>
> - Show quoted text -
Isn't it great? Thank you very much for sharing your knowledge!
Reply by David Brown●September 28, 20102010-09-28
On 28/09/2010 18:46, like2learn wrote:
> I would like to develop a smart sensor, which is an embedded device
> running linux. The sensors collect the data from the field, then pass
> the data to the server at the office. To avoid hack and protect data
> safety, I am thinking about implementing VPN at both the sensor side
> and server side. Now I have a few questions?
>
> 1. Is VPN the best solution for data security about this type of
> applications? My application will require about typically 10 sensors,
> (ax. 100), to be connected to one server, and the data volume is
> moderate (possibly 10MB data from a sensor per day.
>
> 2. There are quite several VPN technologies available for Linux, say
> IPSec VPNs (Openswan, KAME), SSL-Based VPNs (OpenVPN), PPTP-Based VPNs
> (PoPToP), etc. Which seems the best solution for my application in
> terms of the development cost and maintaince cost?
>
> 3. Does VPN cast any restriction on the Internet protocols used for
> data communication? For example, HTTP, TELNET, SOCKET, etc. I don't
> think so, but I want to confirm.
>
> 4. Does email can be used as a cheap replacement of VPN solutions?
> This way we possibly can take advantage of the security measure of
> commercial email system, and it is free. What are the pros and cons?
>
> Thank you!
>
A VPN makes sense if you want to make many different connections over
the link, or if the connection you want to make has lots of ports. For
example, a VPN is useful if the sensor is looking for DNS information
from the server as well as passing sensor data back and forth, or if it
has to use awkward protocols like NFS or CIFS. It also makes it easy to
contact the sensor via telnet or ssh since it is effectively attached to
the server's local network.
If you only need a single connection, using an SSL-based protocol is
probably the easiest solution (either a custom protocol or a standard
one). You can also use ssh as a simple way to tunnel another protocol
over a secure connection. If you only have a port or two to tunnel, and
it's all tcp/ip, then this is a "lighter" method.
If you choose to go for a VPN then I strongly recommend OpenVPN. It is
easy to configure, the client (and server) can run on practically any
system, and it has no problem passing through NAT or other routers that
can be a challenge with IPSEC VPNs.