Re: TCP Connect code for SMTP transaction
This WebDNA talk-list message is from 2004
It keeps the original formatting.
numero = 57634
interpreted = N
texte = Hi, Thanks for your detailed reply. I should have said that I only want to connect to one mail server, our own running EIMS 3.15, I would not be foolish enough to try and write the whole thing including the MX lookups. EIMS can then do all the tricky bit like MX lookups and queuing. It will also do the bouncing of duff messages and I'll get replies back if that is the case. Regards, Colin Colin Sidwell 01905 797383 ------------------------------- http://www.idealinternet.co.uk ------------------------------- > From: John Peacock
> Reply-To: (WebDNA Talk) > Date: Tue, 04 May 2004 11:48:36 -0400 > To: (WebDNA Talk) > Subject: Re: TCP Connect code for SMTP transaction > > 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/ ------------------------------------------------------------- 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:
Hi, Thanks for your detailed reply. I should have said that I only want to connect to one mail server, our own running EIMS 3.15, I would not be foolish enough to try and write the whole thing including the MX lookups. EIMS can then do all the tricky bit like MX lookups and queuing. It will also do the bouncing of duff messages and I'll get replies back if that is the case. Regards, Colin Colin Sidwell 01905 797383 ------------------------------- http://www.idealinternet.co.uk ------------------------------- > From: John Peacock > Reply-To: (WebDNA Talk) > Date: Tue, 04 May 2004 11:48:36 -0400 > To: (WebDNA Talk) > Subject: Re: TCP Connect code for SMTP transaction > > 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/ ------------------------------------------------------------- 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/
Colin Sidwell
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:
2nd WebCatalog2 Feature Request (1996)
I give up!! (1997)
merchant accts. (1997)
Blog solution (2006)
More on the email templates (1997)
Doctype (2004)
WebCatalog can't find database (1997)
[shownext] (1998)
How to delete all files in a folder? (2001)
HELP WITH DATES (1997)
NT BETA BUG???? (1997)
Summing fields (1997)
Interfacing WebMerchant to www.fedex.com (1997)
Multiple Purchase (2002)
show me your store ! (2003)
form crasehes server (1997)
[OT] ImageMagick error (2004)
RE: Multithreading of [replace] (1999)
LOOKUP and Math operations (2001)
[WebDNA] db admin tool (2008)