Chris Haynes wrote:
What I really intended to say was that the SPF protocol
itself should not (need to?) concern itself with forwarding.
Okay, if that means that you don't want to delete chapter 9
in the current drafts I'm happy again ;-)
I don't seriously expect the description of SRS as an
'abomination' to pass through into an approved policy ;-)
Maybe we could tune 9.3 somehow. As long as the SRS and SES
fans don't present some plain text I-Ds I refuse to read or
comment or judge it. Somebody here claimed that SRS works for
him, but he didn't answer my question about a DoS attack with
1,000,000 very long sender addresses.
And Hannah said that it doesn't work well for several millions
of domains, because they don't want any distributed database.
I presume you refer to the mail whose time stamp (in my time
zone) is Sent: Monday, November 22, 2004 4:58 PM.
No, I was talking about Mon, 22 Nov 2004 17:29:23 +0100 as in
<http://article.gmane.org/gmane.mail.spam.spf.discuss/12636> ,
but I vaguely recall what you quote.
The problem is usually to do with a bad end-address. Now
that address was given to him by the end-recipient who has
asked him to do the forwarding. They have to sort out the
problem between themselves.
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.
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.
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.
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.
Work remaing to be done:
- How are non-bounce DSNs to be handled when forwarding is
in use?
Good question, forced me to delete two lines in my reply... ;-)
Bye, Frank