Next: One Recipient per Transaction. Faked defer for other Recipients, Up: Circumventing the SMTP Limitatations [Contents][Index]
With this approach on each SMTP transaction the server accepts the email for the first recipient and defers it for all other recipients, that have different opinion on whether to accept the message from the first recipient. Deferring is done with a "451 4.5.3 Use PRDR or retry immediately, possibly in the same TCP connection, after DATA End of data; retry=0" message.
The 451 reply code means, that there is a temporary error and the client shall retry later.
The 4.5.3 Enhanced Status Code means more recipients were specified for the message than could have been delivered by the protocol. This error should normally result in the segmentation of the message into two, the remainder of the recipients to be delivered on a subsequent delivery attempt. [RFC3463, Section 3.6]. RFC 5248 adds, that 4.5.3 can only be used with ESC 451.
Note, that RFC 821 defines 452 reply code, as "Insufficient storage", which RFC 5821 repeats, but adds, that 452 can also mean "Too many recipients" and that a conforming server should be able to accept at least 100 receipients per iteration before returning 452.
The ideal answer would be "452 4.5.3", stating twice the same thing, but this combination is not allowed ber RFC 5248. If 452 is interpreted as "Insufficient storage now, after some time the server might have more place", then the client will impose some delay. On the other side, with "451 4.5.3" there are no indications for the client to impose a particular delay on the retry.
When the SMTP client retries, the message has one recipient less than the initial message. With this approach, a multi recipient message is split (segmented) into one message per recipient and on each iteration the message for the currently handled recipient can be accepted or rejected.
The advantage of this approach is, that the recipients preferences are matched exactly. As a side effect, if a deferred message arrives the second time, the anti-spam software can evaluate it the second time as likely spam, while the earlier evaluation of the same message, could have classified the message as unlikely spam.
The disadvantage of this approach is, that it delays the delivery of the message for all recipients but the first one. A message with many recipients can be delayed so much, that the SMTP client gives up retrying for some recipients.
The delayed delivery is not mitigated by inserting more than two IP addresses accepting SMTP connections. In its default configuration, in order to preserve resources, Postfix does try to deliver emails to up to two different IP addresses, and after the second try falls asleep. Courier MTA does try to deliver emails only up to one different IP address, before falling asleep.
The retry=0
hint means, that the client shall retry immediately. This is specified in SMTP Service Extension for Greylisting Operations. However, the specification does not say what to do with zero behind retry= and it is not known if there is some significant software implementing that internet draft. Moreover, the hint is defined to be only useful with the GREYLIST service extension and aegee-milter does not take care to announce support for it. Nevertheless adding retry=0
does not harm.