Re: Finding a replacement for my ISP's smtp server

2014-08-05 Thread Rob Owens
On Mon, Jul 28, 2014 at 11:11:08AM -0700, Bob Holtzman wrote:
 On Mon, Jul 28, 2014 at 09:11:59AM -0600, Paul Condon wrote:
  On Mon, Jul 28, 2014 at 02:56:40PM +0100, Brian wrote:
   On Mon 28 Jul 2014 at 14:02:29 +0200, Slavko wrote:
   
Dňa Sun, 27 Jul 2014 13:02:18 +0100 Brian a...@cityscape.co.uk
napísal:

 He could check with nc.
 
   brian@desktop:~$ nc smtp.gmail.com 25
   220 mx.google.com ESMTP 19sm41008233wjz.3 - gsmtp
 

AFAIK, the port 25 have to used only for (inter-) servers connections,
the clients have connect via 587, the port 25 for client connections is
for backward compatibility only.
   
   How does the server tell the difference between talking to another
   server (which is acting as client) and what you call a client?
  
  I have found a script on the web that makes Mutt into a work-alike
  substitute for Thunderbird.
 
 IIRC list protocol suggests that if you have found a solution to a
 problem, you post it for others to see and use. I have found a
 script... with no other useful information is a waste of everyones
 time.
 
I didn't notice if Paul posted his script, so I'll post part of my mutt
config having to do with smtp:

set smtp_url = smtp://myu...@smtp.gmail.com:587/
set smtp_pass = mypassword

-Rob


signature.asc
Description: Digital signature


Re: Finding a replacement for my ISP's smtp server

2014-08-01 Thread Paul E Condon
On 20140731_2251+0100, Brian wrote:
 On Thu 31 Jul 2014 at 15:34:46 -0400, Jerry Stuckle wrote:
 
  On 7/31/2014 3:09 PM, Brian wrote:
   
   The point of my remark was that malware can operate on port 25 so there
   is nothing to prevent it operating on port 587. I was actually agreeing
   with you when you said Nothing. 
  
  Yes, but Port 587 requires (or at least should require) a login; Port 25
  never does for email destined for the domains being served by that MTA.
 
 I feel this is a repetition of a technical point we both agree on.
 
   I think that once you get to discussing the capabilities of the malware
   it acknowledges that port 587 presents no more problems to the malware
   than port 25; it simply depends on how good the malware is.  Which, as I
   originally queried, brings into question the efficacy of ISPs mandating
   its use.
   
   I'll not ask for ISP facts and figures to show how good port 587 is for
   them.
  
  Yes, it does - again, Port 587 requires a login - which adds a huge
  layer of complexity to the malware.
 
 I'm glad we can end this by both of us agreeing that it simply depends
 on how good the malware is.

Good malware? What a concept;-)

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140801225909.ga7...@big.lan.gnu



Re: Finding a replacement for my ISP's smtp server

2014-08-01 Thread Joel Rees
On Fri, Aug 1, 2014 at 8:05 AM, Jerry Stuckle jstuc...@attglobal.net wrote:
 On 7/31/2014 5:51 PM, Brian wrote:
 [...]
 I'm glad we can end this by both of us agreeing that it simply depends
 on how good the malware is.



 Yes, but the difference here is - sending to port 25 is pretty easy.
 Sending via port 587 is MUCH harder.  Hackers take the easy route; as
 long as Port 25 is available, they will send through it.  If Port 25
 ever should become unavailable to a large percentage of users, they may
 have to take the hard route.

Unpacking that a little further, one bad assumption when designing
security systems is that an easy, but possible route is equivalent to
a hard, but possible route.

Malware that fails to cover its tracks has been getting spammers
arrested lately. Covering tracks requires rather complex logic, logic
which can fail. When stuff fails, you have to test it or be willing to
accept the failures.

Testing is also hard work. Failures can result in jail time. And
getting a real job looks more reasonable now.

Sure, switching to port 587 is one of those tactics that helps ISPs
charge ransom money for basic services, but that's a symptom of bad
contract law and intellectual property law more than a symptom of
unsound technical specs.

(And, no, I'm not suggesting there is such a thing as good
intellectual property law.)

-- 
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAAr43iMaAneg+vLRPBheL9SL3_Dmp=wsUHX9RwLX6jBMb=1...@mail.gmail.com



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Celejar
On Mon, 28 Jul 2014 16:48:04 +0100
Darac Marjal mailingl...@darac.org.uk wrote:

...

 encryption such as GPG. If you care about people seeing who you write
 to, then don't use e-mail.

Or use an anonymous remailer.

Celejar


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140731091603.6963dae0d52329eb216af...@gmail.com



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Brian
On Mon 28 Jul 2014 at 19:16:08 -0400, Jerry Stuckle wrote:

 But they also are not in any violation of any RFC's.  No RFC says they
 have to provide port 25 connectivity to your system.

This is substantiated in RFC 5068

  http://tools.ietf.org/html/rfc5068

   This document offers no recommendation concerning the blocking of
   SMTP port 25 or similar practices for controlling abuse of the
   standard anonymous mail transfer port.  Rather, it pursues the
   mutually constructive benefit of using the official SUBMISSION port
   587 [RFC4409].


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140731143556.gh19...@copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Brian
On Mon 28 Jul 2014 at 19:57:52 +0100, Brian wrote:

 On Mon 28 Jul 2014 at 20:16:08 +0200, Slavko wrote:
  Dňa Mon, 28 Jul 2014 18:37:54 +0100 Brian a...@cityscape.co.uk
  napísal:
  
   Your observation that ISPs could also interfere with port 587 doesn't
   cheer me up. :)
  
  It is black side of the freedom...
 
 That hasn't done much to increase my cheerfulness. :)

I'm now in a much more cheerful state of mind:

   http://tools.ietf.org/html/rfc5068

Access Providers MUST NOT block users from accessing the external
Internet using the SUBMISSION port 587 [RFC4409].


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140731143633.gi19...@copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Brian
On Mon 28 Jul 2014 at 22:12:09 +0100, Joe wrote:

 On Mon, 28 Jul 2014 18:16:23 +0100
 Brian a...@cityscape.co.uk wrote:
 
  Port 25 then becomes used only for incoming messages to be sent to
  domains the server is responsible for? If so, that doesn't appear any
  different from the present situation. For relaying a login is
  perfectly understanable, but it can be done on port 25 too. What
  makes port 587 necessary?
 
 Simply to provide a standard port on which authentication is expected
 and used, leaving 25 for unauthenticated mail. An email sent to an
 arbitrary address will be unauthenticated, because none of us have
 authentication credentials for all the world's mail servers.
 Unauthenticated mail will be delivered only *to* the domains the
 receiving server is authoritative for, or relayed *to* anywhere, but
 only *from* domains which are explicitly configured in the server. I
 think the very basic Debian setup of exim4 allows the entry of such
 permitted relaying domains, and certainly the full configuration file(s)
 does so.

Thanks. Due to your post and speed reading an RFC or two I think I now
have a better understanding of what the IETF's intentions are. They do
not include encouraging the blocking of outbound port 25. However, in an
earlier mail

  https://lists.debian.org/debian-user/2014/07/msg01614.html

I said

   You have to authenticate yourself when you join your ISP's network.
   No further authentication is needed to use their SMTP server; you
   are a trusted user so TLS is therefore not required.

This is incorrect. I was working off my experience of my ISP's network
and my own. It may not be needed but an ISP can require authentication
to send mail in spite of knowing a machine is legitimately on its
network. 

The reason for doing it given is generally along the lines of:

   Much of the current use of port 25 is by computers that have been
   infected by malware and are sending spam without the knowledge of
   the users of those computers. Port 587 improves security through
   the use of required authentication and recommended TLS/SSL
   encryption. 

What I do not understand is what prevents the malware (assuming it can
signicantly control the machine) from using the same authentication to
send spam as before. Isn't this back to square 1?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140731143730.gj19...@copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Jerry Stuckle
On 7/31/2014 10:37 AM, Brian wrote:
 On Mon 28 Jul 2014 at 22:12:09 +0100, Joe wrote:
 
 On Mon, 28 Jul 2014 18:16:23 +0100
 Brian a...@cityscape.co.uk wrote:

 Port 25 then becomes used only for incoming messages to be sent to
 domains the server is responsible for? If so, that doesn't appear any
 different from the present situation. For relaying a login is
 perfectly understanable, but it can be done on port 25 too. What
 makes port 587 necessary?

 Simply to provide a standard port on which authentication is expected
 and used, leaving 25 for unauthenticated mail. An email sent to an
 arbitrary address will be unauthenticated, because none of us have
 authentication credentials for all the world's mail servers.
 Unauthenticated mail will be delivered only *to* the domains the
 receiving server is authoritative for, or relayed *to* anywhere, but
 only *from* domains which are explicitly configured in the server. I
 think the very basic Debian setup of exim4 allows the entry of such
 permitted relaying domains, and certainly the full configuration file(s)
 does so.
 
 Thanks. Due to your post and speed reading an RFC or two I think I now
 have a better understanding of what the IETF's intentions are. They do
 not include encouraging the blocking of outbound port 25. However, in an
 earlier mail
 
   https://lists.debian.org/debian-user/2014/07/msg01614.html
 
 I said
 
You have to authenticate yourself when you join your ISP's network.
No further authentication is needed to use their SMTP server; you
are a trusted user so TLS is therefore not required.
 
 This is incorrect. I was working off my experience of my ISP's network
 and my own. It may not be needed but an ISP can require authentication
 to send mail in spite of knowing a machine is legitimately on its
 network. 
 
 The reason for doing it given is generally along the lines of:
 
Much of the current use of port 25 is by computers that have been
infected by malware and are sending spam without the knowledge of
the users of those computers. Port 587 improves security through
the use of required authentication and recommended TLS/SSL
encryption. 
 
 What I do not understand is what prevents the malware (assuming it can
 signicantly control the machine) from using the same authentication to
 send spam as before. Isn't this back to square 1?
 
 

Nothing, if the malware can get the userid and password.  However, to do
so you have to store the information on your machine.  Additionally, the
malware has to know which MUA you're using (to figure out where the
userid and password are stored), and if your MUA has encrypted the
information, how to decrypt it.

Not impossible, by any means.  But much harder than just sending over
port 25, which requires none of the above.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53da5837.7050...@attglobal.net



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Joe
On Thu, 31 Jul 2014 15:37:31 +0100
Brian a...@cityscape.co.uk wrote:


 
 What I do not understand is what prevents the malware (assuming it can
 signicantly control the machine) from using the same authentication to
 send spam as before. Isn't this back to square 1?
 
 

I would assume it can, if it operates your email client under your
credentials. But this may well leave traces, when you find sent mail
that you definitely know you didn't send, or alien names added to your
address book, that the malware has failed to erase properly. It is
probably difficult for malware to pick security stuff out of the
Registry without making a valid logon. Microsoft may be rubbish at
general security, but these days it has to meet fairly strict standards
for email confidentiality if it wants corporate US clients,
particularly medical and legal ones. The preference is for malware to
use a primitive SMTP engine which is entirely separate from the
compromised system's email.

Also, probably more important, your mail hosting company may well spot
the spam going through their own mail server, whereas they are probably
less likely to spot outgoing spam just passing through their routers,
along with hundreds of torrent feeds... I'm sure the ISPs will be
required to monitor and analyse all traffic in and out of their
customers' systems one day, but I doubt that they're looking forward to
it.

-- 
Joe


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140731173721.501c1...@jretrading.com



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Brian
On Thu 31 Jul 2014 at 10:52:39 -0400, Jerry Stuckle wrote:

 On 7/31/2014 10:37 AM, Brian wrote:
  
  The reason for doing it given is generally along the lines of:
  
 Much of the current use of port 25 is by computers that have been
 infected by malware and are sending spam without the knowledge of
 the users of those computers. Port 587 improves security through
 the use of required authentication and recommended TLS/SSL
 encryption. 
  
  What I do not understand is what prevents the malware (assuming it can
  signicantly control the machine) from using the same authentication to
  send spam as before. Isn't this back to square 1?
 
 Nothing, if the malware can get the userid and password.  However, to do
 so you have to store the information on your machine.  Additionally, the
 malware has to know which MUA you're using (to figure out where the
 userid and password are stored), and if your MUA has encrypted the
 information, how to decrypt it.

One would expect the ISP's strategy to factor in the sophistication of
malware. which is presumably sophisticated enough to be able to use port
25.

 Not impossible, by any means.  But much harder than just sending over
 port 25, which requires none of the above.

The ISP's concern is (or should be) the customers who allow sending of
spam without the knowledge of the users of those computers. These
same incompetent customers are now all going to start encrypting the
usernames and passwords used for sending email?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/31072014173505.d888f60ee...@desktop.copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Brian
On Thu 31 Jul 2014 at 17:37:21 +0100, Joe wrote:

 On Thu, 31 Jul 2014 15:37:31 +0100
 Brian a...@cityscape.co.uk wrote:
 
  What I do not understand is what prevents the malware (assuming it can
  signicantly control the machine) from using the same authentication to
  send spam as before. Isn't this back to square 1?
 
 I would assume it can, if it operates your email client under your
 credentials. But this may well leave traces, when you find sent mail
 that you definitely know you didn't send, or alien names added to your
 address book, that the malware has failed to erase properly. It is

If a user notices these traces, all well and good; he can do something
about it. If he doesn't notice his machine will continue to churn out
spam, irrespective of what port is being used.

 probably difficult for malware to pick security stuff out of the
 Registry without making a valid logon. Microsoft may be rubbish at
 general security, but these days it has to meet fairly strict standards
 for email confidentiality if it wants corporate US clients,
 particularly medical and legal ones. The preference is for malware to
 use a primitive SMTP engine which is entirely separate from the
 compromised system's email.

I didn't know that. I don't envisage such an engine on my system but if
it could read /etc/exim4/passwd.client (a plaintext file) it's in
business.
 
 Also, probably more important, your mail hosting company may well spot
 the spam going through their own mail server, whereas they are probably
 less likely to spot outgoing spam just passing through their routers,
 along with hundreds of torrent feeds... I'm sure the ISPs will be
 required to monitor and analyse all traffic in and out of their
 customers' systems one day, but I doubt that they're looking forward to
 it.

I can well understand any decent ISP monitoring port 25 traffic through
its network. Those who block port 25 may eventually come up with before
and after statistics but somehow I doubt it; commercial confidentiality
and all that.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140731174719.gk19...@copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Jerry Stuckle
On 7/31/2014 12:47 PM, Brian wrote:
 On Thu 31 Jul 2014 at 10:52:39 -0400, Jerry Stuckle wrote:
 
 On 7/31/2014 10:37 AM, Brian wrote:

 The reason for doing it given is generally along the lines of:

Much of the current use of port 25 is by computers that have been
infected by malware and are sending spam without the knowledge of
the users of those computers. Port 587 improves security through
the use of required authentication and recommended TLS/SSL
encryption. 

 What I do not understand is what prevents the malware (assuming it can
 signicantly control the machine) from using the same authentication to
 send spam as before. Isn't this back to square 1?

 Nothing, if the malware can get the userid and password.  However, to do
 so you have to store the information on your machine.  Additionally, the
 malware has to know which MUA you're using (to figure out where the
 userid and password are stored), and if your MUA has encrypted the
 information, how to decrypt it.
 
 One would expect the ISP's strategy to factor in the sophistication of
 malware. which is presumably sophisticated enough to be able to use port
 25.


Which is why many ISPs now block Port 25 from residential users.

 Not impossible, by any means.  But much harder than just sending over
 port 25, which requires none of the above.
 
 The ISP's concern is (or should be) the customers who allow sending of
 spam without the knowledge of the users of those computers. These
 same incompetent customers are now all going to start encrypting the
 usernames and passwords used for sending email?
 
 

Most MUAs can already encrypt the password (and sometimes the userid) if
it is saved on the disk.  Thunderbird does this, for instance.  I assume
Outlook does also, although I haven't checked it.

I should add the malware would also have to know the MTA the
userid/password are for.  Again, not impossible by any means - but just
one more thing the malware has to discover.

For instance, I use my own mail server for most of my email; this
account is used for non-business related stuff.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53da8e3f.1030...@attglobal.net



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Joe
On Thu, 31 Jul 2014 18:47:19 +0100
Brian a...@cityscape.co.uk wrote:

 On Thu 31 Jul 2014 at 17:37:21 +0100, Joe wrote:
 
The preference is for
  malware to use a primitive SMTP engine which is entirely separate
  from the compromised system's email.
 
 I didn't know that. I don't envisage such an engine on my system but
 if it could read /etc/exim4/passwd.client (a plaintext file) it's in
 business.

You pointed out how easy it is to talk to an SMTP server with telnet, I
have a couple of times actually sent someone a short email that way. It
would be pretty easy to write a script that would automate the process
for a few hundred recipients at a time. And it won't know what
/etc/exim4 is, it will be Windows malware, and while Windows does
indeed have an /etc (actually \etc) it only keeps hosts, lmhosts,
protocols and services files there.
  
  Also, probably more important, your mail hosting company may well
  spot the spam going through their own mail server, whereas they are
  probably less likely to spot outgoing spam just passing through
  their routers, along with hundreds of torrent feeds... I'm sure the
  ISPs will be required to monitor and analyse all traffic in and out
  of their customers' systems one day, but I doubt that they're
  looking forward to it.
 
 I can well understand any decent ISP monitoring port 25 traffic
 through its network. Those who block port 25 may eventually come up
 with before and after statistics but somehow I doubt it; commercial
 confidentiality and all that.
 
 
I think the ISPs have enough to do in recording email in and out of
their own servers, for the government's benefit. Relatively few
companies and almost no individuals send mail direct. But we all know
that the only direction for the Internet to go is downhill...

-- 
Joe


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140731194458.1c078...@jretrading.com



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Brian
On Thu 31 Jul 2014 at 14:43:11 -0400, Jerry Stuckle wrote:

 On 7/31/2014 12:47 PM, Brian wrote:
  
  One would expect the ISP's strategy to factor in the sophistication of
  malware. which is presumably sophisticated enough to be able to use port
  25.
 
 Which is why many ISPs now block Port 25 from residential users.

The point of my remark was that malware can operate on port 25 so there
is nothing to prevent it operating on port 587. I was actually agreeing
with you when you said Nothing. 

  Not impossible, by any means.  But much harder than just sending over
  port 25, which requires none of the above.
  
  The ISP's concern is (or should be) the customers who allow sending of
  spam without the knowledge of the users of those computers. These
  same incompetent customers are now all going to start encrypting the
  usernames and passwords used for sending email?
 
 Most MUAs can already encrypt the password (and sometimes the userid) if
 it is saved on the disk.  Thunderbird does this, for instance.  I assume
 Outlook does also, although I haven't checked it.
 
 I should add the malware would also have to know the MTA the
 userid/password are for.  Again, not impossible by any means - but just
 one more thing the malware has to discover.

I think that once you get to discussing the capabilities of the malware
it acknowledges that port 587 presents no more problems to the malware
than port 25; it simply depends on how good the malware is.  Which, as I
originally queried, brings into question the efficacy of ISPs mandating
its use.

I'll not ask for ISP facts and figures to show how good port 587 is for
them.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140731190943.gl19...@copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Jerry Stuckle
On 7/31/2014 3:09 PM, Brian wrote:
 On Thu 31 Jul 2014 at 14:43:11 -0400, Jerry Stuckle wrote:
 
 On 7/31/2014 12:47 PM, Brian wrote:

 One would expect the ISP's strategy to factor in the sophistication of
 malware. which is presumably sophisticated enough to be able to use port
 25.

 Which is why many ISPs now block Port 25 from residential users.
 
 The point of my remark was that malware can operate on port 25 so there
 is nothing to prevent it operating on port 587. I was actually agreeing
 with you when you said Nothing. 


Yes, but Port 587 requires (or at least should require) a login; Port 25
never does for email destined for the domains being served by that MTA.

 Not impossible, by any means.  But much harder than just sending over
 port 25, which requires none of the above.

 The ISP's concern is (or should be) the customers who allow sending of
 spam without the knowledge of the users of those computers. These
 same incompetent customers are now all going to start encrypting the
 usernames and passwords used for sending email?

 Most MUAs can already encrypt the password (and sometimes the userid) if
 it is saved on the disk.  Thunderbird does this, for instance.  I assume
 Outlook does also, although I haven't checked it.

 I should add the malware would also have to know the MTA the
 userid/password are for.  Again, not impossible by any means - but just
 one more thing the malware has to discover.
 
 I think that once you get to discussing the capabilities of the malware
 it acknowledges that port 587 presents no more problems to the malware
 than port 25; it simply depends on how good the malware is.  Which, as I
 originally queried, brings into question the efficacy of ISPs mandating
 its use.
 
 I'll not ask for ISP facts and figures to show how good port 587 is for
 them.
 
 

Yes, it does - again, Port 587 requires a login - which adds a huge
layer of complexity to the malware.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53da9a56.8080...@attglobal.net



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Brian
On Thu 31 Jul 2014 at 15:34:46 -0400, Jerry Stuckle wrote:

 On 7/31/2014 3:09 PM, Brian wrote:
  
  The point of my remark was that malware can operate on port 25 so there
  is nothing to prevent it operating on port 587. I was actually agreeing
  with you when you said Nothing. 
 
 Yes, but Port 587 requires (or at least should require) a login; Port 25
 never does for email destined for the domains being served by that MTA.

I feel this is a repetition of a technical point we both agree on.

  I think that once you get to discussing the capabilities of the malware
  it acknowledges that port 587 presents no more problems to the malware
  than port 25; it simply depends on how good the malware is.  Which, as I
  originally queried, brings into question the efficacy of ISPs mandating
  its use.
  
  I'll not ask for ISP facts and figures to show how good port 587 is for
  them.
 
 Yes, it does - again, Port 587 requires a login - which adds a huge
 layer of complexity to the malware.

I'm glad we can end this by both of us agreeing that it simply depends
on how good the malware is.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140731215117.gm19...@copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-31 Thread Jerry Stuckle
On 7/31/2014 5:51 PM, Brian wrote:
 On Thu 31 Jul 2014 at 15:34:46 -0400, Jerry Stuckle wrote:
 
 On 7/31/2014 3:09 PM, Brian wrote:

 The point of my remark was that malware can operate on port 25 so there
 is nothing to prevent it operating on port 587. I was actually agreeing
 with you when you said Nothing. 

 Yes, but Port 587 requires (or at least should require) a login; Port 25
 never does for email destined for the domains being served by that MTA.
 
 I feel this is a repetition of a technical point we both agree on.


But the difference in requiring a login on Port 587 is a very important
difference.  One you seem to be ignoring.

 I think that once you get to discussing the capabilities of the malware
 it acknowledges that port 587 presents no more problems to the malware
 than port 25; it simply depends on how good the malware is.  Which, as I
 originally queried, brings into question the efficacy of ISPs mandating
 its use.

 I'll not ask for ISP facts and figures to show how good port 587 is for
 them.

 Yes, it does - again, Port 587 requires a login - which adds a huge
 layer of complexity to the malware.
 
 I'm glad we can end this by both of us agreeing that it simply depends
 on how good the malware is.
 
 

Yes, but the difference here is - sending to port 25 is pretty easy.
Sending via port 587 is MUCH harder.  Hackers take the easy route; as
long as Port 25 is available, they will send through it.  If Port 25
ever should become unavailable to a large percentage of users, they may
have to take the hard route.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53dacbc1.2070...@attglobal.net



Re: Finding a replacement for my ISP's smtp server

2014-07-29 Thread Darac Marjal
On Mon, Jul 28, 2014 at 07:21:36PM -0400, Jerry Stuckle wrote:
 On 7/28/2014 5:27 PM, Brian wrote:
  On Mon 28 Jul 2014 at 16:08:44 -0400, Jerry Stuckle wrote:
  
  On 7/28/2014 3:51 PM, Brian wrote:
  On Mon 28 Jul 2014 at 21:08:02 +0200, Slavko wrote:
 
  Dňa Mon, 28 Jul 2014 19:57:52 +0100 Brian a...@cityscape.co.uk
  napísal:
 
  Do you really mean criminal? Which countries are these which
  criminalise looking at something which is in a public place? Walking
  round with my eyes closed and my brain closed down isn't an attracive
  prospect.
 
  You never really answered my questiom. If you place something in a
  public place, a mailserver, for example, why should it be a criminal
  offence to look at it. If you did not want it to be seen you have the
  solution at hand.
   
 
  If your car is in a public parking lot, does that mean I can get in and
  drive it off?
  
  I never said that you could. I guess that would be unacceptable in every
  country except in the most extenuating of circumstances.
 
 
 So is port scanning, in many countries.

This is nmap's own position on the subject
http://nmap.org/book/legal-issues.html

Many on the list (USians) might also find this relevant
http://www.securityfocus.com/news/126


signature.asc
Description: Digital signature


Re: Finding a replacement for my ISP's smtp server

2014-07-29 Thread Andrei POPESCU
On Lu, 28 iul 14, 17:05:56, Jerry Stuckle wrote:
 
 But then if you have residential service, there really is no need to
 have your own MTA (other than you want it).

Running your own MTA can be beneficial even if it is not accessible from 
the internet:

- queuing: some mail clients block while sending and you also don't have 
  to worry if the smarthost is not available for the moment
- DRY: don't repeat yourself by making the same configuration in every 
  mail client you use
- local mail works and is not relayed through your smarthost

Depending on your needs the first two points can be solved with one of 
the lightweight MTAs, but I only know of dma that can do all three. 

Besides, both postfix and exim are very well tested and documented and 
can be configured to do more advanced stuff (e.g. address rewriting).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature


Re: Finding a replacement for my ISP's smtp server

2014-07-29 Thread Lisi Reisz
On Monday 28 July 2014 21:38:37 Brian wrote:
   You never really answered my questiom. If you place something in a
   public place, a mailserver, for example, why should it be a criminal
   offence to look at it. If you did not want it to be seen you have the
   solution at hand.
 
  Yes, i provided answer to you. I try it again: If is something in
  public place, it doesn't mean, that anybody can do anything with it.

 You are stating the obvious.

I think that Slavko may not know what criminal means.  It is at the heart of 
this, and he does seem to think that he has replied.  I agree, he hasn't.  
But we must make allowances for the fact that many on this list are not 
native speakers of English.

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201407291149.23689.lisi.re...@gmail.com



Re: Finding a replacement for my ISP's smtp server

2014-07-29 Thread Slavko
Ahoj,

Dňa Tue, 29 Jul 2014 12:22:38 +0300 Andrei POPESCU
andreimpope...@gmail.com napísal:

 On Lu, 28 iul 14, 17:05:56, Jerry Stuckle wrote:
  
  But then if you have residential service, there really is no need to
  have your own MTA (other than you want it).
 
 Running your own MTA can be beneficial even if it is not accessible
 from the internet:
 
 - queuing: some mail clients block while sending and you also don't
 have to worry if the smarthost is not available for the moment
 - DRY: don't repeat yourself by making the same configuration in
 every mail client you use
 - local mail works and is not relayed through your smarthost
 
 Depending on your needs the first two points can be solved with one
 of the lightweight MTAs, but I only know of dma that can do all
 three. 

I did many tests with these light MTA, mostly due using on Raspbian and
OpenWrt, and my resume is, that the exim4 (light, i never tried heavy
daemon) is simplest way and enough light to run on RaspberyPi B (i have
no heavy traffic, of course), then it is simplest solution for any
Debian machine which has cca 4 MB disk place and 512 MB RAM.

These light MTAs has some problems - one is only MUA, with remote
delivering, another can read headers only from file, etc. Then there are
small problems with some other applications (e.g. cron,
procmail, custom scripts, etc), where can be needed to do additional
setup for these MTA. All these problems are solvable, but often
particular MTA dependent.

regards

-- 
Slavko
http://slavino.sk


signature.asc
Description: PGP signature


Re: Finding a replacement for my ISP's smtp server

2014-07-29 Thread Brian
On Mon 28 Jul 2014 at 19:16:08 -0400, Jerry Stuckle wrote:

 On 7/28/2014 6:36 PM, Brian wrote:
  
  You are guaranteeing the remote MTA will have 100% uptime and sends
  mails and non-delivery messages in a timely fashion? And yes, knowing
  the mail was accepted by the destination MTA is important; when someone
  says they haven't received a mail from me I can demonstrate otherwise.
   
 
 If they are a good ISP, then they will have higher uptime than you do!

We are about equal, I expect. I don't use them so don't know.

 And even if they are down - your local system will tell you and you can
 try again later.

If I send directly there is one less point of failure.

 But you also seem to think that just because the remote MTA accepted the
 email the user got it.  That is not necessarily so - for a lot of
 reasons.  For instance, many MTA's will silently drop emails to a bad
 address rather than rejecting them.  It makes it much harder for a
 spammer to discover whether an email is valid or not.

No, I do not think that. I think that if the remote MTA accepted the
mail then the remote MTA accepted that mail and can prove it.

