ietf-mxcomp
[Top] [All Lists]

Re: RE: RE: Can you ever reject mail based on RFC2821 MAIL FROM?

2004-04-24 00:39:08


QED

No. 
This is not erroneous. It's in accord with the published 
record and with the final recipient system policy. It's correct.
Try again.


So just to make sure I understand correctly, under the policy you've
defined, the sender is essnetially giving permission to receivers to
reject mail if the MAIL FROM domain fails to be validated, right?  

But senders have absolutely no knowledge about what forwarding
relationships the recipients may have set up.  Thus, they have no way to
know whether or not their messages will be accepted or rejected under
this policy.    

In other words, the policy you've stated is equivalent to "We're sending
mail from this set of IP addresses.  We don't really care whether they
get delivered or not."  


No. It's equivalent to "please feel free to *reject* based on a local
policy that considers our published record". It's a *feature*. The sender
should now have some knowledge of the forwarding relationship. Is this a
bad thing?

I'd expect this kind of failure (i.e. delivery failure, not "fault") to be
numerous in an transitional phase and rapidly become less common as a
result of customer (and peer) pressure on forwarders.

Other than spammers themselves, who would be willing to make such a
policy statement?  

This is a new question, and a different perspective, but the short answer
is:
Anyone who considers that the benefits outweigh the costs.


And if a domain IS willing to make such a policy
statement, why shouldn't the receiver just reject ALL mail coming from
that domain?  



Why would the receiver choose to do that? Of course, they're free (as now)
to reject any and all mail based on local policy.
Currently, sender doesn't have any way to know whether or not their
messages will be accepted or rejected under local policy.
This doesn't change that.

You make think it *unwise* for the publisher to have such a record, but the
receiver is clearly *correct*. Which answers the question you originally
posed.




<Prev in Thread] Current Thread [Next in Thread>