*> 5. Don't allow multiple RCPT TO's for unknown senders.
*> The problem is that you can't selectively NACK later RCTP TO's. The
*> sending MTA then decides that the entire message was NACK'd, and
*> discards (or retries) it.
If the MTA is behaving that way it is seriously broken. The behaviour
as you describe only happens if you NACK the "DATA" command after the
CRLF.CRLF (RFC 2821 4.2.5 Reply Codes After DATA and the Subsequent
<CRLF>.<CRLF>)
RFC821 was broken on this point I think? A 552 is suggested for too many
recipients, but this would imply a permanent failure for the message? I
guess that this might account for some interoperability issues :-)
Our mailserver doesn't allow more than 5 RCPT TO per session. The others
are answered with a temp failure (4xx code). This works without any
problems for years.
Of course, but this policy violates RFCs - what happened to the 100 RCPT
requirement? I'd be happy to see this kind of behavior written up in some
way - revising rfc2821. There's a whole lot of things that work better if
this requirement can be ignored.
--
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg