Re: Mailing lists - assumptions

Using .INVALID is a bad idea.  As enticing as it may sound as a vain 
attempt to counteract what Yahoo did, don't you think they will adjust 
to it?

The bad guys can easily just add .invalid believing some sites will 
actually do policy lookups blindly and just say "Oh, no policy, continue."

Whats to stop a receiver from removing this new "popular" .invalid 
appendage for lookup purposes and still find that the policy is 
restrictive?

   if 5322.From has ".invalid" then
      Strip it and do a Policy Check on the remaining domain.

We are really going in the wrong direction if we have to begin to 
defeat new security protocols by changing the 5322.From field and now, 
probably too late now since this cat's out of the bag, begin to watch 
for ".invalid" to see if bad guys took the idea seriously and began to 
use it.

Keep in mind it also means that you have to stop resigning the mail 
too or is this new adjusted .invalid from including a new resigner bind?

Can we also get into trouble with double 5322.From exploits now with a 
new "unethical" willingness to tamper with this important header, 
probably the only one remaining in 5322 that is most important to have 
correct with some higher degree of confidence and trust.

-- 
HLS


On 4/20/2014 5:39 AM, Alessandro Vesely wrote:
> On Sat 19/Apr/2014 17:57:24 +0200 Theodore Ts'o wrote:
>> On Sat, Apr 19, 2014 at 11:49:06AM +0200, Alessandro Vesely wrote:
>>>
>>>> From: user+originatingdomain.example.com@dmark-remediation.mailing-list.org
>>>>
>>>> .... where dmark-remediation.mailing-list.org is an MX record to an
>>>> automated bounce server that will explain to the user that they need
>>>> to really send their e-mail to [email protected] via
>>>> a 550 error.
>>>
>>> Oh well, it is easier, clearer, and safer to have
>>>
>>>     From: [email protected]
>>>
>>> and let submission servers issue that 550 directly.
>>
>> The problem is that there might be some receiving servers that will
>> try to see if the originatingdomain.example.com.INVALID is a valid
>> domain address, and seeing that it isn't, might reject the e-mail on
>> that basis.
>
> Exactly.  Why is that a problem?  Upon rejection the user will notice
> the ".INVALID" and remove it, just like he or she would have done if the
> rejection had arrived from dmarc-remediation.  The latter could have
> contained a pointer to an explanation page, which interested users may
> also find with google.
>
> Ale
>
> _______________________________________________
> ietf-822 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-822
>
>


_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822