smtplib does not send to all recipients

[dccarson]

Here is a snippet of code which does not send to all recipients.
However, it also does not inform me of this error. My suspicion is
that this only fails for users with longer usernames. The two I seem
to regularly fail on have 9 and 11 characters respectively. Most users
have names <= 8 characters.

domain = "myDomainHere.c om"
admin = "d123456@%s " % domain
adminFull = "Full Name Here <%s>" % admin
def mailMsg(text, subject, sender, recipients):
# From: and To: headers at the start!
if not sender:
sender = adminFull
elif not sender.endswith (domain):
sender += ("@" + domain)
addresslist = []
for name in recipients:
if not name.endswith(d omain):
name += ("@" + domain)
addresslist.app end(name)
msg = "From: %s\r\nTo: %s\r\n" % (sender, ", ".join(addressl ist))
msg += "Subject: %s\r\n\r\n" % subject
for line in text.split('\n' ):
msg += "%s\r\n" % line.rstrip()

try:
server = smtplib.SMTP('l ocalhost')
server.set_debu glevel(0)
failures = server.sendmail (sender, recipients, msg)
if len(failures):
safeMailMsg("%s \n\n%s" % (failures, msg),
"ttLadder: sent with failures", [admin])
server.quit()
except smtplib.SMTPSen derRefused, sndErr:
safeMailMsg("%s \n\n%s" % (sndErr, msg),
"ttLadder: sender refused", [admin])
except smtplib.SMTPRec ipientsRefused, rcpErr:
safeMailMsg("%s \n\n%s" % (rcpErr, msg),
"ttLadder: recipients refused", [admin])
except Exception, xcp:
safeMailMsg("%s \n\n%s" % (xcp, msg),
"ttLadder: other exception", [admin])
return

The safeMailMsg() routine uses os.system("mail ..."). It works but it
is not sending me any error in this case.

When I test by sending the same mail to myself (7 characters) and a
long name (11 characters), I receive the e-mail but the other user does
not. However, the header in the mail looks correct and if I do a
"Reply-all" it will happily send the mail to both of us.

Is this a known problem with older versions of smtplib? I'm using
Python 2.2.2.

Thanks,
David

[dccarson]

I changed debuglevel to 1 and looked at the response on the recipient
names. They are BOTH accepted, but still only my id (d123456) receives
the e-mail. The long id (d1234567890) never gets the e-mail. Here is
the excerpt of the exchange.

send: 'mail FROM:<d1*****@m yDomainHere.com > size=160\r\n'
reply: '250 2.1.0 <d1*****@myDoma inHere.com>... Sender ok\r\n'
reply: retcode (250); Msg: 2.1.0 <d1*****@myDoma inHere.com>... Sender
ok
send: 'rcpt TO:<d123456>\r\ n'
reply: '250 2.1.5 <d123456>... Recipient ok\r\n'
reply: retcode (250); Msg: 2.1.5 <d123456>... Recipient ok
send: 'rcpt TO:<d1234567890 >\r\n'
reply: '250 2.1.5 <d1234567890>.. . Recipient ok\r\n'
reply: retcode (250); Msg: 2.1.5 <d1234567890>.. . Recipient ok

[Steve Holden]

dc******@gmail. com wrote:

I changed debuglevel to 1 and looked at the response on the recipient
names. They are BOTH accepted, but still only my id (d123456) receives
the e-mail. The long id (d1234567890) never gets the e-mail. Here is
the excerpt of the exchange.

send: 'mail FROM:<d1*****@m yDomainHere.com > size=160\r\n'
reply: '250 2.1.0 <d1*****@myDoma inHere.com>... Sender ok\r\n'
reply: retcode (250); Msg: 2.1.0 <d1*****@myDoma inHere.com>... Sender
ok
send: 'rcpt TO:<d123456>\r\ n'
reply: '250 2.1.5 <d123456>... Recipient ok\r\n'
reply: retcode (250); Msg: 2.1.5 <d123456>... Recipient ok
send: 'rcpt TO:<d1234567890 >\r\n'
reply: '250 2.1.5 <d1234567890>.. . Recipient ok\r\n'
reply: retcode (250); Msg: 2.1.5 <d1234567890>.. . Recipient ok

In which case the Python is working perfectly correctly and you need to
take the matter up with whoever runs the SMTP server. Are you sure the
address is actually valid?

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/

[Skip Montanaro]

dccarson> I changed debuglevel to 1 and looked at the response on the
dccarson> recipient names. They are BOTH accepted, but still only my id
dccarson> (d123456) receives the e-mail. The long id (d1234567890)
dccarson> never gets the e-mail. Here is the excerpt of the exchange.

...
dccarson> reply: '250 2.1.5 <d123456>... Recipient ok\r\n'
...
dccarson> reply: '250 2.1.5 <d1234567890>.. . Recipient ok\r\n'

Sorta makes it look like it's not an smtplib problem, doesn't it? ;-)

Skip

[dccarson]

That seems reasonable. However, using the 'mail' utility I can deliver
the same mail successfully. I assume mail is using sendmail under the
covers, which is doing the same negotiation with the same SMTP server?

[Steve Holden]

dc******@gmail. com wrote:

That seems reasonable. However, using the 'mail' utility I can deliver
the same mail successfully. I assume mail is using sendmail under the
covers, which is doing the same negotiation with the same SMTP server?
The facts would appear to suggest that both sources are accepted by the
local SMTP server - as long as you are positive both chains are indeed
contacting the same server. Ethereal could show you this.

A possible scenario would be that the downstream SMTP chain is somehow
discriminating against the Python-originated messages. Logs should give
evidence here.

So, unless it's a simple typo and you are using different (email or SMTP
server) addresses that you think are the same, see my original response,
which included
and you need to take the matter up with whoever runs the SMTP server. Are you sure the address is actually valid?

Evidence for and against? These things are a pain, but with patience you
can usually track them down. You could try explaining to a stuffed toy,
or a sock on your hand, exactly why there can't be anything wrong with
your code. My wife's bears are very forbearing [n.p.i.]. Whatever it
takes to break the perceptual barrier.

We now return you to your regular episode of scheduled tasks ...

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/

[dccarson]

OK, I've discovered the lost messages, but I'm still slightly confused
as to why they ended up there. The messages were being delivered to
the local machine, box1.domain.com , even though I was addressing them
to <user>@domain.c om.

My past experience with smtp mail has been that if I addressed the
domain explicitly, the mail would not stop at the local machine. This
is in fact why the 'mail' utility is working. If I use 'mail' to mail
something to <user> with no domain, it goes to the local machine, as I
would expect, but addressed to <user>@domain.c om, it goes to the
corporate server.

So why does smtplib deliver to box1.domain.com ? If the local smtp at
box1.domain.com is configured such that this is correct behavior, I
guess I'd expect the 'mail' utility to do the same thing when handling
address <user>@domain.c om.

By the way, the long vs. short usernames was a red herring. Those with
..forward files were getting their mail.

[Peter Hansen]

dc******@gmail. com wrote:

OK, I've discovered the lost messages, but I'm still slightly confused
as to why they ended up there. The messages were being delivered to
the local machine, box1.domain.com , even though I was addressing them
to <user>@domain.c om.

The address is irrelevant with SMTP. What matters is
what server you connect to, and how it is configured
to handle the envelope you give it.

Mail forwarders ought to query a DNS for the "MX"
record (on Linux, "dig domain.com mx" for that info)
and forward the mail to one of the specified mail
exchangers for that domain, regardless of what
server you actually connected to for the initial
delivery.

Not sure this is relevant in your case, but it seems
a likely candidate, since smtplib.py does not (and
should not) be looking up MX records for you, as far
as I know, while the "mail" utility might.

-Peter

[Peter Hansen]

Peter Hansen wrote:

dc******@gmail. com wrote:

OK, I've discovered the lost messages, but I'm still slightly confused
as to why they ended up there. The messages were being delivered to
the local machine, box1.domain.com , even though I was addressing them
to <user>@domain.c om.

The address is irrelevant with SMTP. What matters is

Well, that statement by itself is pretty silly... :-(

I hope you got my point from the rest of the post.

-Peter