On 2009-01-20 12:45:20 -0500, der Mouse wrote:
[Assuming no config changes], there are at most three delivery
attempts:
This doesn't look right.
As I wrote, the actual algorithm is more complicated. If you are really
interested, you can get the perl source code from
http://www.hjp.at/projekte/qpsmtpd/cf_wrapper/. But I'll explain a
little more below.
1) The results of the content filters for the different recipients
don't agree. Use the results to split the recipients into two
sets.
2) All the recipients from set1 get 2xx reply to RCPT, all the
recipients from set2 get a 4xx reply. Now the results of the
content filters for all recipients agree (they are all from set1),
so we can reply with either 2xx or 5xx.
Right so far.
3) All the remaining recipients are now from set2,
Yes.
so the content filters agree again,
No - or rather, not necessarily, not unless you have only two possible
filtering setups. All we know about set2 is that their filtering
choices differ from those of set1.
Yup. So for this particular message (unless the setup has changed in the
mean time) if the result for set1 was "accept", for set2 it must be
"reject" and vice versa.
(If the setup does change, it can affect delivery attempt 2 just the
same as attempt 3 - if it does happen, new sets are created and a 4xx
reply is returned - theoretically that can continue until there is only
one recipient left)
We have no particular reason to think that set2 is uniform within
itself (unless, as I said, there are only two choices possible).
There are, if we are only interested acception/rejection of the message.
You cannot include specific messages, of course (currently I just
concatenate all the rejection reasons into a single message).
The real problem is in the phrase "this particular message". At the time
the server receives the first "RCPT TO:" command it has no way to
know that this is a new delivery attempt for a message which was
temporarily rejected earlier, much less which message (envid is
per-transaction, and you couldn't rely on the client sending it anyway).
So, as a weak approximation, I use sender/recipient pairs instead of
message/recipient pairs as elements of the sets. This works quite well
because a recipient usually wants to receive all messages from a
specific sender or none. But yes, theoretically it can happen that the
sets are split again and again until each recipient is in a set of their
own. In practice I haven't seen it yet (after more than 3 years, but
admittedly on a relatively small number of email addresses).
hp
--
_ | Peter J. Holzer | Openmoko has already embedded
|_|_) | Sysadmin WSR | voting system.
| | | hjp(_at_)hjp(_dot_)at | Named "If you want it -- write it"
__/ | http://www.hjp.at/ | -- Ilja O. on
community(_at_)lists(_dot_)openmoko(_dot_)org
signature.asc
Description: Digital signature
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg