On Wednesday, January 25, 2012 08:54:42 AM Douglas Otis wrote: > 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.
Safe or not, it's not mandated. This spec is completely optional and is only applicable to domains doing SPF already. > 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. This use of SPF is no different than any other, so it's no better or worse here. I don't think your theories about how SPF will make the Internet melt are on topic in the MARF working group. > Until SPF copes with the current Internet environment, its use should > not be mandated. Safe or not, it's not mandated. This spec is completely optional and is only applicable to domains doing SPF already. > 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 use of SPF is no different than any other, so it's no better or worse here. I don't think your theories about how SPF will make the Internet melt are on topic in the MARF working group. > This might lead to nonsensical SPF records containing "exists:icann.org" > or ending with "+all". No specification can ensure people don't do odd things. Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
