3

I'm trying to send emails through sendmail, and preventing them from being queued. I only want the emails to be sent, which has been an extreme problem so far.

in both sendmail.cf, and submit.cf, I have this setting:

O QueueLA=99

In the mail log, it is written that the email in question is both sent and queued. Seriously, isn't that just awfully confusing?

Feb 10 17:04:34 nnn sendmail[27910]: r1AG4Q0V027910: to=vvv@someone.com, 
ctladdr=admin@vvv.se (33/33), delay=00:00:08, xdelay=00:00:04, 
mailer=relay, pri=30391, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, 
stat=Sent (r1AG4U09027911 Message accepted for delivery)

Feb 10 17:04:36 nnn sm-mta[27913]: r1AG4U09027911: to=<vvv@someone.com>, 
delay=00:00:06, xdelay=00:00:02, mailer=esmtp, pri=120589, 
relay=mail1.someone.com. [207.106.200.39], dsn=2.0.0, stat=Sent 
(Queued! 1360512372 qp 15149 <201302101604.r1AG4Q0V027910@mail.nnn.se>)
  1. At the point when this log is written, is the email sent or not?
  2. Is there any way to prevent this last queue?
Robin Manoli
  • 173
  • 2
  • 2
  • 7

3 Answers3

2

Why would you want to change this? This is exactly how sendmail is supposed to function. Sendmail, before confirming to the original sender that it has accepted mail, saves it in a queue on the hard drive. It then picks it up and keeps the physical copy until the next recipient confirms receipt. This is how sendmail makes sure mail isn't lost in the event of a hard system crash or if sendmail crashes itself. Sendmail also delays mail due to variety of reasons. Sometimes the other MTAs you don't control delay email (network issues, system loads, grey listing). It needs to safely store the mail somewhere.

Email is NOT a just in time delivery mechanism like IM. Wait the 2 seconds in normal circumstances.

You know it's sent when you see the other mail server with stat=Sent: relay=mail1.someone.com. [207.106.200.39], dsn=2.0.0, stat=Sent

chylarides
  • 81
  • 3
2

SMTP does not guarantee that the email will reach its destination; it's a best-effort delivery mechanism with no synchronous end-to-end feedback about the fate of your traffic. The server to which you are delivering mails must directly tell you whether it is accepting them for eventual delivery, but it needn't deliver them synchronously (it can store them for later and not tell you), and it needn't deliver them directly (the path has multiple hops). In practice, nearly all SMTP daemons queue mails.

Delivery and read receipts, which are not widely supported due to their abuse by spammers, were designed to overcome this limitation. Additionally, servers later down the line may, at their option, at some future time, send you a notification if they reject your message after the initial server to which you passed it accepted it, but are not required to.

Your application should treat the next hop's acceptance as a success case. This is the most reliable feedback SMTP will consistently give you.

Falcon Momot
  • 25,244
  • 15
  • 63
  • 92
2

After some research I found that the message in the parenthesis (Queued! 1360512372 qp 15149 <201302101604.r1AG4Q0V027910@mail.nnn.se>) is the message from the receiving server.

that means:

  1. yes the email is sent.
  2. no, as the message is queued on the receiving server.

Here is some explanation of how I could get my answer: freebsd 8 mail log status, what do these mean? some quotes from the answer that seemed reliable to me:

"The status entry of sent means the remote server accepted the message."

"The comments in the parentheses of a status entry is the reply given by the remote server when sending the email. It is useful for seeing why a message was rejected, deferred, or held."

Community
  • 1
Robin Manoli
  • 173
  • 2
  • 2
  • 7