The recipient not getting the mail is an issue for her not me. She can
claim the dog chewed it up or that a spam trap eat it. What she cannot
claim is that it wasn't delivered to her designated place. If she did
not get the mail (technically it has been received) she will need to
investigate her own network and her ISP's.

  Compromised? No need to worry; everything is in capable hands. Unlike
  the large ISP networks which harbour spam bots.
 
 Then prove it to your ISP.  And please name the large ISP networks
 which harbor spam bots.

No need to prove it; my ISP regularily inspects my network. 10/10 every
time and a 15 year unblemished record.

You won't find my small network here

  http://www.spamhaus.org/statistics/networks/


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140729134741.gf19...@copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-29 Thread Jerry Stuckle
On 7/29/2014 9:47 AM, Brian wrote:
 On Mon 28 Jul 2014 at 19:16:08 -0400, Jerry Stuckle wrote:
 
 On 7/28/2014 6:36 PM, Brian wrote:

 You are guaranteeing the remote MTA will have 100% uptime and sends
 mails and non-delivery messages in a timely fashion? And yes, knowing
 the mail was accepted by the destination MTA is important; when someone
 says they haven't received a mail from me I can demonstrate otherwise.
  

 If they are a good ISP, then they will have higher uptime than you do!
 
 We are about equal, I expect. I don't use them so don't know.
 
 And even if they are down - your local system will tell you and you can
 try again later.
 
 If I send directly there is one less point of failure.
 
 But you also seem to think that just because the remote MTA accepted the
 email the user got it.  That is not necessarily so - for a lot of
 reasons.  For instance, many MTA's will silently drop emails to a bad
 address rather than rejecting them.  It makes it much harder for a
 spammer to discover whether an email is valid or not.
 
 No, I do not think that. I think that if the remote MTA accepted the
 mail then the remote MTA accepted that mail and can prove it.


This is where you are incorrect.  All you know is the MTA accepted the
email.  You have no idea what the MTA did with the email after that.

 The recipient not getting the mail is an issue for her not me. She can
 claim the dog chewed it up or that a spam trap eat it. What she cannot
 claim is that it wasn't delivered to her designated place. If she did
 not get the mail (technically it has been received) she will need to
 investigate her own network and her ISP's.
 

Yes, she can.  All YOU can claim is it was delivered to her MTA.  You
can NOT guarantee it was delivered to her.  There are many reasons
(valid and invalid) that can cause this.

And in any case, the exact same argument occurs when you use your ISP's
MTA.  The only difference is you're more likely to get the email
delivered to the MTA.

 Compromised? No need to worry; everything is in capable hands. Unlike
 the large ISP networks which harbour spam bots.

 Then prove it to your ISP.  And please name the large ISP networks
 which harbor spam bots.
 
 No need to prove it; my ISP regularily inspects my network. 10/10 every
 time and a 15 year unblemished record.
 
 You won't find my small network here
 
   http://www.spamhaus.org/statistics/networks/
 
 

Not now.  But that does not mean your record will REMAIN unblemished.

Jerry



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d7b03b.9060...@attglobal.net



Re: Finding a replacement for my ISP's smtp server

2014-07-29 Thread Jerry Stuckle
On 7/29/2014 5:22 AM, Andrei POPESCU wrote:
 On Lu, 28 iul 14, 17:05:56, Jerry Stuckle wrote:

 But then if you have residential service, there really is no need to
 have your own MTA (other than you want it).
 
 Running your own MTA can be beneficial even if it is not accessible from 
 the internet:
 
 - queuing: some mail clients block while sending and you also don't have 
   to worry if the smarthost is not available for the moment

That's a mail client problem.  The correct solution if you have this
problem would be to get another client.

 - DRY: don't repeat yourself by making the same configuration in every 
   mail client you use

You still need to configure every mail client you use.

 - local mail works and is not relayed through your smarthost


True, if you have a need for a significant amount of local mail.  But
residential users don't send a lot of mail internally.  There are better
ways of sharing things - like shared network storage.

The only thing my wife and I send to each other via email is forwarding
emails.  Everything else is shared through network storage (which also
serves as a backup device).

 Depending on your needs the first two points can be solved with one of 
 the lightweight MTAs, but I only know of dma that can do all three. 


Sure, if you need them.

 Besides, both postfix and exim are very well tested and documented and 
 can be configured to do more advanced stuff (e.g. address rewriting).
 
 Kind regards,
 Andrei
 

Yes, I know Exim can be configured to do a lot.  But I have yet to see
where it is advantageous to run a MTA on a residential connection, and
know of a lot of reasons why it's bad.

I do run Exim on several servers (actually I have a friend who has
helped set them up - I am NOT a Linux Admin).  But every one of these
servers is in a data center with static IP addresses.

And the biggest advantage is I can access them from my laptop, ipad,
smartphone or whatever - no matter where I am, with no changes to the
email configuration.  You can't do that when the MTA is in your home.

And my outgoing mail doesn't get blocked because it's coming from a
dynamic IP.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d7af3c.80...@attglobal.net



Re: Finding a replacement for my ISP's smtp server

2014-07-29 Thread Brian
On Tue 29 Jul 2014 at 10:31:23 -0400, Jerry Stuckle wrote:

 On 7/29/2014 9:47 AM, Brian wrote:
  
  No, I do not think that. I think that if the remote MTA accepted the
  mail then the remote MTA accepted that mail and can prove it.
 
 
 This is where you are incorrect.  All you know is the MTA accepted the
 email.  You have no idea what the MTA did with the email after that.

It's entirely correct. Of course I've no idea what the accepting MTA
does with the mail. I do not control it.

Try this for a reasonable analogy: I post a letter through the door of
your house. I know it was delivered and accepted - otherwise it wouldn't
have gone through the letterbox. My responsibility is at an end.

What happens on the other side of the door and whether the recipient
gets the letter is between you and your dog.

  The recipient not getting the mail is an issue for her not me. She can
  claim the dog chewed it up or that a spam trap eat it. What she cannot
  claim is that it wasn't delivered to her designated place. If she did
  not get the mail (technically it has been received) she will need to
  investigate her own network and her ISP's.
 
 Yes, she can.  All YOU can claim is it was delivered to her MTA.  You
 can NOT guarantee it was delivered to her.  There are many reasons
 (valid and invalid) that can cause this.

Please see above. The reasons don't concern me, whatever they are.

 And in any case, the exact same argument occurs when you use your ISP's
 MTA.  The only difference is you're more likely to get the email
 delivered to the MTA.

Delivering mail is identical for me and my ISP. There is no magic
involved.

  No need to prove it; my ISP regularily inspects my network. 10/10 every
  time and a 15 year unblemished record.
  
  You won't find my small network here
  
http://www.spamhaus.org/statistics/networks/
 
 Not now.  But that does not mean your record will REMAIN unblemished.

The killer blow?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/29072014154821.d5bd8c20c...@desktop.copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-29 Thread Jerry Stuckle
On 7/29/2014 11:06 AM, Brian wrote:
 On Tue 29 Jul 2014 at 10:31:23 -0400, Jerry Stuckle wrote:
 
 On 7/29/2014 9:47 AM, Brian wrote:

 No, I do not think that. I think that if the remote MTA accepted the
 mail then the remote MTA accepted that mail and can prove it.


 This is where you are incorrect.  All you know is the MTA accepted the
 email.  You have no idea what the MTA did with the email after that.
 
 It's entirely correct. Of course I've no idea what the accepting MTA
 does with the mail. I do not control it.
 
 Try this for a reasonable analogy: I post a letter through the door of
 your house. I know it was delivered and accepted - otherwise it wouldn't
 have gone through the letterbox. My responsibility is at an end.
 
 What happens on the other side of the door and whether the recipient
 gets the letter is between you and your dog.


No, it's more like when you place the letter in the post office box.  It
would get to their door when their MUA receives it from the MTA.
Between the two, any number of things can happen.

 The recipient not getting the mail is an issue for her not me. She can
 claim the dog chewed it up or that a spam trap eat it. What she cannot
 claim is that it wasn't delivered to her designated place. If she did
 not get the mail (technically it has been received) she will need to
 investigate her own network and her ISP's.

 Yes, she can.  All YOU can claim is it was delivered to her MTA.  You
 can NOT guarantee it was delivered to her.  There are many reasons
 (valid and invalid) that can cause this.
 
 Please see above. The reasons don't concern me, whatever they are.
 

But you stated earlier you wanted to know that she got the message.  I'm
just pointing out you can't guarantee that, even if you run your own MTA.

 And in any case, the exact same argument occurs when you use your ISP's
 MTA.  The only difference is you're more likely to get the email
 delivered to the MTA.
 
 Delivering mail is identical for me and my ISP. There is no magic
 involved.


Then there is no reason not to use your ISP's MTA.

 No need to prove it; my ISP regularily inspects my network. 10/10 every
 time and a 15 year unblemished record.

 You won't find my small network here

   http://www.spamhaus.org/statistics/networks/

 Not now.  But that does not mean your record will REMAIN unblemished.
 
 The killer blow?
 
 

It can (and does) happen.  Every day.

But as I said - it's not ME you have to convince.  It's your ISP.  And
if your ISPs are anything like the ones we have here, they couldn't care
less.  They block outgoing port 25, no matter how many safeguards you
have on your system.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d7c55b.9060...@attglobal.net



Re: Finding a replacement for my ISP's smtp server

2014-07-29 Thread Joe
On Tue, 29 Jul 2014 10:27:08 -0400
Jerry Stuckle jstuc...@attglobal.net wrote:


 
 Yes, I know Exim can be configured to do a lot.  But I have yet to see
 where it is advantageous to run a MTA on a residential connection, and
 know of a lot of reasons why it's bad.
 
 I do run Exim on several servers (actually I have a friend who has
 helped set them up - I am NOT a Linux Admin).  But every one of these
 servers is in a data center with static IP addresses.
 
 And the biggest advantage is I can access them from my laptop, ipad,
 smartphone or whatever - no matter where I am, with no changes to the
 email configuration.  You can't do that when the MTA is in your home.
 
 And my outgoing mail doesn't get blocked because it's coming from a
 dynamic IP.

Nor does mine, because it isn't. I understand that it can be difficult
and expensive to get a static IP address in some parts of the USA, but
it isn't over here unless you demand to pay rock-bottom mass-market
prices. My own ISP will even allocate a small block of IPv4 addresses
*at* *no* *extra* *charge* if I can show that I have a use for them. I
don't, so one is enough. I know another ISP who will do that, if I
ever need to drop my current one, which is now owned by Vodafone. It's a
sort of semi-business account, without full business account features
but with a fixed address and no port blocking.

I see two main reasons for running an MTA, as I have for fifteen years
or so:

Brian's reason, in that I can see what happens to email that
disappears. I do a bit of professional IT work where that is useful,
but also my wife occasionally tells me that an email to/from one of her
friends hasn't got through, so what's wrong with our system then, and I
can look up the logs and confirm the problem isn't here. I have in the
past tried to get information from smarthost admins about email logs,
and on the whole have failed miserably. Once it's arrived at the
smarthost, there's no realistic way to tell what happened after that. If
you don't know which company to blame, with proof, you can't complain.
But if a client tells me that email to someone hasn't been working for a
day or so, I can connect home to my server and send an email from
there, reading the exim4 log in real time, and then do the same from a
VM on my laptop, from my client's network, to see if there's any
difference. That's solved a few problems.

Secondly, I (almost) have control of spam. I do virtually no content
checking, having wrestled with spamassassin for a while and decided
there was no way I could win. But I decide whether to risk false
positives that way, or to do basic tests on incoming mail and simply
refuse the transaction on failure. Nobody else loses my email for me.
And it works: spam has now escalated to 6-8 a day, but that's only in
the last couple of months. For years before that, it was 1-2 a day,
with 1500-3000 rejections. My record for rejections was over 12,000 in
one day. That email address at the top is valid and has been in daily
use, especially on Usenet, for sixteen years and my IP address has been
fixed for the same period. And I get seven spams a day in my inbox...

A lesser third reason is that because I do it, I know how to drive a
mail server. I've only used exim4 in that time, but similar principles
will apply to postfix or even the dreaded sendmail. I've looked after a
few versions of Exchange for other people, but that doesn't really
count.

I can see that in a few years' time I won't be allowed to do this, if
only because it takes more effort for my government to spy on me. But I
shall carry on for as long as I can, because it Works For Me (tm).

-- 
Joe


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140729211526.20cd7...@jretrading.com



Re: Finding a replacement for my ISP's smtp server

2014-07-29 Thread Chris Bannister
On Mon, Jul 28, 2014 at 04:08:44PM -0400, Jerry Stuckle wrote:
 On 7/28/2014 3:51 PM, Brian wrote:
  You never really answered my questiom. If you place something in a
  public place, a mailserver, for example, why should it be a criminal
  offence to look at it. If you did not want it to be seen you have the
  solution at hand.
   
 
 If your car is in a public parking lot, does that mean I can get in and
 drive it off?

As that sentence stands, sure you can, provided you can drive, you can
get the car going, etc. etc. The crucial question is *may* I. I may have
even given you permission to. :)

Everyone, provided they have the technical ability etc. *can* do a port
scan using nmap, check server response using telnet etc. 

I have heard/read somewhere that using nmap is considered to be
malicious but as far as being criminal, as meaning against the law, I
don't think that is true. 

Whether you should or not is the crucial question, it could be your job,
penetration tester for one example and therefore if you don't do it do
don't get paid. :)


-- 
If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing. --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140730032803.GB13354@tal



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Slavko
Ahoj,

Dňa Sun, 27 Jul 2014 13:02:18 +0100 Brian a...@cityscape.co.uk
napísal:

 On Sun 27 Jul 2014 at 10:03:29 +0100, Jonathan Dowland wrote:
 
  My current best guess is you are attempting to connect to gmail's
  servers on port 25 and your ISP has blocked connections to port 25
  for any server except their own, in which case port 587 should work
  instead.
 
 He could check with nc.
 
   brian@desktop:~$ nc smtp.gmail.com 25
   220 mx.google.com ESMTP 19sm41008233wjz.3 - gsmtp
 

AFAIK, the port 25 have to used only for (inter-) servers connections,
the clients have connect via 587, the port 25 for client connections is
for backward compatibility only.

regards

-- 
Slavko
http://slavino.sk


signature.asc
Description: PGP signature


Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Curt
On 2014-07-28, Joel Rees joel.r...@gmail.com wrote:

 (Piques my curiosity.)

 They have made
 it clear in that they do not require or use TLS.

 (Wondering what TLS has to do with strangeness in this case.)


Maybe what mutt has to do with vlc. 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnltckhl.2l1.cu...@einstein.electron.org



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Brian
On Mon 28 Jul 2014 at 14:02:29 +0200, Slavko wrote:

 Dňa Sun, 27 Jul 2014 13:02:18 +0100 Brian a...@cityscape.co.uk
 napísal:
 
  He could check with nc.
  
