Sorry, wouldn't work. The name of the POP or IMAP server need not
bear any relationship to any email address. For example, on my
system, the server is named imap.iecc.com (yes, even for POP, it
deters the clueless) but there are not imap.iecc.com addresses at all.
I don't understand why this is relevant. If the MTA operator doesn't want
to support this feature, he doesn't have to. But if he does wish to
support the feature he needs to supply an MX record or accept mail on the
POP or IMAP server. Is that such a great burden? Compared to the other
suggestions here?
Honestly, none of us knows. The name of the POP or IMAP server has
never been intended as part of an e-mail address, so it's hard to
predict what might break. Overloading names tends to lead to
surprising failures. For example, my POP/IMAP server is also my
SUBMIT server, and although it doesn't have an MX record, it does have
an A record. That means that with your proposal, if I did nothing and
one of my users happened to have an MUA with a spam button, when he
pressed it, it would connect to my SUBMIT server and send a message to
the undeliverable address arf(_at_)imap(_dot_)iecc(_dot_)com, causing a baffling
bounce.
I share your concern about demanding upgrades to large amounts of mail
software which is why I'm not thrilled about changes to IMAP and POP
protocols. I also think it's pretty important that the reporting
process has to be opt-in. That's why an extra field in the
Authentication-Results header is attractive, it's something that
delivering MTAs are somewhat likely to add as part of the spam
filtering process anyway, and doesn't require and changes to the
downstream POP or IMAP or whatever.
R's,
John
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg