| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
552, as described in draft-ietf-drums-smtpupd-11.txt:
[RFC-821] incorrectly listed the error where an SMTP server exhausts
its implementation limit on the number of RCPT commands ("too many
recipients") as having reply code 552. The correct reply code for this
condition is 452. Clients SHOULD treat a 552 code in this case as a
temporary, rather than permanent failure so the logic below works.
Handle code 552 as a temporary failure.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically,
process(): move smptlib.SMTP() into the try/except so that
socket.errors on the connection can be flagged and dealt with as total
delivery failures.
Better error logging.
If the connection goes through but smtplib throws an
SMTPRecipientsRefused exception, then Only persistent transient
failures are queued, i.e. those with error code < 500. For failed
recipients with codes >= 500, these are permanent failures and we
do a bounce registration instead.
queue_message(): handles all the actual queuing of files for future
re-delivery attempts. Two files per message are written to
$prefix/qfiles: one is a .txt containing the full text of the message,
the other is a .db file containing a marshal of this information:
listname - Python string naming the list for delivery
recips - Python list of addr strings
attepts - number of total delivery attempts for this queued message
last_recip_count - number of recips the last time this delivery
was re-tried (not sure how useful that will
be).
The base name of the two files is the SHA hexdigest hash of the
message text.
|
| | |
|
| |
|
|
| |
"MAIL FROM" should be the list administrator email address.
|
| |
|
|
|
|
| |
Also, if we get refused recipients but the error code is >= 500, do
some logging. As Harald points out, we really need to handle
non-permanent failures better.
|
| | |
|
|
|
it queue messages. It registers bounces only for SMTP error codes >=
500, although errors never seem to occur with sendmail when not doing
DSN -- probably because such deliveries are asynchronous.
|