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