On Mon, 30 Aug 2004 23:38:01 -0400, Mark Shewmaker
<mark(_at_)primefactor(_dot_)com> wrote:
- The ultimate determination as to per-recipient deliverability
cannot be made until after the SMTP transaction accepts the
message for delivery.
The last condition is not quite correct, because you can make the
determination before replying to the "." at the end of the DATA
command.
Not an ultimate per-recipient determination, unless the answer is
reject-for-everyone.
Ah, I see the confusion. By "make the determination", I read decide
whether or not each recipient wants to accept the mail. I think what
you meant is notify the client of whatever that decision is.
Basically imagine the following session:
==> rcpt to:<a(_at_)host(_dot_)com>
<== 250 ok
==> rcpt to:<b(_at_)host(_dot_)com>
<== 250 ok
==> data
<== 354
==> [mail message]
==> .
Now the MTA has to decide what to reply to the "." at the end of the
data command. At this point, even though the SMTP transaction is not
yet complete (still awaiting a reply from the MTA), the MTA has the
entire message body, and thus can certainly determine that user a
wants the mail, and user b doesn't want the mail. The determination
is made before the end of the SMTP transaction. The problem is there
is no way to notify the client.
So I think it's clearer to say you can't determine per-recipient
deliverability at the time of the RCPT command, and even if you can
determine it during the DATA command, without another SMTP extension
it is not possible to reject the message for a subset of recipients.
In fact, while I don't fully understand the motivation for having
different PRA and MAIL-FROM addresses, I gather from previous messages
that the people who want this the most are large banks that send out
bulk mail.
Somewhat off-topic, but here's one reason: There are some legal
requirements to send some EFT notifications, (and things like those
yearly account-rules-and-conditions-and-information things), that can be
satisfied by emails if you then send paper documents if the email
bounces. I can see where companies might want to outsource the sending
of notifications like this, trusting the outsourced sender to notify
them of rejects, but yet possibly wanting to handle the bounce
processing separately. (Or perhaps the outsourced company might want to
do that--having a bounce-handling machine that is set up to handle
bounces for a week after the mail is sent, which might be long after the
originating machine knows anything about the bulk mail sending session.)
Sorry, I know this is a bit off topic, but I really wish I understood
this point better. I understand that the bank and the sender are two
different institutions. I also understand that whatever part of the
mail is authenticated should end with "bank.com", so that MUAs can
display a golden padlock or somesuch. What do you mean by "handling
bounce processing separately"? Presumably this is the major function
of the outsourced sender, so the sender is getting the bounces.
So in a PRA-based scheme, the bank does something like:
bank.com IN SPF2 "spf2.0/pra ... include:spf2.sender.com -all"
Then mail would go out with:
Mail-From: bank-bounce-1234(_at_)sender(_dot_)com
From: eft-notifications(_at_)bank(_dot_)com
In a mail-from based scheme, you would need both an SPF or TXT record,
and an MX record (though a single CNAME would work, too). Something
like:
sender.bank.com IN MX 10 bounces.sender.com
sender.bank.com IN TXT "v=spf1 redirect=spf.sender.com"
Now the mail might go out:
Mail-From: notification-1234(_at_)sender(_dot_)bank(_dot_)com
From: eft-notifications(_at_)sender(_dot_)bank(_dot_)com
Are these roughly the scenarios you had in mind? If so, is there
really a huge difference between PRA and mail-from?
Is the big objection just the fact that the mail comes from
"sender.bank.com" instead of just "bank.com"? In practice, it seems
like you might want to do that anyway if you have multiple outsourced
senders, because a screw-up by sender.com, say if spf2.sender.com
doesn't exist, would throw an exception and mess up SPF processing for
all subsequent mechanisms, possibly interfering with other senders.
Maybe what we need is a global modifier "display=domain" that says
what domain to display in the golden padlock. Obviously domain must
be a suffix of the current domain, but it could be a strict suffix to
avoid confusing users with extra clutter like the "sender" in
"sender.bank.com." Something like:
sender.bank.com IN TXT "v=spf1 display=%{d2} redirect=spf.sender.com"
It just seems like mail-from-based schemes could be hugely more
beneficial to virus filtering and joe-job prevention than PRA-based
schemes, while I don't really see a comparable (or any) advantage to
PRA-based schemes. Probably I'm just missing the actual "killer"
scenario that really requires PRA.
David