On 1/23/12 7:22 PM, Scott Kitterman wrote:
Douglas Otis <[email protected]> wrote:
> On 1/23/12 5:26 PM, John Levine wrote:
>>>> You say to use a null bounce address and a HELO with a
>>>> domain that produces an SPF Pass. I say use whatever bounce
>>>> address you want, but be sure that it produces an SPF Pass.
>>>> I don't see any practical advantage to requiring a null
>>>> bounce address. If it's not null, and the r= address doesn't
>>>> work, the reporter might get the report bounced back, but if
>>>> I were a reporter I'd prefer to know if my reports were going
>>>> into the void so I could stop sending them.
>>> The advantage of null mail from is no bounce loops. Right, and
>>> the disadvantage is no feedback if it's bouncing.
>>>
>>> How would you feel about SHOULD use null mail from (with
>>> EHLO/HELO SPF pass), but MUST avoid mail loops and Mail From,
>>> if not null, MUST pass SPF?
>> Make it MAY use null bounce address and we have a deal. And
>> whether or not it's null, it MUST pass SPF.
> Dear John,
>
> It would be a bad practice to require a protocol that defeats
> DNS/API caching by incorporating local-part macros that are of no
> value. Macros able to target a domain with a significant number of
> recipient generated transactions per message where the victim may
> not be evident within any referenced record or message. Is MUST
> not use local-part macros an ingredient of this mustard?
No. This is no different than any other use of SPF.
Dear Scott,
Perhaps, but to what end?
Until SPF is safe for the rest of the Internet, its use must not be
mandated.
After all, SPF mechanisms and macros permit more than 100 reflected DNS
transactions per message times the number of parameters checked. This
is suggesting a check against the Mail From and EHLO parameter that
lacks any other form of cache-able authentication. The use of
local-part macros with SPF means this validation process must NEVER be
assumed cache-able.
Until SPF copes with the current Internet environment, its use should
not be mandated.
What happens when the client and server do not share the same version of
Internet Protocol and one of their Internet providers compensates by
translating between the two?
This might lead to nonsensical SPF records containing "exists:icann.org"
or ending with "+all".
Regards,
Doug Otis
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
