Re: Finding a replacement for my ISP's smtp server
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 > > > > 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
On Fri, Aug 1, 2014 at 8:05 AM, Jerry Stuckle 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
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
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
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
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
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
On Thu, 31 Jul 2014 18:47:19 +0100 Brian 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
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
On Thu 31 Jul 2014 at 17:37:21 +0100, Joe wrote: > On Thu, 31 Jul 2014 15:37:31 +0100 > Brian 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
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
On Thu, 31 Jul 2014 15:37:31 +0100 Brian 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
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 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
On Mon 28 Jul 2014 at 22:12:09 +0100, Joe wrote: > On Mon, 28 Jul 2014 18:16:23 +0100 > Brian 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
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 > > 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
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
On Mon, 28 Jul 2014 16:48:04 +0100 Darac Marjal 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
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
On Tue, 29 Jul 2014 10:27:08 -0400 Jerry Stuckle 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
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
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
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
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
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
Ahoj, Dňa Tue, 29 Jul 2014 12:22:38 +0300 Andrei POPESCU 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
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
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
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 > 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
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 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
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
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
On Mon, 28 Jul 2014 21:38:37 +0100 Brian wrote: > On Mon 28 Jul 2014 at 22:00:00 +0200, Slavko wrote: > > > Dňa Mon, 28 Jul 2014 20:51:31 +0100 Brian > > 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
On Mon, 28 Jul 2014 21:56:50 +0100
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.
>
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
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 > >> 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
On Mon, 28 Jul 2014 18:16:23 +0100 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? > > 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 @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 ev
Re: Finding a replacement for my ISP's smtp server
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
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
On Mon 28 Jul 2014 at 22:00:00 +0200, Slavko wrote: > Dňa Mon, 28 Jul 2014 20:51:31 +0100 Brian > 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
On Mon, Jul 28, 2014 at 10:00:00PM +0200, Slavko wrote: > Ahoj, > > Dňa Mon, 28 Jul 2014 20:51:31 +0100 Brian > 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
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 >> 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
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
Ahoj, Dňa Mon, 28 Jul 2014 20:51:31 +0100 Brian 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
On Mon 28 Jul 2014 at 21:08:02 +0200, Slavko wrote: > Dňa Mon, 28 Jul 2014 19:57:52 +0100 Brian > 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
Ahoj, Dňa Mon, 28 Jul 2014 19:57:52 +0100 Brian 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
On Mon 28 Jul 2014 at 20:16:08 +0200, Slavko wrote: > > Dňa Mon, 28 Jul 2014 18:37:54 +0100 Brian > 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
Ahoj, Dňa Mon, 28 Jul 2014 18:37:54 +0100 Brian 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
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 > > > 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
On Mon 28 Jul 2014 at 17:37:19 +0200, Slavko wrote: > Dňa Mon, 28 Jul 2014 14:56:40 +0100 Brian > 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
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
On 2014-07-28, John Hasler 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
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
On 2014-07-28, Paul E Condon 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
On 2014-07-28, Paul Condon 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
On Mon, Jul 28, 2014 at 02:02:29PM +0200, Slavko wrote: > Ahoj, > > Dňa Sun, 27 Jul 2014 13:02:18 +0100 Brian > 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
Ahoj, Dňa Mon, 28 Jul 2014 09:35:39 -0600 Paul Condon napísal: > On Mon, Jul 28, 2014 at 01:37:57PM +, Curt wrote: > > On 2014-07-28, Joel Rees 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
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 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
Ahoj, Dňa Mon, 28 Jul 2014 14:56:40 +0100 Brian 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 > > 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
On Mon, Jul 28, 2014 at 01:37:57PM +, Curt wrote: > On 2014-07-28, Joel Rees 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
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 > > 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
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 >> 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
On Mon 28 Jul 2014 at 14:02:29 +0200, Slavko wrote: > Dňa Sun, 27 Jul 2014 13:02:18 +0100 Brian > 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
On 2014-07-28, Joel Rees 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
Ahoj, Dňa Sun, 27 Jul 2014 13:02:18 +0100 Brian 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
On Sun, Jul 27, 2014 at 10:56 AM, Paul E Condon 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
Re: Finding a replacement for my ISP's smtp server
On Sun, Jul 27, 2014 at 1:49 PM, Bret Busby 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
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 > 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
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 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
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
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
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
On 27/07/2014, Bret Busby wrote: > On 27/07/2014, 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 >> 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 b
Re: Finding a replacement for my ISP's smtp server
On 27/07/2014, 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 > 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
Finding a replacement for my ISP's smtp server
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
