On Tue 18/Mar/2014 04:30:19 +0100 Robert A. Rosenberg wrote:
At 20:48 +0100 on 03/14/2014, Alessandro Vesely wrote about Re:
[ietf-smtp] Per-Recipient Data Responses:
Per-recipient solutions can also be run on the MUA, if dropping is the
only alternative. That makes them completely orthogonal to boundary
filters. In any case, since that's in users hands, they are
responsible to find what suits them better.
Note that reliable Per-Recipient reporting to the MUA (so it can react
to and handle the reports that the message was accepted for delivery
or the delivery request was rejected) depends on the MUA using as its
Mail Submission Server for the message one run by the Recipient's ISP
(and that all the recipients are serviced by THAT SMTP Gateway
Server). So long as it uses a server that will only forward it to a
Server responsible for the email domain instead of one which would
accept responsibility for the delivery then there is no way that a
Per-Recipient submit time response to the RCPT TO can occur (since a
MSA Server does not know if the message will be accepted).
As an example, if I wanted to send a message to Alessandro, I would
ONLY be able to get a submission time accept/reject if it was being
sent by my MUA directly to the tana.it MX server. If I send though MY
ISP's submission server it will forward to the MX server and I will
only an email reject message not a reject at submit time.
Yup, that's regular SMTP behavior. There is no advantage in /getting/
a report directly at submission time: There is increased reliability
in /issuing/ a rejection decision online, as that does not risk to
cause backscatter. There is no reduced reliability in letting a
submission server issue a DSN to the authenticated user it relayed for.
Afterthoughts taking place after acceptance ought to go through a
different path, such as that described in RFC 6650. For example, is
my MUA had erroneously classified your message as spam, the tana.it
mail server should have noticed the move to the spam folder; then it
should have sent a report to abuse(_at_)panix(_dot_)com, based on the SPF
authentication verified at acceptance time. That path is very
unreliable, as my server currently doesn't do that (yet), and even if
it did, it is not clear that the report would have reached the
original author.
Ale
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp