This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
| Author | jamesh |
|---|---|
| Recipients | fenner, gvanrossum, jamesh |
| Date | 2008年01月12日.13:46:35 |
| SpamBayes Score | 0.06467241 |
| Marked as misclassified | No |
| Message-id | <1200145602.09.0.980000347181.issue1339@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
From RFC 2487 section 5.2: "The client MUST discard any knowledge obtained from the server, such as the list of SMTP service extensions, which was not obtained from the TLS negotiation itself. The client SHOULD send an EHLO command as the first command after a successful TLS negotiation." So the starttls() method should probably also be clearing helo_resp and ehlo_resp (and maybe anything else discovered by ehlo()). There are servers in the wild that will (a) refuse to talk to you unless you issue another EHLO after TLS is negotiated and (b) offer a different set of ESMTP features (such as only supporting SMTP AUTH after TLS). This patch isn't enough to talk to such servers. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年01月12日 13:46:42 | jamesh | set | spambayes_score: 0.0646724 -> 0.06467241 recipients: + jamesh, gvanrossum, fenner |
| 2008年01月12日 13:46:42 | jamesh | set | spambayes_score: 0.0646724 -> 0.0646724 messageid: <1200145602.09.0.980000347181.issue1339@psf.upfronthosting.co.za> |
| 2008年01月12日 13:46:35 | jamesh | link | issue1339 messages |
| 2008年01月12日 13:46:35 | jamesh | create | |