On Tuesday 14 November 2006 20:19, Alex van den Bogaerdt wrote:
On Tue, Nov 14, 2006 at 05:51:26PM +0000, K.J. Petrie wrote:
"forwarder" is going to send a message to "petrei(_at_)home(_dot_)address"
but this fails because >>petrie<< has made an error. Please do
pay attention to the (deliberate) typo I made in this address.
Yes, but the typo means my ISP won't recognise it as bound for my
mailbox, and therefore won't apply the policies I have set on my mailbox,
so the SPF check will continue as before, and the mail will be rejected
according to the ISP's standard SPF policy.
Exactly my point.
You (petrie(_at_)forwarder(_dot_)example) have accepted the message.
But this message is going to be rejected by you (@home.address).
Thus the forwarder cannot deliver the message.
Thus the message is bounced, to the victim.
What difference has the forwarder made? As I said above, the sending MTA
has not SPF checked the mail, so would bounce it anyway. That's the only
place an SPF-based reject won't produce a bounce. It's also where the
forger gets no doubt s/he's going nowhere.
It is the forger delivering to "petrie(_at_)forwarder(_dot_)example". It is
you
that made the typo. Or another error occurs, I don't care. It is the
forwarder (selected by you) that causes the problem.
I'm not going to discuss this anymore. If you don't get it now, you never
will.
Alex
Maybe Alex does not wish to discuss this any further, but for the benefit of
others on the list, I don't think this is a major worry because:
1. Exactly the same thing would have happened if the forger sent the message
to a non-existent mailbox - much more likely.
2. If I made the mistake he suggests, I wouldn't be getting any mail, so after
a day or two I would fix it. The chance of a forger forging his domain in
that time and sending it to me is pretty minimal.
3. This has nothing to do with SPF. A message addressed to a non-existent
mailbox will always bounce, whether SPF is used or not, unless the SPF check
occurs on the first hop, which doesn't apply here. So it is irrelevant to the
suggestion I am making, which will normally affect the last hop.
Michael Breton points out that an SPF check is rarely performed on the first
hop. Assuming he is right, SPF-based rejects will always generate a bounce to
the innocent victim, so I don't see how extra bounces would be generated by
turning it off.
Frank Ellermann raises the question of autoresponders. Frank has spent a lot
of time on a detailed and well-reasoned account covering many areas, for
which I am grateful, and I intend to read it carefully and give it the
thought it obviously deserves, so this is just an initial reaction, but it
seems to me that using an autoresponder without an authenticity check of some
kind is discourteous, given the amount of forged spam around. Maybe ISPs
should not provide autoresponders unless such a check is used first. However,
I'm not sure how serious a problem this is wrt my suggestion, because the
choice seems to be between generating a bounce by rejecting the mail, or
sending an autoresponder message both, in the case of forged mail, going to
an innocent victim. In any case, if an SPF check will not yield any useful
information (as behind a forwarder or on an internal network) there is no
point doing it, whatever errors one might wish to prevent. Personally, I
don't like autoresponders, but I accept some people need them to prevent
someone sending them a hundred "why haven't you replied...?" queries. Live
and let live.
So, I'm afraid, at the moment, I can't see how suggesting ISPs allow users to
determine the SPF policies for their own mailbox could seriously impact other
people, but I don't think that's because I'm being blind to problems, though
I'm quite happy to consider the possibility that it is, if someone can show
me how.
K.J. Petrie.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription, please go to http://v2.listbox.com/member/?list_id=735
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735