 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Applications / Eudora / October 2007How to set multiple SMTP ports?
I have two personalities, each requires a different SMTP port and neither is the standard port 25. I can get my Dominant account to send out mail through port 587 which its mail server requires. But the other account requires sending out through port 26 instead of 25. How can I set this up with Eudora Mac? On Eudora Windows this can be accomplished by adding SMTPPort=26 in the appropriate section for that persona. Is there an x-eudora-setting (7211) that can apply an SMTP port for a specific personality? Thanks > I have two personalities, each requires a different SMTP port and neither > is the standard port 25. I can get my Dominant account to send out mail > through port 587 which its mail server requires. But the other account > requires sending out through port 26 instead of 25. How can I set this up > with Eudora Mac? That specific setup is not hard with the regular settings interface: set the SMTP port to 26 in the 'Ports and Protocols' settings pane, and for the personality that talks to a mail server not run by imbeciles, check "use submission port" in the personality settings pane. And keep in mind that whoever decided to put SMTP for mail submission on port 26 doesn't belong anywhere near a computer serving other people. This is not a system who you should trust with mail you give a damn about. > On Eudora Windows this can be accomplished by adding SMTPPort=26 in the > appropriate section for that persona. Is there an x-eudora-setting (7211) > that can apply an SMTP port for a specific personality? x-eudora-setting:7211@personalityname may indeed work I have not found any x-eudora-setting that makes any sense to have vary between personalities which does not work when set that way. It seems like the user interface works for changing *any* x-eudora-setting on a per-personality basis, but I have not driven it too hard to see how odd it might behave when told to change the toolbars based on personality or anything of that sort.  SignatureClues for the blacklisted: <http://www.scconsult.com/bill/dnsblhelp.html> Current Peeve: The seriously selfish newsgroup meme: "It's on-topic here because I'm interested and I'm here" > keep in mind that whoever decided to put SMTP for mail submission on > port 26 doesn't belong anywhere near a computer serving other people. > This is not a system who you should trust with mail you give a damn about. It has become popular nonetheless, among hosting companies, and look who else promotes it: http://support.microsoft.com/kb/274842 http://support.kerio.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=4 07&nav=0,1 There is also no universal outgoing non-blocking of port 587, nor any assurance that port 587 can't be used for spamming as well (see below), so that any old ISP might be blocking *all* those ports for exactly the same reasons; see the following tale of unpredictable blocking by AOL, for example: http://www.jamestopp.com/dfym/2006/02/16/a-confession/ RFCs concerning "Message submission": The only essential difference between original RFC2476 (still in "Proposed" status) and newer RFC4409 (which is in "Draft" status), interestingly both sponsored by Qualcomm, is new section 4.3, requiring authentication, but RFC4409 is rather new, and may not be enforced: http://xml.resource.org/public/rfc/html/rfc2476.html http://www.ietf.org/rfc/rfc2476.txt [Dec 1998] http://www.ietf.org/rfc/rfc4409.txt [Apr 2006] "Official Internet Protocol Standards" (status) http://www.rfc-editor.org/rfcxx00.html > x-eudora-setting:7211@personalityname may indeed work > [quoted text clipped - 4 lines] > it might behave when told to change the toolbars based on personality or > anything of that sort. FWIW, Qualcomm's Eudora forums suggests yet another possibility: SMTP server: smtp.my.isp:26 Although posted in a Windows thread (by Matt Dudziak of Qualcomm), "Copenhagen" added (in May 2005) "This only works for Mac Eudora as yet" http://eudorabb.qualcomm.com/showthread.php?t=1524 YMMV, I suppose. > FWIW, Qualcomm's Eudora forums suggests yet another possibility: > [quoted text clipped - 3 lines] > "Copenhagen" added (in May 2005) "This only works for Mac Eudora as > yet" http://eudorabb.qualcomm.com/showthread.php?t=1524 Good tip. I'll try that. When I tried it on Win Eudora it did not work and now I know why. Thanks very much for your time. > > keep in mind that whoever decided to put SMTP for mail submission on > > port 26 doesn't belong anywhere near a computer serving other people. [quoted text clipped - 6 lines] > http://support.kerio.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid > =407&nav=0,1 I would have expected Kerio to not be that stupid. > There is also no universal outgoing non-blocking of port 587, > nor any assurance that port 587 can't be used for spamming as well (see > below), 587 can be used for spamming, but it is not generally useful for the sort of spamming that makes up the overwhelming majority of spam and the overwhelming reason for ISP's blocking port 25: direct-to-MX trojan spam. > so that any old ISP might be blocking *all* those ports > for exactly the same reasons; > see the following tale of unpredictable blocking by AOL, for example: > http://www.jamestopp.com/dfym/2006/02/16/a-confession/ Given the statements on that page which *cannot* be true, I don't trust any of it. I won't call him a liar, but he surely does not understand what he's talking about. I'm not familiar with any ISP blocking 587 as a matter of considered policy. I know that some have done so briefly as a result of muddled thinking and irrational exuberance in the deployment of port blocking to stop spam, but I don't know of any who have kept it in place after users have complained. There may be a qualified exception to that at AOL, because at one point they were doing a very strange session hijacking trick that made all port 25 and 587 connections from their users talk to their own SMTP proxies that were slightly broken. It is my understanding that they backed off on doing that on port 587, but it is possible that they just made it much less broken or drove off most of the users who cared. > RFCs concerning "Message submission": > > The only essential difference between > original RFC2476 (still in "Proposed" status) > and newer RFC4409 (which is in "Draft" status), Those are not really "status" descriptions, but rather are "specification maturity levels" and it may not be obvious to people who haven't buried their heads in the arcana of RFC policies that a specification at "Draft Standard" level is more mature (i.e. closer to simply being a "Standard") than is one at "Proposed Standard" level. A Proposed Standard RFC doesn't get reclassified as a Draft Standard, it is used as the basis for an updated specification that is published with a new RFC number and classified as a Draft Standard. > interestingly both sponsored by Qualcomm, Not Exactly. Rather, they were both co-authored by a Qualcomm employee. > is new section 4.3, requiring authentication, > but RFC4409 is rather new, and may not be enforced: [quoted text clipped - 5 lines] > "Official Internet Protocol Standards" (status) > http://www.rfc-editor.org/rfcxx00.html You might want to familiarize yourself with the nature of RFC's and how modern publication and classification of them works, both in principle and reality. For a start, note that there is no such thing as enforcement of RFC's as if they were laws. RFC2476 couldn't do anything more than suggest SMTP AUTH as optional because it was published ahead of the first RFC defining SMTP AUTH, which was being worked on by the same working group at the time. From a standards process view, RFC4409 is not a new standard, it is the current version of the same specification as RFC2476. SignatureNow where did I hide that website... > 587 can be used for spamming, but it is not generally useful for the > sort of spamming that makes up the overwhelming majority of spam and the > overwhelming reason for ISP's blocking port 25: direct-to-MX trojan spam. There is a little "gun shyness" here, because we once got blacklisted by SpamCop for a whopping three pieces of unsolicited mail, received somewhere in Europe, from a student's hijacked PC; the relevance of this old memory will be clearer below. Our incoming port 25 is wide open, however -- but only to the external spam/virus filtering vendor (Postini, just acquired by Google). > I'm not familiar with any ISP blocking 587 as a matter of considered > policy. I know that some have done so briefly as a result of muddled > thinking and irrational exuberance in the deployment of port blocking > to stop spam, but I don't know of any who have kept it in place > after users have complained. The firewall manager here uses a conventional, impolite-sounding (but common) psychological term to describe his own (and management's) philosophy, which is as "irrationally exuberant" as can be -- *all* ports are blocked, in or out, except those one can prove to be absolutely essential to the survival of the species, and if at all possible, even those will be opened only to designated IP addresses, if there are fewer than a dozen specific addresses (or specific internal client/server computers) to which anyone has yet demanded access ;-) When some students tell him that a few *thousand* ports need to be opened for some gaming site to work, he reaches for a bottle of pills and won't come out of the rest room for several hours :) And that's why, AFAIAA, we don't have an incoming authenticated port 587 to our own SMTP server, although even the chairman of the Computer Science department has long been pestering us for it. > There may be a qualified exception to that at AOL, because at one point > they were doing a very strange session hijacking trick that made all > port 25 and 587 connections from their users talk to their own SMTP > proxies that were slightly broken. It is my understanding that they > backed off on doing that on port 587, but it is possible that they just > made it much less broken or drove off most of the users who cared. Our manager was once staying at a hotel chain, where much to his surprise, he was able to send outgoing email "right through our firewall," from his laptop to our internal SMTP server, as his email client had always been set to use. The hotel's wireless network was of course actually proxying it, via a neat service to set itself apart from less savvy hoteliers, and no doubt a profitable niche for the systems vendor, too. >> RFCs [2476, 4409] concerning "Message submission"... > Those are not really "status" descriptions, but rather are > "specification maturity levels" and it may not be obvious to people [quoted text clipped - 4 lines] > it is used as the basis for an updated specification that is published > with a new RFC number and classified as a Draft Standard. Thanks for unmuddling the terminology for me. > they were both co-authored by a Qualcomm employee Thanks for making my description more precise :) > You might want to familiarize yourself with the nature of RFC's and how > modern publication and classification of them works, both in principle > and reality. For a start, note that there is no such thing > as enforcement of RFC's as if they were laws. Well, one could equally say that they are followed (or violated) about the same as any other laws, and that to the extent that straying may cause inter-operational failures with products that are designed to these specifications, they are probably what motivate the general behaviors of real systems anyway, in a world that values smoothly running commerce, as much as could any other "laws." In the Windows Eudora group, it's just become apparent that some Microsoft Exchange server(s) do not include the mandatory "MIME-version: 1.0" header, even in MIME messages going to external destinations, and guess what famous email client, named after a famous writer, will not parse it, nor extract any attachments when that happens? I've suggested that the recipient tell their corporate correspondent to email RFC2045 [section 4] to their systems administrator, and tell them that they might lose some customers, who can't smoothly receive their service, if they don't fix that violation, and maybe that's enough incentive for them to do something about it, even if no jail time is at stake :) > RFC2476 couldn't do anything more than suggest SMTP AUTH as optional > because it was published ahead of the first RFC defining SMTP AUTH, > which was being worked on by the same working group at the time. > From a standards process view, RFC4409 is not a new standard, > it is the current version of the same specification as RFC2476. Thanks for adding that perspective. RFC4409 does bear a recent date, however, so it might not yet have influenced all SMTP servers to require the authorization which it now mandates; perhaps that's where SpamCop's alternate "vigilante" approach comes in, to put a gun to the head of whoever doesn't do what they want, laws or no laws (last I knew, SpamCop was ready to "blacklist" anyone who even sets an "autoreply" while on vacation, which they were ranting against as being tantamount to "spam" when accidentally going to forged "sender" addresses). RFC4409 could have an "unintended side effect," however -- what if it influences new viruses to take over existing SMTP servers, to authorize only the spammer who paid the hacker who wrote the virus, locking out normal users, so that the spam traffic could not be slowed down by any unwanted legitimate mail still being sent from the co-opted server? :-) Thanks again, and best wishes. -- > Our manager was once staying at a hotel chain, where much to his surprise, > he was able to send outgoing email "right through our firewall," [quoted text clipped - 4 lines] > via a neat service to set itself apart from less savvy hoteliers, > and no doubt a profitable niche for the systems vendor, too. "Neat service", but not always desirable. For example, maybe I have my SMTP server set up to allow relaying for authorized users on port 25, so I can use it from anywhere in the world. And maybe I WANT to use my own server for some reason, rather than a server transparently provided by somebody else, maybe because I'm using SPF or domainkeys, so that all my outbound mail needs to be processed by my server. In this case, the "neat service" is not so neat. It is helpful to users whose laptops are set up to send through a server which may not allow connections from the hotel's network, but it is less than helpful to others. This is another good reason for port 587. Services which proxy port 25 are less likely to proxy 587, probably assuming that port 587 servers usually require authorization and will accept connections from anywhere. > [hotel proxying of SMTP is a] "neat service", but not always desirable. > [quoted text clipped - 7 lines] > may not allow connections from the hotel's network, but it is less than > helpful to others. I don't know whether the port 25 proxy can distinguish between authenticated and non-authenticated sessions, but certainly it is always fine to proxy non-authenticated sessions, because if the intended remote server is not authenticating and is not blocked by a firewall, then it is an "open relay," and is already putting its operator in jeopardy :) > This is another good reason for port 587. Services which proxy port 25 > are less likely to proxy 587, probably assuming that port 587 servers > usually require authorization and will accept connections from anywhere. It's entirely possible that the hotel was proxying only port 25; our manager was unlikely to be able to know, however, since we don't yet have anything on port 587, so he was configured to use our (unauthenticated) port 25 SMTP, and it was indeed good for that to have been proxied for him. Thank you for bringing our the point about SPF and DomainKeys, which authenticates the legitimacy of a sender's address, by whether its domain's SMTP server has "signed" the message; thus only the domain's "home" server can sign it properly. The latter is itself a problem for some people. For example, we want our professors who teach in China to use our domain's name, but several of them are not carrying their own computers with them, and prefer to send their mail using Gmail, with the "From" address of our domain, which is desirable to us; however, any too-fussy system which rejects via DomainKeys would make this impossible, so we haven't yet published that info in our own DNS, as it could actually harm some of our efforts. -- > I don't know whether the port 25 proxy can distinguish > between authenticated and non-authenticated sessions, Not likely, as proxy setup usually takes place as soon as the connection request is made, and there's no way to know at that point that authentication is going to take place. It might be possible, but probably difficult, for the proxy server to switch the connection back to the originally requested server if it sees an authentication request. But any intelligent authentication scheme is going to insist on an SSL session before the auth dialog takes place, and that woiuld be tough to proxy. > but certainly it is always fine to proxy non-authenticated sessions, > because if the intended remote server is not authenticating > and is not blocked by a firewall, then it is an "open relay," > and is already putting its operator in jeopardy :) Not necessarily. There are various schemes for temporarily authorizing a specific IP for relaying without SMTP authentication. One method is the "POP before SMTP" scheme. This requires the client to check his incoming email via POP before sending any mail. When the POP authentication takes place, the server remembers the IP for a short time, and allows unauthenticated SMTP relaying from that IP. There might be even kludgier systems in use. It would be awkward, but theoretically possible, for the road warrior to determine his IP and somehow have it manually added to a list of authorized relay clients. That's not really a good system, but just an example of why you can't assume that only a wide-open relay would be accepting unauthenticated SMTP connections from a hotel room. If you have the Esoteric Settings plugin enabled, you should have a "Personality Ports" pane in Eudora Preferences that allows you to set different POP/SMTP/IMAP ports for each personality. If you don't have the Personality Ports pane, you might need to install a separate Personality Ports plugin available from http://www.gjbrown.net/download/persports.sit Or, since different ports can be specified with a plugin, it's likely that the appropriate x-eudora-setting could be used without installing the plugin, but I've never tried that. Matt Simpson <net-news69@jmatt.net> wrote in news:net-news69- 580900.10062112102007@sn-radius.vsrv-sjc.supernews.net: > If you don't have the Personality Ports pane, you might need to install > a separate Personality Ports plugin available from > > http://www.gjbrown.net/download/persports.sit I didn't have this plugin installed by default but I did download it. Since I don't have access to the Mac until next week I will have to wait until then to try it. Thanks >> I have two personalities, each requires a different SMTP port and >> How can I set this up with Eudora Mac? > [quoted text clipped - 3 lines] > imbeciles, check "use submission port" in the personality settings > pane. Does the setting under 'Ports and Protocols' allow changing for each personality? It looks more like a global setting used by all personalities. > x-eudora-setting:7211@personalityname may indeed work I'll try this next week, then, when I have a chance to get to the Mac again. Thanks for your input. > >> I have two personalities, each requires a different SMTP port and > [quoted text clipped - 9 lines] > personality? It looks more like a global setting used by all > personalities. It is, but it is not used for personalities that are specifically set to use the submission port, 587. > > x-eudora-setting:7211@personalityname may indeed work > > I'll try this next week, then, when I have a chance to get to the Mac > again. > > Thanks for your input. SignatureNow where did I hide that website... Bill Cole <bill@scconsult.com> wrote in news:bill-FFFEC3.22171113102007 @news.det.sbcglobal.net: >> > x-eudora-setting:7211@personalityname may indeed work >> >> I'll try this next week, then, when I have a chance to get to the Mac >> again. I tried this and it does work. It can be used to set various settings for individual pesonalities. Certainly not the best documented feature I've ever come across, though. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.