On Fri, May 20, 2005 at 09:22:11AM -0700, David MacQuigg wrote:
You query TXT for sales.some-company.com against the source IP.
If you want to check permission for HELO, you do the same for
mailserver7.bigforwarder.com.
Since bigforwarder.com is probably in trusted forwarders, you might
ignore a FAIL on MAIL FROM:, but definitely would not ignore a FAIL
on the EHLO.
Probably ... probably ... We need to remove this uncertainty about the
sender's intent.
Forwarding is done by the receiver, not by the sender. It therefore
is the receiver's problem, not the sender's.
A == Sending MTA, sending on behalf of domain "example.org"
B == Receiving and forwarding MTA "bigforwarder.com"
C == MTA forwarded to
A is sending his message, takes care of proper SPF configuration
and so on. Everything is well, all is configured properly.
B receives the message. It can check SPF, verify A's authorization
to use "example.org" and so on.
Now B sends the message to C. Is is saying "mail from:
user(_at_)example(_dot_)org".
This is:
-1- Against the explicit policy of domain "example.org"
-2- Not true
Now C is receiving the message, from B. If it checks SPF then:
-1- it finds that "example.org" does not authorize B to use its name
-2- it should reject therefore to receive the message
Possible solutions:
-1- C should trust B. It knows that B forwards messages and it thus
knows SPF should not be checked. This is a similar setup as used
in many companies, providers and the like. MTAs "B" and "C"
are in the same trust-domain. Consider B to be at the border and
C to be some internal MTA.
-2- B should not use the "example.org" domain name.
Any attempt to fix the problem (which is caused by the receiver) at
the sender's side is probably going to fail somehow, sometime.
Alex