[Twisted-Python] SMTP client patch

Glyph Lefkowitz glyph at twistedmatrix.com
Thu Feb 20 23:37:08 EST 2003

Hash: SHA1

On Thursday, February 20, 2003, at 06:29 PM, Anders Hammarquist wrote:

> In a message of Thu, 20 Feb 2003 16:14:31 CST, Glyph Lefkowitz writes:
>> I had a look at this patch with Itamar today.  We like where you're
>> going, but here are a few issues:
>> 1. it's not backwards compatible.  DocmaServer uses its own sendEmail,
>> which depends on the sentEmail callback's signature.
> Yes, I know. The changes were needed to be able to get complete
> status for the message delivery. With the old code there was no
> way to find out what happend to failed recipient addresses. I
> suppose I could add logic to try and detect an old-style sentEmail.

Hmm... if you do that (with inspect or somesuch) please make sure to 
spit out an ugly warning so that people will know to fix their code.  
We shouldn't be supporting that long-term.

>> I personally would like to see Twisted's sendEmail deprecated and
>> replaced with an admonishment to use the 'email' module ;), so it 
>> would
>> be nice if you could re-implement sendEmail in terms of your  
>> MIME-less
>> 'sendmail' function.
> As in using sendmail plus the email module? Sure, will do.

Actually I'd prefer the existing code not to be changed, but to spit 
out a warning, since the interface ought to be "just pass a Message", 
not "pass a bunch of crap that gets turned into a Message".  
Considering how easy it is to turn a Message object into a long string, 
I don't think a separate method is required for this...

As long as it's still maintained, though, the existing code should 
remain in place rather than dragging a new dependency in for use with 
2.1 (since 'email' is only in the stdlib since 2.2)

>> 2. Those change to LineReceiver made no sense to us.  Care to explain?
> Somewhere in the docs I read that returning (as opposed to raising)
> an exception will land you in Factory.clientConnectionFailed with
> that exception (wrapped in a failure). However, LineReceiver didn't
> propagate the returned exceptions up to Protocol, so it didn't work
> without those changes. smtpConnectionFailed and smtpTransferFailed
> uses this.

Hmm.  Well, in any event I guess this is a more useful return value in 
general, and doesn't break anything.

>> 3. What's up with the SMTP logger?  and logging every line in the
>> client?  This is duplicated generic code, and should probably be
>> refactored into someplace more appropriate, like twisted.python.log.
> I agree that it may be useful elsewhere (though expect it's use
> will be rather limited). The purpose keeping the log is for
> generating bounce messages (i.e. as sendmail says:

aah, this makes a little more sense.

> ). My first look at t.p.log suggested not using it, since it dealt
> mostly with syslog()-like logging.

You're right.  Given this use-case though, it sounds like you need 
little more beyond cStringIO...?

> I'll have another look to see if it fits with those logging functions, 
> else I'll just rename it to something more generic and let it live in 
> t.p.log.

t.p.log might not be the best place to put it, come to think of it, 
since your impression of 'something like syslog' is correct.  But 
somewhere in t.p in general.
Version: GnuPG v1.2.1 (Darwin)


More information about the Twisted-Python mailing list