On Tue, 2004-08-24 at 17:34, Jim Lyon wrote:
Regarding generation of bounces vs. rejecting mail at SMTP time, John
Glube raises a number of issues:
* Your position presumes wide spread implementation of
Submitter, allowing for extraction of the PRD at the data
stage.
No. SUBMITTER allows you to reject the message at MAIL command time.
Without SUMBMITTER, you can extract the PRD during receipt of the
message, and reject the message and end-of-data time.
No: Without SUBMITTER, you still might have to bounce, (not reject)
messages after end-of-data time. This can happen if one recipient has
white-listed the PRA, but another recipient hasn't.
If the MTA server were given a SUBMITTER parameter, it could have done
per-user rejects at RCPT TO: time, and avoided the need for bounces
altogether.
However, if the MTA server isn't given a SUBMITTER parameter, then
differences between recipient white-listings can cause the MTA to have
to accept the message and then generate bounces for the non-white-listed
recipients.
The only potential solutions I can see are:
1. Unified SPF, so that MAIL FROM is always checks: This is only a
partial solution unfortunately. It can only filter out some forged
Return-Path's.
2. An SMTP extension to do per-user after-data rejects: This would be
a great extension, but until almost everyone uses it we couldn't
require it.
3. In the case of differing per-recipient white-lists, rejecting all
recipients from the first contrary one onwards with a "too many
recipients" transient error.
This violates RFC 2821, as you're supposed to always be able to
accept at least 100 recipients, but I think it might be the only
sure-fire solution that can handle this problem, and that doesn't
assume the rest of the world upgrades to newer SMTP extensions.
I think choice #3 is the only viable choice. It's ugly, but it's the
only thing that can really prevent this bounce-generation problem.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com