spf-discuss
[Top] [All Lists]

Re: Re: RFC 2821 and responsibility for forwarding

2004-12-06 22:55:52
On Mon, 2004-12-06 at 22:23, Frank Ellermann wrote:
this "fixes" forwarding in an SPF-enforcing-world by getting
rid of forwarding

For the POP3-solutions only if user(_at_)forwarder never fetches his
mail, and then it's necessary.  If the POP3 mailbox is mainly
used to collect bounces from user(_at_)nexthop, then it's good if
this mailbox is much smaller than 1 GB :-)  Otherwise collected
trouble would wait there forever, neither user(_at_)nexthop nor the
original SPF-protected sender would know what's going on.

Which is why it's better if it sits in the forwarder's mail queue
waiting for the recipient (next hop) to pick it up rather than being
sent to the local delivery agent for delivery to an out-of-MTA
mailbox... which brings me to...

I still like ODMR/ATRN, a lot,

Yes, I thought that this could be realized on top of POP3, the
user could then use whatever he likes (or is forced to use),

Mmh, when I first read this, I was thinking that this would mean
providing an ODMR ATRN interface to a POP3 mailbox -- which I don't like
because it means actual delivery to a mailbox and the message leaving
the control of the MTA.  If you go the reverse and provide a POP3
interface to messages in the MTA's queue, then the MTA retains control
of the messages, and all the metadata that entails (that is, the
metadata, like the envelope info, that is required to generate a valid
DSN), and the messages would fall under the limits specified in RFC2821
section 4.5.4 and would eventually bounce if never picked up.  I like
that.  But it's not like ODMR, while relatively obscure because MUAs
don't pick up mail via it, doesn't have an implementation -- fetchmail
has supported it for a few years I believe.  Still, getting people to
use ODMR for uses other than MTA to MTA transfers might be as hard as
getting people to use RSR. :)

Andy.