brian@desktop:~$ nc smtp.gmail.com 25
220 mx.google.com ESMTP 19sm41008233wjz.3 - gsmtp
  
 
 AFAIK, the port 25 have to used only for (inter-) servers connections,
 the clients have connect via 587, the port 25 for client connections is
 for backward compatibility only.

How does the server tell the difference between talking to another
server (which is acting as client) and what you call a client?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/28072014145359.36b1c2183...@desktop.copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Jerry Stuckle
On 7/28/2014 9:56 AM, Brian wrote:
 On Mon 28 Jul 2014 at 14:02:29 +0200, Slavko wrote:
 
 Dňa Sun, 27 Jul 2014 13:02:18 +0100 Brian a...@cityscape.co.uk
 napísal:

 He could check with nc.

   brian@desktop:~$ nc smtp.gmail.com 25
   220 mx.google.com ESMTP 19sm41008233wjz.3 - gsmtp


 AFAIK, the port 25 have to used only for (inter-) servers connections,
 the clients have connect via 587, the port 25 for client connections is
 for backward compatibility only.
 
 How does the server tell the difference between talking to another
 server (which is acting as client) and what you call a client?
 
 

It doesn't, but operation is quite different.  MTA's typically require
no login on port 25, but only allow messages to be sent to domains it
serves (otherwise it quickly becomes a spam server).  Port 587 requires
a login, but allows messages to be relayed to any domain.

Now, for historic reasons, some MTA's still allow login on port 25
(either directly or some indirect method like accessing a POP or IMAP
account before sending).  But these are becoming fewer and fewer.

BTW, many ISP's have blocked outgoing port 25 connections (especially on
residential accounts) because there are a lot of trojans out there which
will install a minimal MTA on a user's machine, unbeknownst to the user.
 This allows spammers to use the compromised machine to be a spam
source, hiding the real source of the spam.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d65f5b.1070...@attglobal.net



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Paul Condon
On Mon, Jul 28, 2014 at 02:56:40PM +0100, Brian wrote:
 On Mon 28 Jul 2014 at 14:02:29 +0200, Slavko wrote:
 
  Dňa Sun, 27 Jul 2014 13:02:18 +0100 Brian a...@cityscape.co.uk
  napísal:
  
   He could check with nc.
   
 brian@desktop:~$ nc smtp.gmail.com 25
 220 mx.google.com ESMTP 19sm41008233wjz.3 - gsmtp
   
  
  AFAIK, the port 25 have to used only for (inter-) servers connections,
  the clients have connect via 587, the port 25 for client connections is
  for backward compatibility only.
 
 How does the server tell the difference between talking to another
 server (which is acting as client) and what you call a client?

I have found a script on the web that makes Mutt into a work-alike
substitute for Thunderbird. I don't like it, but it is a start at
getting what I once had. The script has at least one undocumented
Mutt command and other curiosities which I want to resolve before
I feel comfortable with my new situation. I already know that gmail
uses (and publishes for others to use) several different port numbers.
I haven't yet determined whether the different numbers are because
they have changed there interface over time or they simply intend
to support all of them. But, for now, I am in the much happier condition
of tweeking a new toy, than the recent past where I was unable to
reply to email without going through so much pain that I couldn't
remember what I wanted to say by the time I could key in my message.
The script that I found uses 587, but a different sript that I 
found (and didn't work) uses 465. If this email gets to the
debian-user list, and gets properly connected to the thread that is
being quoted, the problem is Solved. I think I have even got gmail
to masquerade as my old email address. We shall see.
 
Thanks to all,
Best regards,

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140728151159.ga5...@gmail.com



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Paul Condon
On Mon, Jul 28, 2014 at 01:37:57PM +, Curt wrote:
 On 2014-07-28, Joel Rees joel.r...@gmail.com wrote:
 
  (Piques my curiosity.)
 
  They have made
  it clear in that they do not require or use TLS.
 
  (Wondering what TLS has to do with strangeness in this case.)

I have read that without TLS the email file, and my password are
sent over the internet in the clear, un-encrypted, and that is
'clearly' a BAD THING. 

I have seen in recent days enough error message blaming TLS to
convince me that there are many programmers who beleive it is.
Until recently, I was like most of the world unaware of the
whole issue.


 
 
 Maybe what mutt has to do with vlc. 

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140728153539.gb5...@gmail.com



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Slavko
Ahoj,

Dňa Mon, 28 Jul 2014 14:56:40 +0100 Brian a...@cityscape.co.uk
napísal:

 On Mon 28 Jul 2014 at 14:02:29 +0200, Slavko wrote:
 
  Dňa Sun, 27 Jul 2014 13:02:18 +0100 Brian a...@cityscape.co.uk
  napísal:
  
   He could check with nc.
   
 brian@desktop:~$ nc smtp.gmail.com 25
 220 mx.google.com ESMTP 19sm41008233wjz.3 - gsmtp
   
  
  AFAIK, the port 25 have to used only for (inter-) servers
  connections, the clients have connect via 587, the port 25 for
  client connections is for backward compatibility only.
 
 How does the server tell the difference between talking to another
 server (which is acting as client) and what you call a client?

I don't know how server can differ the client and another server, but
from abstract of RFC 6409 (which obsoletes the RFC 4409 which
obsoletes the RFC 2476):

   Message relay is unaffected, and continues to use SMTP over port 25.

   When conforming to this document, message submission uses the
   protocol specified here, normally over port 587.

And latter in the same RFC:

3.  Message Submission

3.1.  Submission Identification

   Port 587 is reserved for email message submission as specified in
   this document.  Messages received on this port are defined to be
   submissions.  The protocol used is ESMTP [SMTP-MTA], with additional
   restrictions or allowances as specified here.

   Although most email clients and servers can be configured to use port
   587 instead of 25, there are cases where this is not possible or
   convenient.  A site MAY choose to use port 25 for message submission
   by designating some hosts to be MSAs and others to be MTAs.

By this i assume, that i posted formerly.

As client i consider the MUA, but e.g. exim has a client mode too (i
don't know about other MTAs). I am sorry for simplification.

I want to point, that for end users is intended the 587 port, as
mentioned someone other too, and IMO it is not a good opinion to
suggest to try (check) the port 25, if the 587 is provided. Another
goal is, that there are some ISP, which don't blocks/redirects/proxies
the 587 port yet ;-)

regards

-- 
Slavko
http://slavino.sk


signature.asc
Description: PGP signature


Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Darac Marjal
On Mon, Jul 28, 2014 at 09:35:39AM -0600, Paul Condon wrote:
 On Mon, Jul 28, 2014 at 01:37:57PM +, Curt wrote:
  On 2014-07-28, Joel Rees joel.r...@gmail.com wrote:
  
   (Piques my curiosity.)
  
   They have made
   it clear in that they do not require or use TLS.
  
   (Wondering what TLS has to do with strangeness in this case.)
 
 I have read that without TLS the email file, and my password are
 sent over the internet in the clear, un-encrypted, and that is
 'clearly' a BAD THING. 

Yes-with-a-but.

TLS is the same technology used in HTTPS websites; it encrypts your
message in transit. The WWW and E-mail are quite different beasts,
though. E-mail is primarily a multi-hop, server-to-server communication.
If you connect to your ISP and send a message using TLS, then yes, your
message is protected from prying eyes. The message is now at the ISP's
server but it's not destined for them, so they connect to another server
(either the MX for the recipient or perhaps just another outgoing hop).
At this point, you have no control over how the message is handled.
Maybe it's sent with TLS, but probably not. Maybe it's sent within
seconds, but it could be held for hours or days.

If you really care about people seeing what you write, use an end-to-end
encryption such as GPG. If you care about people seeing who you write
to, then don't use e-mail.

 
 I have seen in recent days enough error message blaming TLS to
 convince me that there are many programmers who beleive it is.
 Until recently, I was like most of the world unaware of the
 whole issue.
 
 
  
  
  Maybe what mutt has to do with vlc. 
 
 -- 
 Paul E Condon   
 pecon...@mesanetworks.net
 
 
 -- 
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/20140728153539.gb5...@gmail.com
 


signature.asc
Description: Digital signature


Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Slavko
Ahoj,

Dňa Mon, 28 Jul 2014 09:35:39 -0600 Paul Condon pecond...@gmail.com
napísal:

 On Mon, Jul 28, 2014 at 01:37:57PM +, Curt wrote:
  On 2014-07-28, Joel Rees joel.r...@gmail.com wrote:
  
   (Piques my curiosity.)
  
   They have made
   it clear in that they do not require or use TLS.
  
   (Wondering what TLS has to do with strangeness in this case.)
 
 I have read that without TLS the email file, and my password are
 sent over the internet in the clear, un-encrypted, and that is
 'clearly' a BAD THING. 

Sure, you are right about unencrypted messages.

But ISP in my work (state-owned school, ISP provided by our government and
owned by the Deutsche Telekom) proxies the 25 port, which has a result
in removing the the STARTTLS advertising from our mail server and then
the STARTTLS fails. If mail provider doesn't provides the 587 port
(yes, it seems, that the Deutsche Telekom know nothing about them),
or (obsolete) 465 port there isn't another way how to send encrypted
emails.

regards

-- 
Slavko
http://slavino.sk


signature.asc
Description: PGP signature


Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Paul E Condon
On Mon, Jul 28, 2014 at 02:02:29PM +0200, Slavko wrote:
 Ahoj,
 
 Dňa Sun, 27 Jul 2014 13:02:18 +0100 Brian a...@cityscape.co.uk
 napísal:
 
  On Sun 27 Jul 2014 at 10:03:29 +0100, Jonathan Dowland wrote:
  
   My current best guess is you are attempting to connect to gmail's
   servers on port 25 and your ISP has blocked connections to port 25
   for any server except their own, in which case port 587 should work
   instead.
  
  He could check with nc.
  
brian@desktop:~$ nc smtp.gmail.com 25
220 mx.google.com ESMTP 19sm41008233wjz.3 - gsmtp
  
 
 AFAIK, the port 25 have to used only for (inter-) servers connections,

Well no, not using 25, but I am using this thread to test if I have
fixed a different problem in my email setup. 
OK to not respond to this denial (;-)

 the clients have connect via 587, the port 25 for client connections is
 for backward compatibility only.
 
 regards
 
 -- 
 Slavko
 http://slavino.sk



-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140728160138.ga5...@gmail.com



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Curt
On 2014-07-28, Paul Condon pecond...@gmail.com wrote:

 I have read that without TLS the email file, and my password are
 sent over the internet in the clear, un-encrypted, and that is
 'clearly' a BAD THING. 

True, but I would think (and here I have the enormous liberty that
comes from thinking in an almost total ignorance of the subject) that
the chances of your password being eavesdropped somewhere between you at
home and the remote mail server of your ISP (at some node on the
network? or sumthin'?) is remote.

No idea how it's done.

Still, I agree totally with you (my ISP uses SSL--I guess they're behind
the times).

 I have seen in recent days enough error message blaming TLS to
 convince me that there are many programmers who beleive it is.
 Until recently, I was like most of the world unaware of the
 whole issue.




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnltctcs.2l1.cu...@einstein.electron.org



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Curt
On 2014-07-28, Paul E Condon pecon...@mesanetworks.net wrote:

 Well no, not using 25, but I am using this thread to test if I have
 fixed a different problem in my email setup. 
 OK to not respond to this denial (;-)


Much more clever than one of those maddening test posts.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnltcu6q.2l1.cu...@einstein.electron.org



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread John Hasler
Slavko writes:
 If mail provider doesn't provides the 587 port (yes, it seems, that
 the Deutsche Telekom know nothing about them), or (obsolete) 465 port
 there isn't another way how to send encrypted emails.

TLS only protects you against being impersonated and against your
messages being intercepted between you and the server.  If you need to
keep the contents of your messages secret you must use end-to-end
encryption.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r415tpcj@thumper.dhh.gt.org



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Curt
On 2014-07-28, John Hasler jhas...@newsguy.com wrote:
 Slavko writes:
 If mail provider doesn't provides the 587 port (yes, it seems, that
 the Deutsche Telekom know nothing about them), or (obsolete) 465 port
 there isn't another way how to send encrypted emails.

 TLS only protects you against being impersonated and against your
 messages being intercepted between you and the server.  If you need to
 keep the contents of your messages secret you must use end-to-end
 encryption.

Just when Paul thought his troubles were over.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnltd0uf.2l1.cu...@einstein.electron.org



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Brian
On Mon 28 Jul 2014 at 10:34:03 -0400, Jerry Stuckle wrote:

 On 7/28/2014 9:56 AM, Brian wrote:
  
  How does the server tell the difference between talking to another
  server (which is acting as client) and what you call a client?
 
 It doesn't, but operation is quite different.  MTA's typically require
 no login on port 25, but only allow messages to be sent to domains it
 serves (otherwise it quickly becomes a spam server).  Port 587 requires
 a login, but allows messages to be relayed to any domain.

Would I be correct in thinking MTAs only talk to each other over port
25?

Would I also be right that using port 587 mandates authentication
whereas with port 25 it is optional?

 Now, for historic reasons, some MTA's still allow login on port 25
 (either directly or some indirect method like accessing a POP or IMAP
 account before sending).  But these are becoming fewer and fewer.

Port 25 then becomes used only for incoming messages to be sent to
domains the server is responsible for? If so, that doesn't appear any
different from the present situation. For relaying a login is perfectly
understanable, but it can be done on port 25 too. What makes port 587
necessary?

All my mail from home is sent directly using exim which, as far as I can
make out will only send on port 25. Leaving aside what you say below (my
ISP does not block outgoing port 25 traffic) I should not be affected?
 
 BTW, many ISP's have blocked outgoing port 25 connections (especially on
 residential accounts) because there are a lot of trojans out there which
 will install a minimal MTA on a user's machine, unbeknownst to the user.
  This allows spammers to use the compromised machine to be a spam
 source, hiding the real source of the spam.

So, in world where every ISP blocks outgoing port 25 connections the
delivering of one's own mail becomes impossible. The flow of spam and
malware across the net will continue to increase though, I suppose.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/28072014174804.fdd19e1d8...@desktop.copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Brian
On Mon 28 Jul 2014 at 17:37:19 +0200, Slavko wrote:

 Dňa Mon, 28 Jul 2014 14:56:40 +0100 Brian a...@cityscape.co.uk
 napísal:
 
  How does the server tell the difference between talking to another
  server (which is acting as client) and what you call a client?

[RFC abstracts snipped. Thanks for them. I'll get round to reading in
detail later]
 
 As client i consider the MUA, but e.g. exim has a client mode too (i
 don't know about other MTAs). I am sorry for simplification.

No need to be sorry. The simplification was fine. It's just that here
mutt and other MUAs connect to exim for direct mail delivery. I wanted
to clarify that servers can also be clients.

 I want to point, that for end users is intended the 587 port, as
 mentioned someone other too, and IMO it is not a good opinion to
 suggest to try (check) the port 25, if the 587 is provided. Another
 goal is, that there are some ISP, which don't blocks/redirects/proxies
 the 587 port yet ;-)

  brian@desktop:~$ nmap -Pn mail.o2.co.uk

  Starting Nmap 6.00 ( http://nmap.org ) at 2014-07-28 18:30 BST
  Nmap scan report for mail.o2.co.uk (82.132.141.69)
  Host is up (0.047s latency).
  Not shown: 998 filtered ports
  PORTSTATE SERVICE
  25/tcp  open  smtp
  110/tcp open  pop3

  Nmap done: 1 IP address (1 host up) scanned in 7.61 seconds

Whether they direct all outgoing port 25 trafic to their own server I do
not know.

Your observation that ISPs could also interfere with port 587 doesn't
cheer me up. :)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/28072014182232.527daac4e...@desktop.copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Bob Holtzman
On Mon, Jul 28, 2014 at 09:11:59AM -0600, Paul Condon wrote:
 On Mon, Jul 28, 2014 at 02:56:40PM +0100, Brian wrote:
  On Mon 28 Jul 2014 at 14:02:29 +0200, Slavko wrote:
  
   Dňa Sun, 27 Jul 2014 13:02:18 +0100 Brian a...@cityscape.co.uk
   napísal:
   
He could check with nc.

  brian@desktop:~$ nc smtp.gmail.com 25
  220 mx.google.com ESMTP 19sm41008233wjz.3 - gsmtp

   
   AFAIK, the port 25 have to used only for (inter-) servers connections,
   the clients have connect via 587, the port 25 for client connections is
   for backward compatibility only.
  
  How does the server tell the difference between talking to another
  server (which is acting as client) and what you call a client?
 
 I have found a script on the web that makes Mutt into a work-alike
 substitute for Thunderbird.

IIRC list protocol suggests that if you have found a solution to a
problem, you post it for others to see and use. I have found a
script... with no other useful information is a waste of everyones
time.

-- 
Bob Holtzman
Giant intergalactic brain-sucking hyperbacteria 
came to Earth to rape our women and create a race 
of mindless zombies.  Look!  It's working!


signature.asc
Description: Digital signature


Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Slavko
Ahoj,

Dňa Mon, 28 Jul 2014 18:37:54 +0100 Brian a...@cityscape.co.uk
napísal:

 No need to be sorry. The simplification was fine. It's just that here
 mutt and other MUAs connect to exim for direct mail delivery. I wanted
 to clarify that servers can also be clients.

It is named as with smarthost, it can be easy set by the
dpkg-reconfigure exim4-config dialog ;)

  I want to point, that for end users is intended the 587 port, as
  mentioned someone other too, and IMO it is not a good opinion to
  suggest to try (check) the port 25, if the 587 is provided. Another
  goal is, that there are some ISP, which don't
  blocks/redirects/proxies the 587 port yet ;-)
 
   brian@desktop:~$ nmap -Pn mail.o2.co.uk
 
   Starting Nmap 6.00 ( http://nmap.org ) at 2014-07-28 18:30 BST
   Nmap scan report for mail.o2.co.uk (82.132.141.69)
   Host is up (0.047s latency).
   Not shown: 998 filtered ports
   PORTSTATE SERVICE
   25/tcp  open  smtp
   110/tcp open  pop3
 
   Nmap done: 1 IP address (1 host up) scanned in 7.61 seconds

Beware, port scan can be criminal in some countries...

 Whether they direct all outgoing port 25 trafic to their own server I
 do not know.

Try ask your email provider to enable 587 port, pointing to the
mentioned RFC ;)

 Your observation that ISPs could also interfere with port 587 doesn't
 cheer me up. :)

It is black side of the freedom...

regards

-- 
Slavko
http://slavino.sk


signature.asc
Description: PGP signature


Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Brian
On Mon 28 Jul 2014 at 20:16:08 +0200, Slavko wrote:

 
 Dňa Mon, 28 Jul 2014 18:37:54 +0100 Brian a...@cityscape.co.uk
 napísal:
 
  No need to be sorry. The simplification was fine. It's just that here
  mutt and other MUAs connect to exim for direct mail delivery. I wanted
  to clarify that servers can also be clients.
 
 It is named as with smarthost, it can be easy set by the
 dpkg-reconfigure exim4-config dialog ;)

I'm aware of the capabilities of 'dpkg-reconfigure exim4-config' and the
'smarthost' option. On this machine (at home) I can deliver my own mail
to its destination without having to rely on someone else. Advantages
are that I get immediate feedback and the certain knowledge the mail has
arrived at its destination.

When out roaming, I use my own server as a smarthost to get the same
advantages.

   I want to point, that for end users is intended the 587 port, as
   mentioned someone other too, and IMO it is not a good opinion to
   suggest to try (check) the port 25, if the 587 is provided. Another
   goal is, that there are some ISP, which don't
   blocks/redirects/proxies the 587 port yet ;-)
  
brian@desktop:~$ nmap -Pn mail.o2.co.uk
  
Starting Nmap 6.00 ( http://nmap.org ) at 2014-07-28 18:30 BST
Nmap scan report for mail.o2.co.uk (82.132.141.69)
Host is up (0.047s latency).
Not shown: 998 filtered ports
PORTSTATE SERVICE
25/tcp  open  smtp
110/tcp open  pop3
  
Nmap done: 1 IP address (1 host up) scanned in 7.61 seconds
 
 Beware, port scan can be criminal in some countries...

Do you really mean criminal? Which countries are these which
criminalise looking at something which is in a public place? Walking
round with my eyes closed and my brain closed down isn't an attracive
prospect.

  Whether they direct all outgoing port 25 trafic to their own server I
  do not know.
 
 Try ask your email provider to enable 587 port, pointing to the
 mentioned RFC ;)

mail.o2.co.uk is not a server I use; it was an example. My email
provider (for sending) is myself. Completely trustworthy and reliable.

  Your observation that ISPs could also interfere with port 587 doesn't
  cheer me up. :)
 
 It is black side of the freedom...

That hasn't done much to increase my cheerfulness. :)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/28072014192714.cd9215baf...@desktop.copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Slavko
Ahoj,

Dňa Mon, 28 Jul 2014 19:57:52 +0100 Brian a...@cityscape.co.uk
napísal:

 Do you really mean criminal? Which countries are these which
 criminalise looking at something which is in a public place? Walking
 round with my eyes closed and my brain closed down isn't an attracive
 prospect.

IMO, this is a common mistake, if something is in public place, it
doesn't mean, that it is a public thing. E.g. if i will on the plaza
(it is a public place), then i will still the privacy person :)
My doors and windows are on public side of my home, but when you will
try to open them, you can be considered as stealer, etc.

-- 
Slavko
http://slavino.sk


signature.asc
Description: PGP signature


Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Brian
On Mon 28 Jul 2014 at 21:08:02 +0200, Slavko wrote:

 Dňa Mon, 28 Jul 2014 19:57:52 +0100 Brian a...@cityscape.co.uk
 napísal:
 
  Do you really mean criminal? Which countries are these which
  criminalise looking at something which is in a public place? Walking
  round with my eyes closed and my brain closed down isn't an attracive
  prospect.

You never really answered my questiom. If you place something in a
public place, a mailserver, for example, why should it be a criminal
offence to look at it. If you did not want it to be seen you have the
solution at hand.
 
 IMO, this is a common mistake, if something is in public place, it
 doesn't mean, that it is a public thing. E.g. if i will on the plaza

By being in public there all sorts of things which can happen to you.
People can do all sorts of things. For example, they can come and talk
to you, buy a meal a meal for you, give you a discarded newpaper to
read, rob you (that's a reportable offence), sing to you, try to sell
you lottery tickets etc, etc.

Don't want any of this; don't go out.

 (it is a public place), then i will still the privacy person :)
 My doors and windows are on public side of my home, but when you will
 try to open them, you can be considered as stealer, etc.

How do feel about people looking at your house and looking in through
the windows? You never know what they are thinking and what information
they are gathering.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/28072014202851.78dda668b...@desktop.copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Slavko
Ahoj,

Dňa Mon, 28 Jul 2014 20:51:31 +0100 Brian a...@cityscape.co.uk
napísal:

 You never really answered my questiom. If you place something in a
 public place, a mailserver, for example, why should it be a criminal
 offence to look at it. If you did not want it to be seen you have the
 solution at hand.

Yes, i provided answer to you. I try it again: If is something in
public place, it doesn't mean, that anybody can do anything with it.

regards

-- 
Slavko
http://slavino.sk


signature.asc
Description: PGP signature


Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Jerry Stuckle
On 7/28/2014 1:16 PM, Brian wrote:
 On Mon 28 Jul 2014 at 10:34:03 -0400, Jerry Stuckle wrote:
 
 On 7/28/2014 9:56 AM, Brian wrote:

 How does the server tell the difference between talking to another
 server (which is acting as client) and what you call a client?

 It doesn't, but operation is quite different.  MTA's typically require
 no login on port 25, but only allow messages to be sent to domains it
 serves (otherwise it quickly becomes a spam server).  Port 587 requires
 a login, but allows messages to be relayed to any domain.
 
 Would I be correct in thinking MTAs only talk to each other over port
 25?


That is correct.

 Would I also be right that using port 587 mandates authentication
 whereas with port 25 it is optional?
 

In a correctly operating MTA, yes.

 Now, for historic reasons, some MTA's still allow login on port 25
 (either directly or some indirect method like accessing a POP or IMAP
 account before sending).  But these are becoming fewer and fewer.
 
 Port 25 then becomes used only for incoming messages to be sent to
 domains the server is responsible for? If so, that doesn't appear any
 different from the present situation. For relaying a login is perfectly
 understanable, but it can be done on port 25 too. What makes port 587
 necessary?
 

This became necessary due to the number of trojans used by spammers to
compromise unsuspecting users.  As a result, many ISP's now block any
outgoing requests to port 25.  In my area, both Verizon and Comcast
(Xfinity) do, for instance.

 All my mail from home is sent directly using exim which, as far as I can
 make out will only send on port 25. Leaving aside what you say below (my
 ISP does not block outgoing port 25 traffic) I should not be affected?
  

Exim can use other ports also.  It's all in the configuration. (but
sorry, I do not have enough expertise to tell you exactly how to do it).

 BTW, many ISP's have blocked outgoing port 25 connections (especially on
 residential accounts) because there are a lot of trojans out there which
 will install a minimal MTA on a user's machine, unbeknownst to the user.
  This allows spammers to use the compromised machine to be a spam
 source, hiding the real source of the spam.
 
 So, in world where every ISP blocks outgoing port 25 connections the
 delivering of one's own mail becomes impossible. The flow of spam and
 malware across the net will continue to increase though, I suppose.
 
 

No, it just means you need to connect to a mail server via port 587,
then have it send the email.

If spammers can't use compromised machines, it severely limits the
number of servers they can use.  And since an IP can be blacklisted if
too much spam is sent through it, responsible hosting companies and ISPs
(i.e. those who don't wish to be blacklisted) will limit the number of
messages which can be sent per time unit and/or terminate accounts for
sending spam.  A user on a compromised machine, though, wouldn't know
their system was blacklisted and probably wouldn't care.

Just another way to help protect unsuspecting users from themselves.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d6acf7.3070...@attglobal.net



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Jerry Stuckle
On 7/28/2014 3:51 PM, Brian wrote:
 On Mon 28 Jul 2014 at 21:08:02 +0200, Slavko wrote:
 
 Dňa Mon, 28 Jul 2014 19:57:52 +0100 Brian a...@cityscape.co.uk
 napísal:

 Do you really mean criminal? Which countries are these which
 criminalise looking at something which is in a public place? Walking
 round with my eyes closed and my brain closed down isn't an attracive
 prospect.
 
 You never really answered my questiom. If you place something in a
 public place, a mailserver, for example, why should it be a criminal
 offence to look at it. If you did not want it to be seen you have the
 solution at hand.
  

If your car is in a public parking lot, does that mean I can get in and
drive it off?

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d6adcc.1050...@attglobal.net



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Tom Furie
On Mon, Jul 28, 2014 at 10:00:00PM +0200, Slavko wrote:
 Ahoj,
 
 Dňa Mon, 28 Jul 2014 20:51:31 +0100 Brian a...@cityscape.co.uk
 napísal:
 
  You never really answered my questiom. If you place something in a
  public place, a mailserver, for example, why should it be a criminal
  offence to look at it. If you did not want it to be seen you have the
  solution at hand.
 
 Yes, i provided answer to you. I try it again: If is something in
 public place, it doesn't mean, that anybody can do anything with it.

To further the analogy that Brian touched on, looking at an object in a
public space is not and cannot be criminal. Using nmap as Brian did, is
like looking at a building and seeing what doors and windows it has, it
doesn't even go so far as checking to see if those doors and windows are
locked.

Cheers,
Tom

-- 
Tex SEX!  The HOME of WHEELS!  The dripping of COFFEE!!  Take me to
Minnesota but don't EMBARRASS me!!


signature.asc
Description: Digital signature


Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Brian
On Mon 28 Jul 2014 at 22:00:00 +0200, Slavko wrote:

 Dňa Mon, 28 Jul 2014 20:51:31 +0100 Brian a...@cityscape.co.uk
 napísal:
 
  You never really answered my questiom. If you place something in a
  public place, a mailserver, for example, why should it be a criminal
  offence to look at it. If you did not want it to be seen you have the
  solution at hand.
 
 Yes, i provided answer to you. I try it again: If is something in
 public place, it doesn't mean, that anybody can do anything with it.

You are stating the obvious.

I'll try a more technical answer. Remember, you were of the opinion that
using nmap could be a criminal offence in some countries (which you
declined to name).

I will use my preferred email client (telnet) for this test.

  brian@desktop:~$ telnet mail.o2.co.uk 25
  Trying 82.132.141.69...
  Connected to mail.o2.co.uk.
  Escape character is '^]'.
  220 mail.o2.co.uk ESMTP Service ready


  brian@desktop:~$ telnet mail.o2.co.uk 587
  Trying 82.132.141.69...
  telnet: Unable to connect to remote host: Connection timed out


I also used another 40.000 ports.

Happpier with this?

Communication is one of the most basic human needs. Have I transgressed
its boundaries?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140728203837.gb19...@copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Brian
On Mon 28 Jul 2014 at 16:05:11 -0400, Jerry Stuckle wrote:

 On 7/28/2014 1:16 PM, Brian wrote:
 
  All my mail from home is sent directly using exim which, as far as I can
  make out will only send on port 25. Leaving aside what you say below (my
  ISP does not block outgoing port 25 traffic) I should not be affected?
   
 
 Exim can use other ports also.  It's all in the configuration. (but
 sorry, I do not have enough expertise to tell you exactly how to do it).

Exim will definitely *receive* mail on multiple ports; that much I do
know. Sending on other than port 25 would appear to contradict the idea
that MTAs only communicate over port 25. But I'll look into it.

  So, in world where every ISP blocks outgoing port 25 connections the
  delivering of one's own mail becomes impossible. The flow of spam and
  malware across the net will continue to increase though, I suppose.
 
 No, it just means you need to connect to a mail server via port 587,
 then have it send the email.

If exim cannot send over port 587. And how do I know the mail
server I'm connecting to is accepting on port 587? I don't think mine
does; I'll have to check. I'm provisionally of the same opinion as
expressed above; the flow of communication is controlled.

 If spammers can't use compromised machines, it severely limits the
 number of servers they can use.  And since an IP can be blacklisted if
 too much spam is sent through it, responsible hosting companies and ISPs
 (i.e. those who don't wish to be blacklisted) will limit the number of
 messages which can be sent per time unit and/or terminate accounts for
 sending spam.  A user on a compromised machine, though, wouldn't know
 their system was blacklisted and probably wouldn't care.
 
 Just another way to help protect unsuspecting users from themselves.

I don't need or want protecting from myself. I'll go to hell in my own
way. :)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140728205650.gc19...@copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Jerry Stuckle
On 7/28/2014 4:56 PM, Brian wrote:
 On Mon 28 Jul 2014 at 16:05:11 -0400, Jerry Stuckle wrote:
 
 On 7/28/2014 1:16 PM, Brian wrote:

 All my mail from home is sent directly using exim which, as far as I can
 make out will only send on port 25. Leaving aside what you say below (my
 ISP does not block outgoing port 25 traffic) I should not be affected?
  

 Exim can use other ports also.  It's all in the configuration. (but
 sorry, I do not have enough expertise to tell you exactly how to do it).
 
 Exim will definitely *receive* mail on multiple ports; that much I do
 know. Sending on other than port 25 would appear to contradict the idea
 that MTAs only communicate over port 25. But I'll look into it.


Yes and no.  There is also an concept of smart host (I don't know if
this is exim only), where all outgoing mail is routed through a
different host.  It's quite often used in large companies, for instance,
where an MTA receives all mail from users and delivers locally.  This
server is not directly accessible via the internet; rather another MTA
handles all traffic in and out of the network.

But the main thought here is - you shouldn't be running a local mail
server on a residential account.  There really is no need for it
(business accounts are different).

 So, in world where every ISP blocks outgoing port 25 connections the
 delivering of one's own mail becomes impossible. The flow of spam and
 malware across the net will continue to increase though, I suppose.

 No, it just means you need to connect to a mail server via port 587,
 then have it send the email.
 
 If exim cannot send over port 587. And how do I know the mail
 server I'm connecting to is accepting on port 587? I don't think mine
 does; I'll have to check. I'm provisionally of the same opinion as
 expressed above; the flow of communication is controlled.
 

I never said Exim cannot send over port 587.  In fact, I said just the
opposite.  I just don't know enough about Exim configuration to provide
the details.

But then if you have residential service, there really is no need to
have your own MTA (other than you want it).

And even if you do have your own MTA, it doesn't help that much.  When
you send a message, all your MTA can do is tell you if the message was
accepted by the destination MTA.  Using a remote MTA will do the same thing.

One other thing - if you have a dynamic IP address, none of the servers
I maintain will ever accept your email.  Dynamic IPs are specifically
blocked due to spam problems.  That is also becoming more and more common.

 If spammers can't use compromised machines, it severely limits the
 number of servers they can use.  And since an IP can be blacklisted if
 too much spam is sent through it, responsible hosting companies and ISPs
 (i.e. those who don't wish to be blacklisted) will limit the number of
 messages which can be sent per time unit and/or terminate accounts for
 sending spam.  A user on a compromised machine, though, wouldn't know
 their system was blacklisted and probably wouldn't care.

 Just another way to help protect unsuspecting users from themselves.
 
 I don't need or want protecting from myself. I'll go to hell in my own
 way. :)
 
 

The problem is it's not YOU who suffers if your machine is compromised.
 It is the rest of the internet.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d6bb34.6000...@attglobal.net



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Joe
On Mon, 28 Jul 2014 18:16:23 +0100
Brian a...@cityscape.co.uk wrote:

 On Mon 28 Jul 2014 at 10:34:03 -0400, Jerry Stuckle wrote:
 
  On 7/28/2014 9:56 AM, Brian wrote:
   
   How does the server tell the difference between talking to another
   server (which is acting as client) and what you call a client?
  
  It doesn't, but operation is quite different.  MTA's typically
  require no login on port 25, but only allow messages to be sent to
  domains it serves (otherwise it quickly becomes a spam server).
  Port 587 requires a login, but allows messages to be relayed to any
  domain.
 
 Would I be correct in thinking MTAs only talk to each other over port
 25?
 
 Would I also be right that using port 587 mandates authentication
 whereas with port 25 it is optional?
 
  Now, for historic reasons, some MTA's still allow login on port 25
  (either directly or some indirect method like accessing a POP or
  IMAP account before sending).  But these are becoming fewer and
  fewer.
 
 Port 25 then becomes used only for incoming messages to be sent to
 domains the server is responsible for? If so, that doesn't appear any
 different from the present situation. For relaying a login is
 perfectly understanable, but it can be done on port 25 too. What
 makes port 587 necessary?

Simply to provide a standard port on which authentication is expected
and used, leaving 25 for unauthenticated mail. An email sent to an
arbitrary address will be unauthenticated, because none of us have
authentication credentials for all the world's mail servers.
Unauthenticated mail will be delivered only *to* the domains the
receiving server is authoritative for, or relayed *to* anywhere, but
only *from* domains which are explicitly configured in the server. I
think the very basic Debian setup of exim4 allows the entry of such
permitted relaying domains, and certainly the full configuration file(s)
does so.
 
 All my mail from home is sent directly using exim which, as far as I
 can make out will only send on port 25. Leaving aside what you say
 below (my ISP does not block outgoing port 25 traffic) I should not
 be affected? 
  BTW, many ISP's have blocked outgoing port 25 connections
  (especially on residential accounts) because there are a lot of
  trojans out there which will install a minimal MTA on a user's
  machine, unbeknownst to the user. This allows spammers to use the
  compromised machine to be a spam source, hiding the real source of
  the spam.

Almost as good is for ISPs to refuse to create proper PTR records for
domestic IP addresses. The vast majority of spam rejected by my server
comes from IP addresses which do not have a complementary PTR-A record
pair in public DNS, and this is a test which just about all SMTP servers
carry out on incoming mail. Virtually all the spam that does get
through comes from Google and Yahoo mail servers, and from 'business'
mail hosting accounts with random domain names set up purely for the
distribution of spam, which is presumably economic to do.

An effective further step is to accept email only for legitimate users
of the receiving domain, and not just anyone@domain.com. The large
majority of spam I see is sent to obviously made-up user names on my
domains, and my server would reject those connections if the DNS check
hadn't already done so. This is NDR spam, which relies on a SMTP server
accepting such mail, then the mail being refused by a subsequent
server or remaining uncollected by clients. The SMTP server which was
fooled now has to issue an NDR, sent to a forged sender address, now
coming from a fairly legitimate mail server and therefore being more
likely to be delivered to the real target, the forged sender address.
The NDR does, of course, contain the entire spam message. If all SMTP
servers accepted mail only for a set of named users, NDR spam could be
eliminated.

 
 So, in world where every ISP blocks outgoing port 25 connections the
 delivering of one's own mail becomes impossible. The flow of spam and
 malware across the net will continue to increase though, I suppose.
 
 
That's supposedly the main distinction between domestic and business
Internet accounts, that business accounts don't block ports and do
permit the use of public Internet servers such as SMTP servers. Most
domestic accounts explicitly forbid server operation. In many countries,
business accounts are expensive or unavailable, and even in the UK,
'business' accounts tend to cost a fair bit more.

But ultimately, whatever TCP port number is used, it is impossible to
distinguish a spammer from a legitimate sender of email. We can't tell
spammers not to use 587, nor that they aren't permitted to use the
hijacked computer's TLS credentials, if any. DNS tests are currently
more reliable than blocking ports, though I do know two small-ish
businesses in the UK who use third-party mail services with incorrectly
setup DNS. I've told them a couple of times, but there is evidently
nobody involved who knows what a PTR 

Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Brian
On Mon 28 Jul 2014 at 16:08:44 -0400, Jerry Stuckle wrote:

 On 7/28/2014 3:51 PM, Brian wrote:
  On Mon 28 Jul 2014 at 21:08:02 +0200, Slavko wrote:
  
  Dňa Mon, 28 Jul 2014 19:57:52 +0100 Brian a...@cityscape.co.uk
  napísal:
 
  Do you really mean criminal? Which countries are these which
  criminalise looking at something which is in a public place? Walking
  round with my eyes closed and my brain closed down isn't an attracive
  prospect.
  
  You never really answered my questiom. If you place something in a
  public place, a mailserver, for example, why should it be a criminal
  offence to look at it. If you did not want it to be seen you have the
  solution at hand.
   
 
 If your car is in a public parking lot, does that mean I can get in and
 drive it off?

I never said that you could. I guess that would be unacceptable in every
country except in the most extenuating of circumstances.

I was talking about looking at something. How do you send (or not send,
as the case may be) email through a server if you do not look at it?

  brian@desktop:~$ telnet smtp.verizon.net 25
  Trying 206.46.232.100...
  telnet: Unable to connect to remote host: Connection timed out

  brian@desktop:~$ telnet smtp.verizon.net 465
  Trying 206.46.232.100...
  Connected to smtp.verizon.net.
  Escape character is '^]'.

Now I know the smarthost setting in exim requires port 465.

Anything wrong with this? Is nmap more or less evil?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140728212705.gd19...@copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Joe
On Mon, 28 Jul 2014 21:56:50 +0100
Brian a...@cityscape.co.uk wrote:

 On Mon 28 Jul 2014 at 16:05:11 -0400, Jerry Stuckle wrote:
 
  On 7/28/2014 1:16 PM, Brian wrote:
  
   All my mail from home is sent directly using exim which, as far
   as I can make out will only send on port 25. Leaving aside what
   you say below (my ISP does not block outgoing port 25 traffic) I
   should not be affected? 
  
  Exim can use other ports also.  It's all in the configuration. (but
  sorry, I do not have enough expertise to tell you exactly how to do
  it).
 
 Exim will definitely *receive* mail on multiple ports; that much I do
 know. Sending on other than port 25 would appear to contradict the
 idea that MTAs only communicate over port 25. But I'll look into it.
 

You can do nearly anything you can imagine with exim4. It has 'routers'
to deal differently with different sending and receiving domains (and
pretty much any other aspect of a message it is given), and 'transports'
which specify how the message is to be handled, SMTP being one
alternative. You set up a transport to deal with a particular remote
server, then a router to identify the mail to be sent there. You can
have an arbitrary number of smarthosts handling different domains, or
send directly to some domains, all other mail going via a smarthost,
etc. The routers have to be in a particular order, the transports don't.

Here are a router and transport I used for sending to a smarthost, years
ago, for all mail to a set of sub-domains. I no longer have any domain
names hosted here, so I've left in the mail host's name and server
details. Here also is the skeleton conf.d/passwd.client file where
server logon credentials are saved.



#
### router/200_exim4-config_primary
#

### router/200_exim4-config_primary
#
# This file holds the primary router, responsible for nonlocal mails

.ifdef DCconfig_internet
# configtype=internet
#
# deliver mail to the recipient if recipient domain is a domain we
# relay for. We do not ignore any target hosts here since delivering to
# a site local or even a link local address might be wanted here, and if
# such an address has found its way into the MX record of such a domain,
# the local admin is probably in a place where that broken MX record
# could be fixed.

#mydomain:
  debug_print = R: mydomain for $local_part@$domain
  driver = manualroute
  domains = *.mydomain.co.uk
  transport = oneandone_auth_smtp
  route_list = * auth.smtp.1and1.co.uk





### transport/30_exim4-config_remote_smtp_smarthost
#

# This transport is used for delivering messages over SMTP connections
# to a smarthost. The local host tries to authenticate.
# This transport is used for smarthost and satellite configurations.

remote_smtp_smarthost:
  debug_print = T: remote_smtp_smarthost for $local_part@$domain
  driver = smtp
  hosts_try_auth = ; ${if exists{CONFDIR/passwd.client} \
{\
${lookup{$host}nwildlsearch{CONFDIR/passwd.client}{$host_address}}\
}\
{} \
  }
.ifdef REMOTE_SMTP_SMARTHOST_HOSTS_AVOID_TLS
  hosts_avoid_tls = REMOTE_SMTP_SMARTHOST_HOSTS_AVOID_TLS
.endif
.ifdef REMOTE_SMTP_HEADERS_REWRITE
  headers_rewrite = REMOTE_SMTP_HEADERS_REWRITE
.endif
.ifdef REMOTE_SMTP_RETURN_PATH
  return_path = REMOTE_SMTP_RETURN_PATH
.endif
.ifdef REMOTE_SMTP_HELO_FROM_DNS
  helo_data=REMOTE_SMTP_HELO_DATA
.endif

oneandone_auth_smtp:
  debug_print = T: oneandone_auth_smtp for $local_part@$domain
  driver = smtp
  hosts_require_auth = auth.smtp.1and1.co.uk
  port = 587



#
### end transport/30_exim4-config_remote_smtp_smarthost
#




/etc/exim4/conf.d/passwd.client:

# password file used when the local exim is authenticating to a remote
# host as a client.
#
# see exim4_passwd_client(5) for more documentation
#
# Example:
### target.mail.server.example:login:password


-- 
Joe


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140728224519.53f93...@jretrading.com



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Joe
On Mon, 28 Jul 2014 21:38:37 +0100
Brian a...@cityscape.co.uk wrote:

 On Mon 28 Jul 2014 at 22:00:00 +0200, Slavko wrote:
 
  Dňa Mon, 28 Jul 2014 20:51:31 +0100 Brian a...@cityscape.co.uk
  napísal:
  
   You never really answered my questiom. If you place something in a
   public place, a mailserver, for example, why should it be a
   criminal offence to look at it. If you did not want it to be seen
   you have the solution at hand.
  
  Yes, i provided answer to you. I try it again: If is something in
  public place, it doesn't mean, that anybody can do anything with it.
 
 You are stating the obvious.
 
 I'll try a more technical answer. Remember, you were of the opinion
 that using nmap could be a criminal offence in some countries (which
 you declined to name).
 
 I will use my preferred email client (telnet) for this test.
 
   brian@desktop:~$ telnet mail.o2.co.uk 25
   Trying 82.132.141.69...
   Connected to mail.o2.co.uk.
   Escape character is '^]'.
   220 mail.o2.co.uk ESMTP Service ready
 
 
   brian@desktop:~$ telnet mail.o2.co.uk 587
   Trying 82.132.141.69...
   telnet: Unable to connect to remote host: Connection timed out
 
 
 I also used another 40.000 ports.
 
 Happpier with this?
 
 Communication is one of the most basic human needs. Have I
 transgressed its boundaries?
 
 

Not as far as it goes. I occasionally use telnet to a mail server to
check an email address is valid. That's a legitimate SMTP function to
use anonymously, and many email clients use it to verify an address
while you're composing an email. But if you got a reply on 587 and then
tried guessing user names and passwords, knowing you didn't have an
account there, I think you would be attempting to gain unauthorised
access to a computer system, which is an offence in some countries.

And SMTP and HTTP are protocols normally accessed anonymously, as FTP
can be. Other protocols, such as SSH and RDP are never accessible
anonymously, they always require an account on the server, and it could
be argued that any connection attempts to such ports were 'attempting
to gain...' Also, the use of malformed connection packets can sometimes
gain access to vulnerabilities in servers, and such behaviour would
seem to fall foul of the definition. nmap can certainly be used to
try to identify the OS in use by a server, and perhaps try to see
some details of the network behind the firewall, which again would not
seem to be legitimate things to do. It's not clear cut, but some
behaviours would appear to be legitimate, and some not.

-- 
Joe


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140728230432.01a73...@jretrading.com



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Brian
On Mon 28 Jul 2014 at 17:05:56 -0400, Jerry Stuckle wrote:

 On 7/28/2014 4:56 PM, Brian wrote:
  
  Exim will definitely *receive* mail on multiple ports; that much I do
  know. Sending on other than port 25 would appear to contradict the idea
  that MTAs only communicate over port 25. But I'll look into it.
 
 
 Yes and no.  There is also an concept of smart host (I don't know if
 this is exim only), where all outgoing mail is routed through a
 different host.  It's quite often used in large companies, for instance,
 where an MTA receives all mail from users and delivers locally.  This
 server is not directly accessible via the internet; rather another MTA
 handles all traffic in and out of the network.
 
 But the main thought here is - you shouldn't be running a local mail
 server on a residential account.  There really is no need for it
 (business accounts are different).

You would have to explain that very, very carefully to me. Nobody who is
not part of a corporate environment is allowed to deliver their own
mail? I am not permitted to have the freedom to communicate in whatever
way I want because I live in a house and do not work in a office? Is
that in an RFC? You are telling me there is no need to pop a letter
though the letterbox of the house next door because I can get Royal Mail
to do it for me?

  If exim cannot send over port 587. And how do I know the mail
  server I'm connecting to is accepting on port 587? I don't think mine
  does; I'll have to check. I'm provisionally of the same opinion as
  expressed above; the flow of communication is controlled.
  
 
 I never said Exim cannot send over port 587.  In fact, I said just the
 opposite.  I just don't know enough about Exim configuration to provide
 the details.
 
 But then if you have residential service, there really is no need to
 have your own MTA (other than you want it).

I want to. When I go to relatives in London I want to take parcelled up
birthday presents with me rather than entrust them to DHL. Of course, I
needn't - but I want to.

 And even if you do have your own MTA, it doesn't help that much.  When
 you send a message, all your MTA can do is tell you if the message was
 accepted by the destination MTA.  Using a remote MTA will do the same thing.

You are guaranteeing the remote MTA will have 100% uptime and sends
mails and non-delivery messages in a timely fashion? And yes, knowing
the mail was accepted by the destination MTA is important; when someone
says they haven't received a mail from me I can demonstrate otherwise.
 
 One other thing - if you have a dynamic IP address, none of the servers
 I maintain will ever accept your email.  Dynamic IPs are specifically
 blocked due to spam problems.  That is also becoming more and more common.

Dynamic IP = spam senders. What's that? 80%. 90% of the people on the
internet. Disenfranchisement on a massive scale. O brave new world, That
has such people in't.
 
  I don't need or want protecting from myself. I'll go to hell in my own
  way. :)
 
 The problem is it's not YOU who suffers if your machine is compromised.
  It is the rest of the internet.

Compromised? No need to worry; everything is in capable hands. Unlike
the large ISP networks which harbour spam bots.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140728223600.ge19...@copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Jerry Stuckle
On 7/28/2014 6:36 PM, Brian wrote:
 On Mon 28 Jul 2014 at 17:05:56 -0400, Jerry Stuckle wrote:
 
 On 7/28/2014 4:56 PM, Brian wrote:

 Exim will definitely *receive* mail on multiple ports; that much I do
 know. Sending on other than port 25 would appear to contradict the idea
 that MTAs only communicate over port 25. But I'll look into it.


 Yes and no.  There is also an concept of smart host (I don't know if
 this is exim only), where all outgoing mail is routed through a
 different host.  It's quite often used in large companies, for instance,
 where an MTA receives all mail from users and delivers locally.  This
 server is not directly accessible via the internet; rather another MTA
 handles all traffic in and out of the network.

 But the main thought here is - you shouldn't be running a local mail
 server on a residential account.  There really is no need for it
 (business accounts are different).
 
 You would have to explain that very, very carefully to me. Nobody who is
 not part of a corporate environment is allowed to deliver their own
 mail? I am not permitted to have the freedom to communicate in whatever
 way I want because I live in a house and do not work in a office? Is
 that in an RFC? You are telling me there is no need to pop a letter
 though the letterbox of the house next door because I can get Royal Mail
 to do it for me?


No RFC - and no RFC is required.  ISPs are free to set their own rules
on how they run their own systems.  If you don't like it, you can find
another ISP.

But they also are not in any violation of any RFC's.  No RFC says they
have to provide port 25 connectivity to your system.


 If exim cannot send over port 587. And how do I know the mail
 server I'm connecting to is accepting on port 587? I don't think mine
 does; I'll have to check. I'm provisionally of the same opinion as
 expressed above; the flow of communication is controlled.


 I never said Exim cannot send over port 587.  In fact, I said just the
 opposite.  I just don't know enough about Exim configuration to provide
 the details.

 But then if you have residential service, there really is no need to
 have your own MTA (other than you want it).
 
 I want to. When I go to relatives in London I want to take parcelled up
 birthday presents with me rather than entrust them to DHL. Of course, I
 needn't - but I want to.
 

Completely immaterial.

 And even if you do have your own MTA, it doesn't help that much.  When
 you send a message, all your MTA can do is tell you if the message was
 accepted by the destination MTA.  Using a remote MTA will do the same thing.
 
 You are guaranteeing the remote MTA will have 100% uptime and sends
 mails and non-delivery messages in a timely fashion? And yes, knowing
 the mail was accepted by the destination MTA is important; when someone
 says they haven't received a mail from me I can demonstrate otherwise.
  

If they are a good ISP, then they will have higher uptime than you do!
And even if they are down - your local system will tell you and you can
try again later.

But you also seem to think that just because the remote MTA accepted the
email the user got it.  That is not necessarily so - for a lot of
reasons.  For instance, many MTA's will silently drop emails to a bad
address rather than rejecting them.  It makes it much harder for a
spammer to discover whether an email is valid or not.

 One other thing - if you have a dynamic IP address, none of the servers
 I maintain will ever accept your email.  Dynamic IPs are specifically
 blocked due to spam problems.  That is also becoming more and more common.
 
 Dynamic IP = spam senders. What's that? 80%. 90% of the people on the
 internet. Disenfranchisement on a massive scale. O brave new world, That
 has such people in't.


That's the way it is.  There is a significant amount of spam sent from
compromised residential machines.  These are almost always on dynamic
IPs.  Like it or not - that's the way it is.

 I don't need or want protecting from myself. I'll go to hell in my own
 way. :)

 The problem is it's not YOU who suffers if your machine is compromised.
  It is the rest of the internet.
 
 Compromised? No need to worry; everything is in capable hands. Unlike
 the large ISP networks which harbour spam bots.
 
 

Then prove it to your ISP.  And please name the large ISP networks
which harbor spam bots.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d6d9b8.1090...@attglobal.net



Re: Finding a replacement for my ISP's smtp server

2014-07-28 Thread Jerry Stuckle
On 7/28/2014 5:27 PM, Brian wrote:
 On Mon 28 Jul 2014 at 16:08:44 -0400, Jerry Stuckle wrote:
 
 On 7/28/2014 3:51 PM, Brian wrote:
 On Mon 28 Jul 2014 at 21:08:02 +0200, Slavko wrote:

 Dňa Mon, 28 Jul 2014 19:57:52 +0100 Brian a...@cityscape.co.uk
 napísal:

 Do you really mean criminal? Which countries are these which
 criminalise looking at something which is in a public place? Walking
 round with my eyes closed and my brain closed down isn't an attracive
 prospect.

 You never really answered my questiom. If you place something in a
 public place, a mailserver, for example, why should it be a criminal
 offence to look at it. If you did not want it to be seen you have the
 solution at hand.
  

 If your car is in a public parking lot, does that mean I can get in and
 drive it off?
 
 I never said that you could. I guess that would be unacceptable in every
 country except in the most extenuating of circumstances.


So is port scanning, in many countries.

 I was talking about looking at something. How do you send (or not send,
 as the case may be) email through a server if you do not look at it?
 

Even trying to open the door on your car (to see if it is locked) can be
breaking and entering, whether or not you took something.

   brian@desktop:~$ telnet smtp.verizon.net 25
   Trying 206.46.232.100...
   telnet: Unable to connect to remote host: Connection timed out
 
   brian@desktop:~$ telnet smtp.verizon.net 465
   Trying 206.46.232.100...
   Connected to smtp.verizon.net.
   Escape character is '^]'.
 
 Now I know the smarthost setting in exim requires port 465.


That is the way the default is set up.  But it is not cast in concrete;
it is a configuration parameter.

 Anything wrong with this? Is nmap more or less evil?
 
 

As others have said - in some countries it is illegal - just like trying
to open your car door (or a window on your house).

Which also begs the question - why would you need to do a port scan on
your ISP?  That's what help files are for.

You seem to think anything on the internet is there for your personal
benefit.  That is NOT the case.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d6db00.40...@attglobal.net



Re: Finding a replacement for my ISP's smtp server

2014-07-27 Thread Bret Busby
On 27/07/2014, Bret Busby bret.bu...@gmail.com wrote:
 On 27/07/2014, Paul E Condon pecon...@mesanetworks.net wrote:
 I've known for a long while that there was something
 strange about sending mail via my ISP. They have made
 it clear in that they do not require or use TLS. It
 occurs to me that perhaps my computer does not have
 installed the appropriate certs to function with TLS.
 How would I ever have known they were missing if they
 were not being used? So maybe their goofyness has allowed me to miss
 something that I was doing something wrong from way back when I first got
 started
 in Debian in about Y2K. Certs are used for https and
 these must be on the computer because it manages to
 connect to my banks (2) , but maybe the ones needed to do SMTP are some
 different? How can I check. I have found some instructions for using
 gmail
 as a smart host and I'm trying to follow them, but things are not
 working. When I press the 'y' key in mutt to send an
 email, the message 'sending...' displays in the bottom
 line, but it stays there for many minutes when it once would accept an
 email is just a few seconds. How can I
 find out what is happening during that time? Is there
 some debug tool?

 Thoughts or suggestions?

 --
 Paul



 Hello.

 1. I am not a Debian or email expert, merely a user of limited knowledge.

 2. The message appears to me, to be inconsistent with the message
 subject. Do you want to replace your ISP, or, are you trying to find
 how to better access your ISP's SMTP server?

 3.  You have not stated which version of Debian, you are using. This
 can be important, as one of the email applications that I use, iceape,
 is, I believe, not available for Debian 7.x, and I do not know how
 another; alpine, behaves with Debian 7.x.

 4. Wih email, I use three different applications (I believe that I use
 no more than three); for outgoing email, I use iceape, Opera, and, in
 most replies to email messages, alpine. I use two different ISP's
 (Internet Service Providers); one for accessing the Internet (and
 thus, providing the SMTP server), and another for web sites hosting
 (and thus, for the IMAP server). The ISP for the IMAP server, has
 recently (causing much trouble) switched its legacy hosting from an
 ISP that it had taken over, and, had instituted IMAP hosting using
 TLS, and so the IMAP server in alpine (the INBOX path) had to be
 changed. The SMTP server does not show, as involving TLS (I have no
 idea, as to what is TLS, only that it is something that has to be
 addressed in the INBOX path), and, the SMTP server address, is the
 same for each of the outgoing email applications. I am unot familiar
 with using mutt as an amial application, but I suggest that you try
 the SMTP server address, in each of a couple of other email
 applications, for example, download and instal Opera, and (if
 applicable) iceape, set up mail accounts, with the SMTP server address
 that you are now using, and, send to yourself (to a gmail account, for
 example), test messages, via each of the email applicatoions, and,
 examine the time taken to send each message.

 5. I note that your message does not indicate whether the delays in
 sending, are for every message, are regular, or, are occasional. Such
 information, is important. I occasionally get delays, and, sometimes,
 timeouts, when sending messages, and I assume that it is due to the
 SMTP server, or, one of the nodes between here and the SMTP server,
 being busy.

 I hope that this is helpful.



Two further aspects of this, have since occurred to me (and, a third,
added for luck :) ).

6. You did not name your ISP. Perhaps, if you had included in your
post, the name of the ISP, someone else on this list, may have
experience with the particular ISP, and, be able to give you the
simple solution (assuming that the solution is simple; which it can be
- sometimes, as simple as substitution of the path for the SMTP
server, eg, in apline/pine, at the end of the path for the SMTP
server, having novalidate-cert) - sometimes, solutions, especially
with email, can be amazingly simple.

6. Have you contacted your ISP support people, and, asked them what
exactly is the correct path for the SMTP server? It may be on an FAQ
web poage for the ISP, or, may be resolved by contacting the ISP (best
by email, if email contact is available, and, if response time, is
adequate), and, putting the explicit question what exactly, is the
correct path for the SMTP server, to be input into email
applications?. Once again, it may be an amazingly simple solution,
once you know what is the solution.

7. And, see my signature quotation.

-- 
Bret Busby
Armadale
West Australia
..

So once you do know what the question actually is,
 you'll know what the answer means.
