On 24 Feb 2004 at 22:29, Greg Connor wrote:
(...)
So, here is a suggestion that incorporates what I think Hector and Ernesto
are suggesting.
1. Allow receivers to check the HELO name. They MAY check the HELO.
(After everyone likes it and agrees it is a good idea, we can change the
spec to SHOULD check, but we probably should try not to piss off anyone who
has already implemented it.) The receiver that *chooses* to check the HELO
name all the time should be warned that some sites may have their HELO
names set up wrong, and if they check all the time, the might be losing
some legitimate mail from those badly-configured servers, not just bounces
from the mailer daemon of those servers. The practice should carry a
disclaimer until we have some good, solid data.
I don't see how checking an bogus HELO can make you lose legitimate mail.
I understand that there are lots of non-sense HELO strings like PC12343,
mailer.local, or "localhost", but none of those will fail any SPF check,
since there is no SPF record for those domains. If a host sends a bogus
HELO string and it happens to be a domain that holds SPF-entries and the
SPF check FAILS, there could be two cases:
1) this sending MTA belongs to the same owner as the domain, in which
case he should have configured SPF better, so its a problem of SPF-record
maintainance (same problem we have with inproperly configured SPF-records
for the envelope sender)
2) the sending MTA is using a domain that doesn't belong to him, in which
case the legitimate mail will be rejected.
I don't really see case 2) happening. When would a legitimate MTA (even
if it's a very ugly piece of software) introducte itself as a host in a
random domain?
2. Check the HELO name for *known forged* values only. That is, the bad
HELO name is one that would have failed SPF if the message had been MAIL
FROM: <> But we know that many servers have short names (like HELO
mailserver) or weird names that don't resolve (like HELO
mailserver.localhost). But IF the HELO name they are claiming to use has
an SPF record, that record MAY be used to validate the server name even if
the mail is not from <> - Basically, this is enough to check for blatant
forgeries like HELO microsoft.com or HELO baschny.de. Ernesto will be
happy. But the check should not be strict enough to fail the mail
transaction if the HELO name doesn't resolve.
That's correct and is what I suggested too: The unresolvable or bogus
domain checks are optional and MTA-specific. We just want to check for
SPF-pass/fail (where DNS-errors are considered a PASS).
2.1. Check the HELO name against the SPF record for whatever domain name
HELO is claiming to be, and check the MAIL FROM name against whatever
domain name MAIL FROM is claiming to be. Do NOT check the HELO name
against the MAIL FROM SPF or vice versa. We are following the existing
spec, just widening the applicability a bit.
Correct. HELO and MAIL FROM domains can and usually will be distinct.
2.2. Do not mark the message as failed if HELO doesn't resolve or doesn't
have SPF records. Some mail admins may decide to block mail from servers
with a non-existent HELO name but that is NOT supported by SPF policy.
Correct, as I stated above. Companies can even use this SPF-feature to
add SPF entries for its own internal (.local, .intra) domains:
mail.intra. IN TXT "v=spf1 ip4:192.168.2.0/24 -all"
This way no outsider could introduce itself as "mail.intra".
2.3. If the HELO check is PASS, SOFTFAIL, or UNKNOWN, proceed as OK. Don't
add this information to the headers or to any scoring unless the MAIL FROM
is <>. All of the SPF spec is built around the MAIL FROM and the HELO is
an optional add-on. Don't modify the added headers and what not - HELO is
either failed or not recorded/scored anywhere.
Yes, good point.
3. We are already recommending to people that mail servers have their own
SPF records, so bounce messages from those servers can be validated, we are
just (optionally!) widening the range of applicability of those checks.
Therefore, I don't think we really need to change the spec to add
scope=helo. If the existing spec works, use it. In other words, it is
opt-in for the receiver, but we are not giving the sender a choice, since
we have already told them to set up mail server records.
The problem without the "scope" is that you mix the configuration of
HELO hostnames and MAIL FROM domains. There is no way to declare one
thing for "MAIL FROM:<bogus(_at_)baschny(_dot_)de>" and another thing for
"HELO baschny.de". In most cases the same policy would apply, but I
can imagine that someone will come up with a case where this is not
true. Maybe we should wait to see if such a case appears?
Even with "scope=" I understand that there is no way to create a
differentiated policy for HELO and MAIL FROM checks. With the limited
syntax possibilities I also don't see any way around it.
4. I would strongly recommend NOT to "go up the chain". For example, if
there is an SPF record for baschny.de, that should protect against rogue
machines saying "HELO baschny.de". It should NOT be extended to apply to
"HELO www.baschny.de". This is already a principle of SPF. If you want to
protect those other names, make SPF records for them too.
There is already a good reason to provide SPF records for ALL names that
have either A or MX. We are not adding any valid reason to go up the chain
with HELO checking. If there is no SPF for www.baschny.de, I can claim my
HELO name is www.baschny.de -- but then I can also claim my mail is from
gconnor(_at_)www(_dot_)baschny(_dot_)de(_dot_) We should be very very very
very cautious and
suspicious of any attempt to "generalize" the SPF policy of domain.com as
applying to name.domain.com. Some SPF senders may choose not to do this
until forgery of their sub-domains becomes a problem. That is OK. (If you
have wildcard A or wildcard MX, add wildcard SPF. If you don't already
have a wildcard A or MX in your domain then wildcard SPF will not be
needed.)
That's true. Without wildcards, you have to assume the forgery will/can
be blocked by other means (unresolvable HELO hostname...).
5. Domain owners should be aware of this -- there MIGHT be mail servers out
there (if you have a large diverse user base and they set up their own mail
servers) that claim their HELO name is baschny.de even if they are not
sending out mail as user(_at_)baschny(_dot_)de(_dot_) Those servers will
already have a
problem sending bounces - now they will have a problem sending ANY mail,
even mail for other domains not in baschny.de. Remind any local folks who
might set up their own mail server to make an SPF record for their mail
server and to make sure it matches the HELO name.
This has always been the recommendation done by the nice Wizard
at http://spf.pobox.com/wizard.html already. It tells you the possible
names and suggest a "v=spf1 a -all" line.
Would this suggestion satisfy people?
Yes.
Here is another side note I just thought of. In the case of after-receipt
filtering (like spamassassin) I'm assuming they already check MAIL FROM:<>
in a different form, but it's worth checking to make sure those checks are
being performed correctly. If we mention checking Received: lines in the
spec we should mention the <> case too because it may be hard to spot from
the headers. For <> mail, the Return-Path is probably not <> but
MAILER-DAEMON(_at_)receiving-server-name(_dot_) If you are checking SPF
against the
headers by looking for Received: lines added by your server (say
mail1.mydomain.com) then you should look for messages from
MAILER-DAEMON(_at_)mail1(_dot_)mydomain(_dot_)com, and activate the HELO
checking on that
line. Are after-receipt checking systems already doing this correctly? If
so, then all we have to do is add an optional check so that the
administrator can choose to check HELO information ALL the time, not just
when Return-Path is MAILER-DAEMON(_at_)receiving-server-name(_dot_)
Correct. Although I imagine it's pretty ugly to find the correct HELO
string in the Received-lines-mess.
I also like the idea brought up to kick the HELO string from the Received
lines altogether, but this would restrict this kind of checking (but will
also make this checking less needed, since the string will not be visible
anyway...).
Greets,
Ernesto
--
Ernesto Baschny <ernst(_at_)baschny(_dot_)de>
http://www.baschny.de - PGP: http://www.baschny.de/pgp.txt
Sao Paulo/Brasil - Stuttgart/Germany
Ernst(_at_)IRCnet - ICQ# 2955403