Can someone tell why my e-mails are arriving anywhere from eight (8) hours to an entire day later to recipients when using the DoCmd.SendObject method (MS Access) ? The e-mail providers are Comcast and gmail (i.e. Comcast.net and Gmail.com).
E-mail Late Arrival Using DoCmd.SendObject Method (1 Viewer)
- Thread starter lhooker
- Start date
- Local time
- Today, 04:15
- Joined
- Feb 28, 2001
- Messages
- 27,186
You say the mail in question is arriving "later" to recipients. Later than what? What is your comparison? Do you have a mail client that is faster when you run it through some other command interface?
SMTP usually involves sending mail through a gateway server. (Your servers are xxx...Comcast.net and xxx...Gmail.com, where the "xxx..." represents unknown server paths under the parent domains.) But the Access DoCmd.SendObject command wants to go through the Windows MAPI interface, which means you are using one or the other of the mail clients associated with MAPI on your machine. And those would be the mail clients for COMCAST or GMAIL.
I believe it is possible that you have an improper configuration for the mail clients, which might cause delays. The real test, if you HAVE a GUI-based interface, is that you might wish to see what is in your "outgoing" and "sent" boxes. If you send an e-mail and immediately check for the mail to have reached the "outgoing" or "sent" box, you will know if you have a transmission issue. I will say this: Once the mail message is in the SENT box, you can do nothing else. It is out of your hands
Therefore, endeavor to perform that test quickly. In fact, if you "normalize" the windows so that you can have your mail client in one panel and your Access app in another, both being visible, you could watch as the message appears in the OUTGOING box and shifts to the SENT box. That process should take seconds from "app creates" to "appearance in the OUTGOING box." The delay of entering the SENT box is where you might have issues in the timing and tuning of your primary mail client.
SMTP usually involves sending mail through a gateway server. (Your servers are xxx...Comcast.net and xxx...Gmail.com, where the "xxx..." represents unknown server paths under the parent domains.) But the Access DoCmd.SendObject command wants to go through the Windows MAPI interface, which means you are using one or the other of the mail clients associated with MAPI on your machine. And those would be the mail clients for COMCAST or GMAIL.
I believe it is possible that you have an improper configuration for the mail clients, which might cause delays. The real test, if you HAVE a GUI-based interface, is that you might wish to see what is in your "outgoing" and "sent" boxes. If you send an e-mail and immediately check for the mail to have reached the "outgoing" or "sent" box, you will know if you have a transmission issue. I will say this: Once the mail message is in the SENT box, you can do nothing else. It is out of your hands
Therefore, endeavor to perform that test quickly. In fact, if you "normalize" the windows so that you can have your mail client in one panel and your Access app in another, both being visible, you could watch as the message appears in the OUTGOING box and shifts to the SENT box. That process should take seconds from "app creates" to "appearance in the OUTGOING box." The delay of entering the SENT box is where you might have issues in the timing and tuning of your primary mail client.
I'm expecting the sent MS Access e-mail to arrive at the destination within minutes, rather
than hours or day(s). I'm using the standard e-mail services for a typical user.
The sent MS Access e-mail never shows up in my Comcast.net or Gmail.com 'Outgoing' or 'Sent'
folders, while watching for a few minutes.
than hours or day(s). I'm using the standard e-mail services for a typical user.
The sent MS Access e-mail never shows up in my Comcast.net or Gmail.com 'Outgoing' or 'Sent'
folders, while watching for a few minutes.
GPGeorge
Grover Park George
- Local time
- Today, 02:15
- Joined
- Nov 25, 2004
- Messages
- 1,867
It is possible there is some server-level filtering going on. I've had email bounce back after more than 24 hours. I've had email sit in a queue on a recipient's email server, apparently some sort of AV scanning was going on.
Isaac
Lifelong Learner
- Local time
- Today, 02:15
- Joined
- Mar 14, 2017
- Messages
- 8,777
If I'm not mistaken recall correctly, doesn't DoCmd.SendObject essentially just automate your local default mail client?
If so, the question isn't really about SendObject; it queues up a message to send immediately. It's more about all the other cogs in the gears.
You could probably mimic an email using the same subject and attachment and body and the behavior will likely be the same.
'Why' will likely be next to impossible to answer. My wife's gmail seems to always take about 15 min to get anything. Mine takes seconds. Why? I dunno ... maybe someday we can ask Google!
If so, the question isn't really about SendObject; it queues up a message to send immediately. It's more about all the other cogs in the gears.
You could probably mimic an email using the same subject and attachment and body and the behavior will likely be the same.
'Why' will likely be next to impossible to answer. My wife's gmail seems to always take about 15 min to get anything. Mine takes seconds. Why? I dunno ... maybe someday we can ask Google!
- Local time
- Today, 04:15
- Joined
- Feb 28, 2001
- Messages
- 27,186
E-mail interchange is one of the older networking protocols. How it sends something is... and is not... always the same.
The "always the same" part is that you build a message with some number of elements (attachments, text body, etc.) and create an SMTP "capsule" which you then commit to an SMTP gateway. That transmission is more or less direct from your workstation to the gateway server because most businesses use internal routers that do not store and forward, they just act as a switching network. However, at the gateway, that "capsule" is stored in the gateway server, place in a message queue that gets sent along towards its destination.
The "not always the same" is that your service provider's gateway has some number of routing entries in the ROUTES table inside of the network components. However, there is no guarantee where those entries direct the message. Even with a U.S. Navy mainframe system, my main system's route tables had 20+ entries because of all the agencies with which we exchanged data. Sometimes routes are chosen for speed but sometimes they are chosen for security or reliability.
Each route identifies another server to which mail can be forwarded. At each hop, it is again placed into a queue (stored) until the next step in the process. The next steps along the route don't have to be SMTP servers as long as they conform to "store and forward" standards. In the case of "standard" Outlook, the starting point is the Outlook mail client and the ending point is a mail service manager such as Exchange. All the hops in between depend on the routes for all the servers in between. And there is where differences emerge.
Not saying that anyone is trying to be evasive, but there are servers where if you send mail, they intentionally re-route your traffic through multiple relay servers as a means of obscuring your point of origin. And there are services where for any reason or no reason at all, they have limited networks that do not have a lot of choices for routes because they take a "regional" approach that routes you from region to region. My mainframe actually had the ability to act as a store/forward server and it had its own mail client. Every now and then I had to intervene in my own system's mail queue if its chosen destination was not responding due to network issues. Each message had a certain number of retries before it would be dropped back into the queue (at the rear) for later retransmission. It was possible that a message would hang there for three days before it would be returned as undeliverable. (Three days was a parameter, not hard-coded, for my system.)
Therefore, a delay in the message may well depend on how it is routed as well as whether there is a store/forward component that gets backlogged for some reason.
Having said that, the next question is whether the SendObject, which exercises MAPI system libraries, does the same thing as your interactive mail client program, which also normally exercises MAPI libraries. Normally, I would say that they would do so, but it is not a requirement.
The "always the same" part is that you build a message with some number of elements (attachments, text body, etc.) and create an SMTP "capsule" which you then commit to an SMTP gateway. That transmission is more or less direct from your workstation to the gateway server because most businesses use internal routers that do not store and forward, they just act as a switching network. However, at the gateway, that "capsule" is stored in the gateway server, place in a message queue that gets sent along towards its destination.
The "not always the same" is that your service provider's gateway has some number of routing entries in the ROUTES table inside of the network components. However, there is no guarantee where those entries direct the message. Even with a U.S. Navy mainframe system, my main system's route tables had 20+ entries because of all the agencies with which we exchanged data. Sometimes routes are chosen for speed but sometimes they are chosen for security or reliability.
Each route identifies another server to which mail can be forwarded. At each hop, it is again placed into a queue (stored) until the next step in the process. The next steps along the route don't have to be SMTP servers as long as they conform to "store and forward" standards. In the case of "standard" Outlook, the starting point is the Outlook mail client and the ending point is a mail service manager such as Exchange. All the hops in between depend on the routes for all the servers in between. And there is where differences emerge.
Not saying that anyone is trying to be evasive, but there are servers where if you send mail, they intentionally re-route your traffic through multiple relay servers as a means of obscuring your point of origin. And there are services where for any reason or no reason at all, they have limited networks that do not have a lot of choices for routes because they take a "regional" approach that routes you from region to region. My mainframe actually had the ability to act as a store/forward server and it had its own mail client. Every now and then I had to intervene in my own system's mail queue if its chosen destination was not responding due to network issues. Each message had a certain number of retries before it would be dropped back into the queue (at the rear) for later retransmission. It was possible that a message would hang there for three days before it would be returned as undeliverable. (Three days was a parameter, not hard-coded, for my system.)
Therefore, a delay in the message may well depend on how it is routed as well as whether there is a store/forward component that gets backlogged for some reason.
Having said that, the next question is whether the SendObject, which exercises MAPI system libraries, does the same thing as your interactive mail client program, which also normally exercises MAPI libraries. Normally, I would say that they would do so, but it is not a requirement.
