Andy Bakun wrote:
I also agree with David Woodhouse
[...]
where he said:
I fully support the practice of rejecting mail from domains
publishing '-all' records with a 551 error code if you would
otherwise have to forward it.
Yes, I forgot this in my incomplete list, it's needed in all
POP3-based workarounds for the "over quota" case.
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.
I don't think the SPF position on forwarding should be "don't
do it".
Sure, it's "do what you like, and don't cause harm" (one step
further and we're in a religious debate ;-) because there are
many possible solutions, but not one best way for all.
[incomplete list of solutions]
- ordinary POP3 (incl. all solutions working on top of POP3)
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),
people would end up becoming Email Service Providers rather
than just deploying a forward file for the sake of onvenience
-- I'll set up a simple forward for an ex-employee (if
company policy allows it), but I'm not interested in keeping
that user's mailbox around and having to maintain quota
control and whatnot for 'em after the leave the company).
True. But in that case you could pull the 551 stunt for your
ex-employee, after all he wants this service. Again the cases:
- next hop doesn't support SPF => 251 forward
- sender has no sender policy => 251 forward
- otherwise 551 / SRS
The first case also covers situations where the next hop has
whitelisted you, maybe it's a private box of your ex-employee,
or a small provider, and he can manage this. And the 1st case
is something configured / confirmed by your ex-employee, you'd
disable this "don't care" bit as soon as anything doesn't work.
RSR, er, Reverse Source Routes, as I've already outlined
You're allowed to use it always, it's in STD 10. But you still
need a confirmation that the other side respects it, the normal
2821 procedure is to ignore RSR. If the next hop forwards to a
3rd hop (any normal 2821 MTA) it won't work. But otherwise you
could set the "don't care" bit for this ex-employee.
"Does this ISP support RSR ?" "Hu ?!" "STD 10, reverse source
routes." "Sure, they support standards." <eg>
Everytime I come across another way to "solve the forwarding
problem", and then compare it to SRS, SRS wins everytime
because it is the simplest solution and requires the least
number of people to change.
I'd still like to see a plain text explanation of how it's
supposed to work for long addresses, if a paranoid forwarder
intends to stay within the 64 characters limit for the LHS...
and is hit by millions of different long addresses, just to
make it more interesting.
SPF tests based on the RCPT TO are a technical nightmare
(probably impossible).
Heh, success! :)
BTW, Hector said in mxcomp, that his product _must_ delay most
tests until RCPT TO, because that's the moment when it detects
any attempt to be abused as open relay. Maybe an "all-in-one"
MTA (MSA. MX, MDA), irrelevant for your "big ISPs don't white
list for single users" example. Hector published a matrix of
possible tests at the time of RCPT TO in mxcomp.
Bye, Frank