Smtplib module

[Barry A. Warsaw]

>>>>> "GH" == Gerhard Häring <gh_pythonlist at gmx.de> writes:

    GH> you're of course right. My thinking was too complicated,
    GH> again. But you'll only recognize if the local delivery to the
    GH> mail server failed, not when relayed mail's delivery fails. I
    GH> did never find the local failures particularly interesting,
    GH> because I usually know which users exist on my SMTP server in
    GH> advance.

    GH> I was thinking about the general problem of finding out if an
    GH> email address exists and if mails get delivered. This is of
    GH> course much more complex, and AFAIK not solvable in the
    GH> general case.

If you want to find out whether an email has been read, you can try
setting the Return-Receipt-To: header, but this confirmation will
happen asynchronously to the SMTP transaction, and requires
cooperation with the recipient's mail reader (MUA).  There are a few
other headers that are MUA specific, including X-Confirm-Reading-To:
and X-pmrqc <!>.

As for error messages during the SMTP transaction, it all depends on
whether you're talking to a local smtpd which does the final delivery,
or you're talking to a remote smtpd on the MX of the recipient.  In
the former case, you likely won't get anything other than an immediate
successful return, unless there's some misconfiguration or other
problem with your local MTA.  Some MTAs also have a "synchronous" mode
where your smtplib.py client talks to your local MTA, and it doesn't
return until it's talked to the intended remote MTA.  Then sometimes
any error condition the remote receives will be forwarded to your
local MTA, which forwards the error to your smtplib.py client.  A huge
downside with this approach is that it'll take you a long time to work
through a big list of recipients since any slow remote MTAs will clog
the whole works.

You could also connect to the remote MTA yourself directly via
smtplib.py, but then you've got similar problems as the synchronous
approach above.  Then again, you could do some asyncore (select-based)
or thread-based approach to mitigate any per-address delays.  Once
you've gone down that route though, you're 1/2 way to writing your own
Python based MTA <wink>.

For asynchronous deliveries, you're stuck doing VERP or bounce
parsing.  For the latter, take a look at Mailman's recipes, which
could be split out without too much work.  Mailman will eventually
support VERP, but it requires cooperation with your receiving MTA, so
I'm not sure it'll make it into MM2.1.

clear-as-fog-ly y'rs,
-Barry