Re: TCP Connect code for SMTP transaction
This WebDNA talk-list message is from 2004
It keeps the original formatting.
numero = 57631
interpreted = N
texte = Colin Sidwell wrote: > The emailer component of WebDNA 6 then processes the text files and connects > to the specified mail server. That is to say, the e-mail server that you have keyed into the WebCatalog Email Preferences, right? That is the server that will actually deliver the message and will handle any bounced messages (potentially, see below). > > However, if the recipient address is bad, e.g. bad.user@good-domain.com you > do not get any notice of the failure back as I used to in OS9/Web*/SIMS And you still won't, since you are handing off actual delivery to the OSX sendmail program (not to be confused with the [sendmail] context). With OS9/etc, WebCatalog didn't have a real SMTP server available, so most people used SIMS, where the [sendmail] context wrote text files and SIMS transmitted the message. You could get immediate feedback. You now have 3 layers ([sendmail], WebCat email, sendmail), where you used to have 2. And because you have that extra layer in place, you will not get an immediate feedback if an address is wrong (see below for more details). > I take your point about waiting for the SMTP response but I've already > determined that I can use- > Yes, you /can/ write a SMTP client using multiple pages, but my larger point is that you shouldn't, because you _won't_ get it right. I know a lot more about SMTP protocol than the average bear, yet I would never write a SMTP client. I don't mean to rag on you, but you are clearly not seeing the big picture here (my fault I'm sure ;). It is also not going to help you because you are still going to be at least one hop away from being able to directly know the message has failed in those cases where the message will immediately bounce. Here's a rough description of how SMTP works. MTA is Mail Transfer Agent, which is the server process which queues mail and attempts to send it onwards. MTA's are the processes responsible for checking the MX (Mail eXchange) record in DNS to see what remote MTA will accept mail for a given domain (see below). 1. SMTP Client - sends email via hardcoded address for MTA 2. MTA - receives message from SMTP client 3. MTA - looks up MX record for domain 4. MTA -> Remote MTA - if doesn't connect immediately will queue for later delivery Now, in WebCat terms: [sendmail] context writes a text file and then the emailer app then transmits the message to the configured SMTP server (this step consitutes the SMTP Client in step 1). That server process (probably sendmail under OS/X) now attempts to send the message on to the next hop (step 2-4). The reason I broke things out above is that in step 3, there might be multiple MX records (usually at least two and potentially many more) that will accept mail for a domain. Often, those MX records will point to servers which will accept the message, but those servers will then turn around and send the message to some other server for actual delivery. Sometimes those secondary MX servers are not smart and just accept any message for a given domain and rely on the final server to actually check to see if the account is valid. Hence, you cannot assume that a sucessful SMTP session means the e-mail address is correct. And you cannot assume that you will get an immediate response back if a message cannot be delivered, because there could be several machines involved before the message delivery is actually checked. The correct way to handle this is to make sure that the FROM: address is valid and can receive bounce messages. These may come 48-72 hours after the initial message is sent (depending on timeouts). HTH John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748 ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list
. To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Associated Messages, from the most recent to the oldest:
Colin Sidwell wrote: > The emailer component of WebDNA 6 then processes the text files and connects > to the specified mail server. That is to say, the e-mail server that you have keyed into the WebCatalog Email Preferences, right? That is the server that will actually deliver the message and will handle any bounced messages (potentially, see below). > > However, if the recipient address is bad, e.g. bad.user@good-domain.com you > do not get any notice of the failure back as I used to in OS9/Web*/SIMS And you still won't, since you are handing off actual delivery to the OSX sendmail program (not to be confused with the [sendmail] context). With OS9/etc, WebCatalog didn't have a real SMTP server available, so most people used SIMS, where the [sendmail] context wrote text files and SIMS transmitted the message. You could get immediate feedback. You now have 3 layers ([sendmail], WebCat email, sendmail), where you used to have 2. And because you have that extra layer in place, you will not get an immediate feedback if an address is wrong (see below for more details). > I take your point about waiting for the SMTP response but I've already > determined that I can use- > Yes, you /can/ write a SMTP client using multiple pages, but my larger point is that you shouldn't, because you _won't_ get it right. I know a lot more about SMTP protocol than the average bear, yet I would never write a SMTP client. I don't mean to rag on you, but you are clearly not seeing the big picture here (my fault I'm sure ;). It is also not going to help you because you are still going to be at least one hop away from being able to directly know the message has failed in those cases where the message will immediately bounce. Here's a rough description of how SMTP works. MTA is Mail Transfer Agent, which is the server process which queues mail and attempts to send it onwards. MTA's are the processes responsible for checking the MX (Mail eXchange) record in DNS to see what remote MTA will accept mail for a given domain (see below). 1. SMTP Client - sends email via hardcoded address for MTA 2. MTA - receives message from SMTP client 3. MTA - looks up MX record for domain 4. MTA -> Remote MTA - if doesn't connect immediately will queue for later delivery Now, in WebCat terms: [sendmail] context writes a text file and then the emailer app then transmits the message to the configured SMTP server (this step consitutes the SMTP Client in step 1). That server process (probably sendmail under OS/X) now attempts to send the message on to the next hop (step 2-4). The reason I broke things out above is that in step 3, there might be multiple MX records (usually at least two and potentially many more) that will accept mail for a domain. Often, those MX records will point to servers which will accept the message, but those servers will then turn around and send the message to some other server for actual delivery. Sometimes those secondary MX servers are not smart and just accept any message for a given domain and rely on the final server to actually check to see if the account is valid. Hence, you cannot assume that a sucessful SMTP session means the e-mail address is correct. And you cannot assume that you will get an immediate response back if a message cannot be delivered, because there could be several machines involved before the message delivery is actually checked. The correct way to handle this is to make sure that the FROM: address is valid and can receive bounce messages. These may come 48-72 hours after the initial message is sent (depending on timeouts). HTH John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748 ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
John Peacock
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
WebCat for mass emailings (1997)
[WebDNA] 3-5 GB of native WebDNA db in RAM?, else MySQL w/WebDNA (2009)
emailer setup (1997)
Emailer setup (1997)
problems with 2 tags shakur (1997)
WCS Newbie question (1997)
emailer (1997)
Loop into field (1998)
Extended [ConvertChars] (1997)
Typhoon Rev. and PCS store problems (1999)
tracking variables across a site... (2000)
carriage returns in data (1997)
Include a big block of text (1997)
Does ".tpl" index with SE's? (2003)
Color options for items (1999)
hard carriage returns and sendmail (1998)
Re:HELP - NONE STOP DIGESTS. Digest for 4/24/97) (1997)
File Upload, Browser Timeout (2003)
using showpage and showcart commands (1996)
Searching the same field with 2 form variables. (2000)