Hello!
On Fri, Nov 26, 2004 at 02:54:23AM +0100, Frank Ellermann wrote:
[...]
True. And if it's something trivial like this scenario...
HELO me MAIL FROM me RCPT TO u(_at_)hop1 => queue 1
HELO hop1 MAIL FROM x RCPT TO u(_at_)hop2 => reject, bad u(_at_)hop2
...then hop1 should be able to bounce it to me somehow, after
all a traditional forwarder would use x == me, and a new
style forwarder could note the "me" somewhere, maybe in one
of William's new "redirection" headers, In that simple case
hop1 could also mark the .forward file of u(_at_)hop1 as invalid.
Ok. That makes sense if u(_at_)hup1 also has direct access to mail at hop1.
E.g. a traditional UNIX account where s/he has setup a .forward file.
Then, the mail system could rename .forward into .forward.INVALID and
notify u locally. But OTOH, if u has setup a .forward, s/he doesn't
expect to receive any mail locally at hop1, so s/he might well miss that
notification, as well as any future mail.
If things turn out to have been a temporary problem (like hop2's
provider temporarily messed up the user database and returned a 550 User
Unknown for a few hours), then the question remains what damage is
higher, permanently removing the forwarding, or a few bounces reaching
"me", even though me isn't responsible for the problem, of course.
And another point is, then, what if hop1 doesn't really provide local
access, but *only* forwarding, say you can just setup a username with
them and set a forwarding target using a web frontend, and that's it wrt
incoming mail to u(_at_)hop1?
Then, there's no "default" delivery mode you can chose after removing a
forwarding target that might be permanently invalid.
So you have only two ways left: Notifying "me" that something's botched,
like "it's not your fault, but this mail of yours hasn't reached the
recipient because of a configuration error" (just like senders also get
bounces from sendmail if there's a "local configuration error", so mails
aren't just dropped w/o anyone noticing). Or hop1 cancelling service for
u, temporarily or permanently, and notifying u in some out-of-band way.
It starts to get interesting if u(_at_)hop2 is over quota, or any
other situation forcing hop2 to bounce to x instead of reject.
Right. (Except that some sites check quota during the SMTP chat so
over quota leads to reject instead of accept+bounce.)
Nevertheless it's still a problem between u(_at_)hop1 and u(_at_)hop1,
and hop1 _should_ be interested, maybe again invalidating the
.forward of u(_at_)hop1(_dot_) I'm also interested, x ==
u(_dot_)dev(_dot_)null(_at_)hop1
is not the best possible solution. And of course the affected
u(_at_)hop1 resp. u(_at_)hop2 is interested, he has a serious problem.
Right. And SRS suggests to use something like
SRS0=(_dot_)(_dot_)(_dot_)(_dot_)=me(_at_)hop1, and if
mails bounce, the bounce is directed back to "me".
So the x should be something like a traditional POP3 mailbox,
where u(_at_)hop1 resp. u(_at_)hup2 can get his dead mail later. That
could work for Hannah's case, they probably offer POP3, and do
the forwarding only on demand.
We do offer pop3, but for a given localpart it's either pop3 or
forwarding. So we can't just switch a forward back to direct pop3.
[...]
Kind regards,
Hannah.