Hector Santos wrote: > only after I clicked SEND
Same here, I found your explanation after I clicked "send". > It may also raise the question when the "World's largest > ESP" and a growing amount of other ESPs/ISP mail receivers > forcing this PTR record, should be 'Highlighted' in 2821bis. I think that is unnecessary. 2821bis-09 already covers it in chapter 4.1.4: | An SMTP server MAY verify that the domain name argument | in the EHLO command actually corresponds to the IP address | of the client. However, if the verification fails the | server MUST NOT refuse to accept a message on that basis. Where "receiver policy" overrules a MUST NOT it won't help to add "really" in the draft. What AOL does is apparently different, they "only" require that a name exists, not that it matches. A variation of the MTAMARK theme. Let's keep 2821bis as is for this issue, it's discussed in other drafts: draft-ietf-dnsop-inaddr-required-07 (2005), replaced by: draft-ietf-dnsop-reverse-mapping-considerations-06 (WGLC) An "iprev" mechanism is specified in draft-kucherawy-sender-auth-header-14 (2008) Hopefully Murray can submit a PubReq soon, it depends on DKIM-ADSP, after s/SSP/ASP/g it now needs s/ASP/ADSP/g :-| I think the OpenSPF folks liked the draft, as far as SPF and PRA are concerned, i.e. not necessarily "iprev". I've no problem with "iprev", but it could cause a flamewar in Last Call if somebody wants this. > I guess there is also some selfishness here because as > with most things, if it doesn't happen to you, if you > don't feel it, most people who careless about it. We should have pushed harder for something like MTAMARK in 2005, but we didn't. Now we get what's left. If you don't like "iprev" here is something you might like, TMA: http://blogs.msdn.com/tzink/archive/2007/10/26/sender-authentication-part-32-tma-explained.aspx For the known reasons I don't like it when receivers do weird things based on unrelated info published by the alleged or real sender, but I also know that YMMV. <eg> Frank