- Deep Thought,
 Chapter 28 of Book 1 of
 The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts,
 written by Douglas Adams,
 published by Pan Books, 1992


Re: Finding a replacement for my ISP's smtp server

2014-07-27 Thread Jonathan Dowland
What precise instructions did you follow / what configuration have you supplied
mutt to try and send via gmail?

My current best guess is you are attempting to connect to gmail's servers on
port 25 and your ISP has blocked connections to port 25 for any server except
their own, in which case port 587 should work instead.

It may be better to configure an MTA on your machine (such as exim by default,
in Debian) to send mail to gmail, rather than mutt directly. That way anything
generating mail on the system will be set up correctly.


-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140727090329.ga25...@bryant.redmars.org



Re: Finding a replacement for my ISP's smtp server

2014-07-27 Thread Brian
On Sat 26 Jul 2014 at 19:56:12 -0600, Paul E Condon wrote:

 I've known for a long while that there was something
 strange about sending mail via my ISP. They have made
 it clear in that they do not require or use TLS. It

You have to authenticate yourself when you join your ISP's network. No
further authentication is needed to use their SMTP server; you are a
trusted user so TLS is therefore not required.

If you send mail through the same server when you are on another network
an ISP doesn't trust you and (if they allow the server to be used in
this circumstance) might want authentication over TLS.

 occurs to me that perhaps my computer does not have
 installed the appropriate certs to function with TLS.
 How would I ever have known they were missing if they
 were not being used? So maybe their goofyness has allowed me to miss
 something that I was doing something wrong from way back when I first got
 started
 in Debian in about Y2K. Certs are used for https and
 these must be on the computer because it manages to
 connect to my banks (2) , but maybe the ones needed to do SMTP are some

The certs used with https are for your benefit, not the benefit of the
web site.

 different? How can I check. I have found some instructions for using gmail

You only need a cert if you are *receiving* mail using your own SMTP
server.

 as a smart host and I'm trying to follow them, but things are not
 working. When I press the 'y' key in mutt to send an

What benefit to you is there in using gmail's server to relay mail for
you? In what way is your ISP's server deficient?

 email, the message 'sending...' displays in the bottom
 line, but it stays there for many minutes when it once would accept an
 email is just a few seconds. How can I
 find out what is happening during that time? Is there
 some debug tool?
 
 Thoughts or suggestions?

Of possible use:

   
https://lists.debian.org/0c9db5f869098cadf984beb91ffe3950.squir...@webmail.myownsite.me


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140727110458.gf27...@copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-27 Thread Brian
On Sun 27 Jul 2014 at 10:03:29 +0100, Jonathan Dowland wrote:

 My current best guess is you are attempting to connect to gmail's servers on
 port 25 and your ISP has blocked connections to port 25 for any server except
 their own, in which case port 587 should work instead.

He could check with nc.

  brian@desktop:~$ nc smtp.gmail.com 25
  220 mx.google.com ESMTP 19sm41008233wjz.3 - gsmtp


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/27072014130049.5cf50ed3a...@desktop.copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-27 Thread Paul E Condon
I think I may have found a fix for this. I found some instructions
which allowed me to check whether or not I had just done a step
correctly before
going on to the next step. At the end a window popped up announcing that
I had completed the setting up correctly, but that it might take up to 2 days
for the setup to take effect. I am waiting, hopefully. Trying
something now may just disrupt the process.

On Sat, Jul 26, 2014 at 7:56 PM, Paul E Condon
pecon...@mesanetworks.net wrote:
 I've known for a long while that there was something
 strange about sending mail via my ISP. They have made
 it clear in that they do not require or use TLS. It
 occurs to me that perhaps my computer does not have
 installed the appropriate certs to function with TLS.
 How would I ever have known they were missing if they
 were not being used? So maybe their goofyness has allowed me to miss
 something that I was doing something wrong from way back when I first got
 started
 in Debian in about Y2K. Certs are used for https and
 these must be on the computer because it manages to
 connect to my banks (2) , but maybe the ones needed to do SMTP are some
 different? How can I check. I have found some instructions for using gmail
 as a smart host and I'm trying to follow them, but things are not
 working. When I press the 'y' key in mutt to send an
 email, the message 'sending...' displays in the bottom
 line, but it stays there for many minutes when it once would accept an email
 is just a few seconds. How can I
 find out what is happening during that time? Is there
 some debug tool?

 Thoughts or suggestions?

 --
 Paul


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CADQD7YVAh=qkdSmBKEA5CSyAddRGksp=4s4UKeWEjbaOS=x...@mail.gmail.com



Re: Finding a replacement for my ISP's smtp server

2014-07-27 Thread Brian
On Sun 27 Jul 2014 at 07:49:47 -0600, Paul E Condon wrote:

 I think I may have found a fix for this. I found some instructions
 which allowed me to check whether or not I had just done a step
 correctly before
 going on to the next step. At the end a window popped up announcing that
 I had completed the setting up correctly, but that it might take up to 2 days
 for the setup to take effect. I am waiting, hopefully. Trying
 something now may just disrupt the process.

A fix for what? One which takes up to days? Has this got anything to do
with what you wrote below?

 
 On Sat, Jul 26, 2014 at 7:56 PM, Paul E Condon
 pecon...@mesanetworks.net wrote:
  I've known for a long while that there was something
  strange about sending mail via my ISP. They have made
  it clear in that they do not require or use TLS. It
  occurs to me that perhaps my computer does not have
  installed the appropriate certs to function with TLS.
  How would I ever have known they were missing if they
  were not being used? So maybe their goofyness has allowed me to miss
  something that I was doing something wrong from way back when I first got
  started
  in Debian in about Y2K. Certs are used for https and
  these must be on the computer because it manages to
  connect to my banks (2) , but maybe the ones needed to do SMTP are some
  different? How can I check. I have found some instructions for using gmail
  as a smart host and I'm trying to follow them, but things are not
  working. When I press the 'y' key in mutt to send an
  email, the message 'sending...' displays in the bottom
  line, but it stays there for many minutes when it once would accept an email
  is just a few seconds. How can I
  find out what is happening during that time? Is there
  some debug tool?
 
  Thoughts or suggestions?
 
  --
  Paul
 
 
 -- 
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 https://lists.debian.org/CADQD7YVAh=qkdSmBKEA5CSyAddRGksp=4s4UKeWEjbaOS=x...@mail.gmail.com
 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/27072014150838.426513bc4...@desktop.copernicus.demon.co.uk



Re: Finding a replacement for my ISP's smtp server

2014-07-27 Thread Joel Rees
On Sun, Jul 27, 2014 at 1:49 PM, Bret Busby bret.bu...@gmail.com wrote:
 [...] The SMTP server does not show, as involving TLS (I have no
 idea, as to what is TLS, only that it is something that has to be
 addressed in the INBOX path),

http://en.wikipedia.org/wiki/Transport_Layer_Security

What we used to call Secure Sockets Layer (as in openSSL which has not
changed its name to openTLS).

Using TLS with e-mail usually involves clicking a box that says
something like Use TLS and maybe/probably another that says
something like Use STARTTLS.

http://en.wikipedia.org/wiki/STARTTLS

and setting the port number for SMTP connections in the Advanced
settings. 465 is supposed to be a common TLS port for SMTP, but I
don't recall having used that port in the last ten years or more.

The OP will need to check with his mail providers (some of which will
not be his ISP) to find out what port(s) can be used.

Mail providers have web pages for popular mail client setups, and you
have to interpolate a bit from the popular MUA clients to whatever
you're using. Mutt, Claws, Sylpheed, etc., are not generally
considered popular enough, but you can usually figure out what goes
where bye scanning through the MSOutlook and Apple Mail help pages.

-- 
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAAr43iNRi3c75+Dy5=X=ptfjxah8awvvejufv4sxyofwmas...@mail.gmail.com



Re: Finding a replacement for my ISP's smtp server

2014-07-27 Thread Joel Rees
On Sun, Jul 27, 2014 at 10:56 AM, Paul E Condon
pecon...@mesanetworks.net wrote:
 I've known for a long while that there was something
 strange about sending mail via my ISP.

(Piques my curiosity.)

 They have made
 it clear in that they do not require or use TLS.

(Wondering what TLS has to do with strangeness in this case.)

 It
 occurs to me that perhaps my computer does not have
 installed the appropriate certs to function with TLS.

My experience is that MUAs really don't mess with certificates. They
assume the mail server is legit enough to run through a handshake that
involves asymmetric keys, and thus should protect the client from fake
servers trying to steal passwords. This approach is considered
allowable because you should not really be connecting to random mail
servers, and the real server should know how to decrypt your client's
encrypted transmission of your password.

If you are browsing your mail via the web (thus, https for TLS), your
web browser will need certificates for the mail provider's web server.
The certificate would be used for the https connection. But that is
usually transparent to the user. Pre-installed certificates for
everyserver and the kitchen sink on all major browsers including
Iceweasel (which I think is a flaw in implementation, but that's a
separate issue).

 How would I ever have known they were missing if they
 were not being used? So maybe their goofyness has allowed me to miss
 something that I was doing something wrong from way back when I first got
 started
 in Debian in about Y2K. Certs are used for https and
 these must be on the computer because it manages to
 connect to my banks (2) , but maybe the ones needed to do SMTP are some
 different? How can I check.

The difference is basically in the way you log in. In http, you start
without authentication because you're supposed to be starting in
surfing mode (which was supposed to be anonymous, which control-freak
companies can't stand). The shift from http to https uses a different
handshake protocol which involves the assumption that the browser
should recognize or not recognize the https connection by the
certificate. (See above opinion on the current implementation.)

 I have found some instructions for using gmail
 as a smart host and I'm trying to follow them, but things are not
 working.

I hope the instructions you are using are from Google's own pages.

 When I press the 'y' key in mutt to send an
 email, the message 'sending...' displays in the bottom
 line, but it stays there for many minutes when it once would accept an email
 is just a few seconds. How can I
 find out what is happening during that time? Is there
 some debug tool?

 Thoughts or suggestions?

 --
 Paul

Delays in connections may be due to using port numbers other than the
ones the mail provider asks for, or such things. Or it may be the
provider or the MUA falling back from the specified mode, and trying
other modes.

Now that I think of it, I have definitely seen the latter. Set the MUA
to try TLS, but allow fallback, and it has to timeout each attempted
connection as it falls back.

-- 
Joel Rees

Computer memory is just fancy paper,
and the CPU is just a fancy pen.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAAr43iNuSHbzAkMG50wpm=4mjjwxhe1gdvxpyd_rr_huuqf...@mail.gmail.com



Finding a replacement for my ISP's smtp server

2014-07-26 Thread Paul E Condon
I've known for a long while that there was something
strange about sending mail via my ISP. They have made
it clear in that they do not require or use TLS. It
occurs to me that perhaps my computer does not have
installed the appropriate certs to function with TLS.
How would I ever have known they were missing if they
were not being used? So maybe their goofyness has allowed me to miss
something that I was doing something wrong from way back when I first got
started
in Debian in about Y2K. Certs are used for https and
these must be on the computer because it manages to
connect to my banks (2) , but maybe the ones needed to do SMTP are some
different? How can I check. I have found some instructions for using gmail
as a smart host and I'm trying to follow them, but things are not
working. When I press the 'y' key in mutt to send an
email, the message 'sending...' displays in the bottom
line, but it stays there for many minutes when it once would accept an
email is just a few seconds. How can I
find out what is happening during that time? Is there
some debug tool?

Thoughts or suggestions?

--
Paul


Re: Finding a replacement for my ISP's smtp server

2014-07-26 Thread Bret Busby
On 27/07/2014, Paul E Condon pecon...@mesanetworks.net wrote:
 I've known for a long while that there was something
 strange about sending mail via my ISP. They have made
 it clear in that they do not require or use TLS. It
 occurs to me that perhaps my computer does not have
 installed the appropriate certs to function with TLS.
 How would I ever have known they were missing if they
 were not being used? So maybe their goofyness has allowed me to miss
 something that I was doing something wrong from way back when I first got
 started
 in Debian in about Y2K. Certs are used for https and
 these must be on the computer because it manages to
 connect to my banks (2) , but maybe the ones needed to do SMTP are some
 different? How can I check. I have found some instructions for using gmail
 as a smart host and I'm trying to follow them, but things are not
 working. When I press the 'y' key in mutt to send an
 email, the message 'sending...' displays in the bottom
 line, but it stays there for many minutes when it once would accept an
 email is just a few seconds. How can I
 find out what is happening during that time? Is there
 some debug tool?

 Thoughts or suggestions?

 --
 Paul



Hello.

1. I am not a Debian or email expert, merely a user of limited knowledge.

2. The message appears to me, to be inconsistent with the message
subject. Do you want to replace your ISP, or, are you trying to find
how to better access your ISP's SMTP server?

3.  You have not stated which version of Debian, you are using. This
can be important, as one of the email applications that I use, iceape,
is, I believe, not available for Debian 7.x, and I do not know how
another; alpine, behaves with Debian 7.x.

4. Wih email, I use three different applications (I believe that I use
no more than three); for outgoing email, I use iceape, Opera, and, in
most replies to email messages, alpine. I use two different ISP's
(Internet Service Providers); one for accessing the Internet (and
thus, providing the SMTP server), and another for web sites hosting
(and thus, for the IMAP server). The ISP for the IMAP server, has
recently (causing much trouble) switched its legacy hosting from an
ISP that it had taken over, and, had instituted IMAP hosting using
TLS, and so the IMAP server in alpine (the INBOX path) had to be
changed. The SMTP server does not show, as involving TLS (I have no
idea, as to what is TLS, only that it is something that has to be
addressed in the INBOX path), and, the SMTP server address, is the
same for each of the outgoing email applications. I am unot familiar
with using mutt as an amial application, but I suggest that you try
the SMTP server address, in each of a couple of other email
applications, for example, download and instal Opera, and (if
applicable) iceape, set up mail accounts, with the SMTP server address
that you are now using, and, send to yourself (to a gmail account, for
example), test messages, via each of the email applicatoions, and,
examine the time taken to send each message.

5. I note that your message does not indicate whether the delays in
sending, are for every message, are regular, or, are occasional. Such
information, is important. I occasionally get delays, and, sometimes,
timeouts, when sending messages, and I assume that it is due to the
SMTP server, or, one of the nodes between here and the SMTP server,
being busy.

I hope that this is helpful.


-- 
Bret Busby
Armadale
West Australia
..

So once you do know what the question actually is,
 you'll know what the answer means.
- Deep Thought,
 Chapter 28 of Book 1 of
 The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts,
 written by Douglas Adams,
 published by Pan Books, 1992




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACX6j8PXrDLmcDmUWNATzgQCDUhaqrCAzj=5fjzput_zrln...@mail.gmail.com