Hi !!
yes, but it's mainly for the case of the null nevelope sender
Correct, it was originally for null return address. Enough people
expressed an interest in using SPF for HELO checking that it was built
into many SPF checkers as an optional feature that can be turned on by
the admin.
but this will not work, see the case with hotmail unless a different
policy could be stablished for each check.
and it's
not possible right now to specify separated policies for mail from and
helo for the same domain.
Not true, but since you already know about the "postmaster" workaround,
you already know this.
this is just a workaround that only will work if i publish such information
and if the receiver forces helo checks on every incoming email. And what
about people that want to publish a policy for the postmaster that does
not conform with the policy for the helo. This is not the way to go ...
When it comes time to decide "where to go from here" and "what to do 1
year from now" let's talk about whether Unified or Separate is better.
why not start this discussion it right now ? (i mean, i tough we already
have started it)
For NOW, what I am trying to explain is that HELO checking in SPF
already exists. Now.
no, you are only speaking about workarounds and optional tweaks. SPF
right now only talks about helo checks when it could not check the
sender.
> Before we talk about the future, let's establish and
agree on what is in the code right now and actually running on most if
not all SPF checkers.
i'm doing spf checks for a long time, but i cannot make helo checks
ALWAYS, just when the implementation i use decides to use them. In
fact i had to disable spf checks for null envelop senders so i have
seen legal email fail the helo checks.
Where we are NOW should not be a subject of much debate, because it's
incredibly easy to observe and measure. Let's make sure we agree about
where SPF is now, today, at this moment, and then we can have long
discussions about the future and where to go from here.
Where we are NOW is:
SPF checks MAIL FROM, and HELO sometimes, and HELO all the time if you
turn on the switch.
i have no such switch, and if i had it i will not turn it on as
almost nobody that publishes spf records is taking in account helo
protection.
The same record is used in both contexts which is usually what you want
no, it's not what i want, in fact it's totally diferent.
It is possible to specify different policies with a %{l} macro, if needed.
no, there is a workaround where i can either specify policy for the helo
or for the postmaster but not for both (if they are different)
You started this discussion by asking "How do I do this"
hey, i never asked such this thing !!
and I answered: this is how
not really.
I didn't expect to get disagreement about how things are
now. I just answered, assuming it was an honest question. I am now not
sure if you are disagreeing with me about how things actually are now,
or if you are just making suggestions for the future.
both of them.
but this breaks forwarding.
I understand why you say this but I don't agree with it.
it really does.
I publish -all
for my personal domain. I don't see a problem with doing so.
that's your choice, but you are not alone, most of us will have real
problems publishing -all
If people
want their mail forwarded, they can make accomodations for it, such as
using trusted-forwarder white list or their own white list.
not, the problem is that you cannot take control of all of that,
you cannot guess how many forwarders are on the earth and put all
of them in trusted-forwarders.
Some of SPF's critics (most notably David Woodhouse) have said over and
over and over that "-all breaks forwarding". I don't agree with that
generalization. People checking SPF really need to be aware of
forwarding, and use whitelists, but senders should not avoid -all just
out of fear that some receivers will do it wrong. Receivers who do it
wrong should fix their own problem, not blame it on people publishing -all.
the problem is not on receivers is on forwarders. in that question i
agree with David Woodhouse, -all really breaks forwarding, altough
you can force all forawrders to uses srs, which will unlikely happen.
For those people who send mail from postmaster, AND that mail might come
from other sources not specified in the SPF record, AND they want their
HELO name protected, are not going to be able to get everything they
want.
that's because you are using a screwdriver to fix nails, you can use
it but is not the correct tool.
Again, I didn't mean to get into a philosophical debate about the
"right" way to do things. I am describing the WAY THINGS REALLY ARE
TODAY.
and i'm saying that the way that things really are today is not good,
so let's invent/try a better way.
I totally agree that there is a more elegant way to deal with it
coming in the future, but that hasn't been invented yet. When it is,
your comments about it will probably turn out to be right.
well, we are trying to do it right now.
HELO checking in SPF EXISTS NOW TODAY. It's not doing something the
tool hasn't been designed to do
can you tell me where spf classic says it has been designed to do helo
checks ??
(Sorry for repeating the same point over and over, but I don't think I
have been clear enough before. We need to totally separate the two
questions of "how it works now" and "how it should work in the future".)
the original discussions started as "how it should work in the future",
i know "how it works now" and i don't like it, so when somebody else
proposed to separte helo cheks from spf i agree with him, so now you
could agree with us or not, but trying to convince us that spf is
what it is is a waste of time, all of us know how spf is.
You can. The only limitation right now is that you can't publish
different policies for HELO domain and MAIL FROM: <postmaster(_at_)domain>.
(Or maybe there is... there might be some other macro that could be used
to tell the difference. Frankly nobody has mentioned it as a problem
before so there wasn't a real need to go looking for a second, more
complete solution.)
No, we can't. In our case postmaster can send email but we do not want
anybody to use our domain at the helo, so either we allow anyone to
forge our domain at helo or prohibit postmaster to send mail. So this
does not work, at least for us.
--
Best regards ...
It's a fine line between fishing & standing still
----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail david(_at_)ols(_dot_)es
Pintor Vayreda 1 telf +34 902 50 29 75
08184 Palau-Solita i Plegamans movil +34 670 35 27 53
----------------------------------------------------------------