>1. Does this mean that POP authentication in Emailer has been supplanted >by SMTP authentication? Or, to put it another way, if one chooses just to >POP mail without sending mail, will the POP authentication still go to >the POP server off the EmailAccount field after the "@" sign?
POP Auth now becomes needless. If your ISP offers that, great, it makes no difference. Each time Emailer sends an email (does a SMTP session), it will attempt to use SMTP Authentication. This All or Nothing issue only effects people that can't use SMTP Authentication with some of their email servers. If you can use it (even if you don't have to) with all your SMTP servers, then you are good to do. At this point, I'd be surprised to find there are servers out there that CAN'T use SMTP Authentication. There may still be many that don't *require* it (either because they can use POP Auth, or because they do some other form of authentication), but my guess would be, even those that don't require it, can still do it if someone tries. >>The auth routine pulls its data from the same place the POP ability >>does. > >2a. You mean "The [smtp] auth routine..."? Correct. >2b. Does the "same username and password" associated with the email >account mean the "EmailAddress" field has to be the same as an email >address associated with the smtp server listed in the "SMTP server" >field? It could care less what you have in the Email ADDRESS field. What matters is, whatever SMTP Server is in the SMTP field, must be able to accept an authentication attempt from the Username and password found in the SAME ACCOUNT'S Email Account (the part before the last @) and the Password field. So assuming no special or odd requirements from the ISP and Mail Servers, based on your following examples: >Example 1: >Email Account: [EMAIL PROTECTED] >Password: UsernameISP-Password >SMTP Server: SMTPserver.ISP.com >Email address: [EMAIL PROTECTED] Works >Example 2: >Email Account: [EMAIL PROTECTED] >Password: UsernameABC-Password >SMTP Server: SMTPserver.ISP.com >Email address: [EMAIL PROTECTED] Will not work >Example 3: >Email Account: [EMAIL PROTECTED] >Password: UsernameXYZ-Password >SMTP Server: SMTPserverXYZ.XYZ.com >Email address: [EMAIL PROTECTED] Works >Example 4: >Email Account: [EMAIL PROTECTED] >Password: UsernameISP-Password >SMTP Server: SMTPserver.ISP.com >Email address: [EMAIL PROTECTED] Works Again, that all assumes no special needs or issues with the mail servers. In reality, #1 and #3 should work fine, #2 *might* if the ISP and the ABC groups have some affiliation with each other and accept each other's users (as SBC and Yahoo I think do, because SBC outsources its email to the Yahoo group), and #4 should work UNLESS the ISP has a requirement that the mail sender match the authentication info (as Mac.com does). >3. Is there anything in what you did that might make Emailer send its >attachments more slowly than it did otherwise? I don't *think* so. There shouldn't be. Of course, I can't say anything for 100% sure, because I don't know all the nitty gritty details of Emailer, so I can't ever be 100% sure that any changes I did haven't cascaded into a failure somewhere else. But based on what I did, and what I do know, I don't see any reason my changes should effect your attachment upload speeds. (but hey, I didn't know any reason in the past why one of my Patches would stop someone from using their mail server, and it turned out it did... not because of a change I made, but because of a change the patcher made in inserting a new version string... so I won't say that I am NOT at fault... I'll just say that I don't *THINK* I am at fault). -chris <http://www.mythtech.net> ___________________________________________________________________________ To unsubscribe send a mail message with a SUBJECT line of "unsubscribe" to <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
