On Tue, 2004-09-14 at 14:14, Matthew Elvey wrote:Yes, the technique won't work. For folks unfamiliar with RHSBLs:
This is a belated-due-to-to-travel follow-up to replies to this post: http://www.imc.org/ietf-mxcomp/mail-archive/msg03596.html (Summary: Sender ID fails to be a solution that only requires sysadmin action; it mandates end-user reconfiguration on a massive scale, because it doesn't say that HELO checking should/must be done... The Microsoft IPR are too encumbered...)
The obvious reaction to [John's] technique would be to spoof IP addresses of
known good MX servers in these records.
<>As I said before, the mailbox domain within SPF and Sender-ID is worthless for reputation checks.
<moved, also by Doug:><> <>
<>I find it difficult to believe people will allow themselves to be harmed by reputation services that hold them accountable for any MTA authorized to send their mail.
Let me clarify. Neither Sender-ID nor SPF will support RHSBLs.Doug, did you get my email - of a possible broad, strong example showing it falling down.
Right, it's not new. It just doesn't have Marketing Might behind it. Of course now it has an encouraging nod from AOL...unofficially, of course :)
=-=-=-=-= On 8/25/2004 4:32 AM, Carl Hutzler sent forth electrons to convey:
<Matthew Elvey said:>
Phrased differently:This is a VERY interesting approach. [...]
....<why HELO>
This sounds really cool. But I am an engineer and must always ask, what is
wrong with this and why has it not been thought of before?
It has been considered and there is language within CSV that
accommodates this approach. : )
Carl- I'm curious as to whether you think AOL would take advantage of this flexibility if it was available.
Lets see, forwarding cases....might work here with some PRA/Submitter typeForwarding case would work GREAT - no PRA/SUBMITTER needed. Yes, 'The MTA would HELO the domain they are about to send for.' This domain wouldn't have to match the MAIL FROM or PRA or SUBMITTER. It would simply need to be a domain that had an appropriate reputation for the content. E.g. if we assume AOL is responsible about ensuring very little spam is sent using the servers it authorizes to do HELO aol.com, and sends all email through these servers, then there is no forwarding to worry about. Helo aol.dom would trigger a reputation check on aol.dom as used in HELO, the reputation would be excellent, and no further checks would be necessary - the From: domain or PRA could be elvey.dom or DomainWithNoSPFrecord.dom.
changes. Not a huge problem.
Here's a sophisticated possible scenario that provides more flexibility: AOL might do HELO goodAolPayingCustomer.dom, if the mail is from one, and the customer hasn't recently sent a ton of email. It might use HELO aolSuspectCustomer.dom where appropriate, before cutting the customer off completely. AOL wouldn't have to pay to give goodAolPayingCustomer.dom a good reputation; it would deserve it. AOL wouldn't have to cut off customers as often - it could limit use in a less draconian way. Helo aolTrialUser.dom and HELO AOLFreeEmailUser.dom would make sense, provided AOL provided and used dedicated IPs for such mail and created the appropriate DNS records.
Just to clarify: the above is a sophisticated, enhanced solution that HELO-based reputations make *possible*. It will be perfectly OK for an MTA (or all of a domain's MTAs) to have one domain that goes in all HELO/EHLO commands sent, and this is likely to be the usual case, and will work well.
<snip>
Cool, though to be fair: what's the upper limit on the number of DNS queries marid-mpr might require, assuming a malicious sender attempting a DoS?I don't care whether a mail server is who he says he is, I care
whether he's authorized to send the message he's trying to send.
May I add that the marid-mpr draft can safely answer this question
within a single DNS query and not require the potentially hundreds
needed by Sender-ID or SPF.
Confusing paragraph, that.
<snip>
Andrew Newton wrote: > On Sep 8, 2004, at 12:06 PM, David Woodhouse wrote: >> A HELO scope would be useful. > That is already being covered by the CSV proposals.
No, not even close. -protocol with CSV, and -protocol with a HELO scope
would be EXTREMELY different, can't believe you don't see this, Andy!
Please consider the need for two steps in this process. One,
authenticate and validate the authorization of the MTA EHLO name. Two,
obtain a list of authorized EHLO names referenced by the mailbox domain
being examined. This list can be either nominal or comprehensive
without the nominal case inviting spoofing. In which case, CSV remains
"as-is". MPR records are much simpler and easier to maintain and obtain
than scripts for SPF or Sender-ID.
Very efficient.I would suggest avoiding sequential TXT scripts needed with either SPF or Sender-ID as being unworkable. CSV used in combination with MPR and BATV provides all the features claimed by either SPF, SRS or Sender-ID without disrupting email to the same extent.
There is another issue with either SPF or Sender-ID records. CSV and
MPR are named based solutions that work within the natural scale of DNS
and only require single non-sequential lookups. SPF or Sender-ID
require either extensive iterative references to record names to obtain
addresses, or the repeating of IP addresses in a script form. The
maintenance of such a list will be high, or the relative overhead to use
such a list will be high or both.
...Folks agree/disagree with that? (Applies only to SPF and SenderID.)
In addition to/as part of the security review of SenderID:
I think it's necessary that a number of MAYs and SHOULD [NOT]s turn
into SHOULD [NOT]s and MUST [NOT]s. There is far too much waffling -
MUST [NOTs] MUST be used whereever there isn't a compelling reason not
to. IETF standards demand it.
Folks agree/disagree that MARID specs should cover how they will work with A&R services? (IMO blacklists and whitelists ARE A&R services.) The result codes from, e.g. sorbs - http://www.dnsbl.us.sorbs.net/using.shtml are more than a binary result - some BLs provide bitmapped result codes.Also, the way that Accredidation and Reputation services are to be used is essential. It belongs in a BCP, which should specify BFP (Best Future Practice) for how various tests should be interpreted and acted upon. SPF claims to address the spam problem (according to text that was on the spf.pobox.com home page) so the Accredidation and Reputation services that are a necessary component to this solution must be specified. An incomplete spec that lacks these things has no business aspiring to be an Internet Standard. How can a spec that is grossly incomplete be properly reviewed by us or the IESG? It can't!
Indeed. I have. It's hell slogging through the acronyms though - MCAL, MCNL, etc. I'll have to read it again in order to be clear on what goes where - A vs PTR vs APL... Just read BATV - glad to see it! Perhaps it could pursue a standards track - the 'Public Tagging' component means interoperability is important so it should pursue standardization.
You will find that the marid-mpr draft does allow the protection of theFrom and the MAIL FROM and is a good alternative to the PRA approach.