Andy Bakun wrote:
I'm seeing the advantage of using a reverse source route
when forwarding being that _trust does not need to be
established at all_, but this is also an advantage of SRS.
ACK. Unfortunately it doesn't work without cooperation. If
the forwarder and the next hop both support STD 10 all would
be well, but if the next hop supports "only" RfC 2821 it won't
work. And the forwarder has no way to detect this in a SMTP
session, with one very obscure exception:
Try EHLO, get error "unknown command", then RSET and use HELO
for a pure STD 10 session. John Levine said "quixotic quest",
that was 100% correct... ;-) In all other cases you simply
don't know what the other side does. For "all other cases"
read "almost all cases".
You could modify MTAs so that they could advertise an "I can
do STD 10" capability, but then it would be probably better
to implement William's SUBMIT. A technical SUBMIT-solution
trying to get rid of a "manual" trust destroys SPF, when it
is abused like the existing 2821-SMTP mess without SPF... :-(
Maintaining whitelists is a hassle
Many MTAs doing SPF checks probably need it. A very simple
case is a secondary MX forwarding all received stuff to the
primary MX, the primary MX must white-list its secondary MX.
Or if your MX is also an MSA you have to "white-list" your own
authenticated users (not really, but somehow you don't use SPF
tests against your own users, it's like an implicit white list)
I've found that maintaining forwarding is a hassle also.
Maintaining two hassles does not sound appealing.
It's a solution if you hate SRS. You could delegate the task
to your users, after all they want this weird .forward to work,
so they should configure it as they see fit:
- 0 don't care, next hop does no SPF or whitelisted you, this
is also the default for all senders without sender policy
- 1 if sender is protected use SRS, resp. reject (551) if SRS
is unavailable.
If they select option "0" (= trust me), and you get a reject
from the next hop delete the account and the .forward (or use
a polite variant of this strategy, e.g. auto-switch to "1" ;-)
Bye, Frank