headers
Hector Santos | 1 Jun 2005 01:24

Re: "Header Reordering", yet again


----- Original Message -----
From: "David MacQuigg" <david_macquigg <at> yahoo.com>
To: <ietf-smtp <at> imc.org>
Sent: Tuesday, May 31, 2005 3:16 PM
Subject: Re: "Header Reordering", yet again

> I would go even further and say re-ordering of headers by forwarders is
> very rare, but at this point I'm just guessing, so I'll keep  looking for
> any facts to the contrary.

No need to guess.  Its common sense.

First, if it was happening, obviously it isn't something that cause
problems.  Something that tends to cause a noticeable problem will typically
be a) public knowledge, and b) the vendor made aware.   When it comes to
non-isolated problems (a problem related to networking with others), the
problem is usually addressed pronto.  No company NDA will prevent the
exposure of public knowledge for a problem that is noticeable across points.

Point: Mail Distribution Software are the first to find out of problems when
it causes disruption or in the case of something new like a security
concept - a possible reordering issue.

Second,  Where is this Receive-SPF: analysis suppose to take place?

Think about it.   Here is a basic summary framework outline of our decades
old system that has evolved over time:

(01)  network
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Lilly | 1 Jun 2005 04:07
Picon

Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt


On Tue May 31 2005 09:56, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
>   [problem with the mail provider]
> >> your solution was sending direct-to-MX with a MAIL FROM
> >> listadmin <at> bruces.box.example and a HELO bruces.box.example
>  
> > No, neither MAIL FROM nor HELO/EHLO were changed. no point in
> > changing MAIL FROM, as the intent was not to change where
> > delivery notices were sent.
> 
> Now it sounds like an ordinary alias-style forwarder to third
> parties (5.3.6(a) in 1123).

No, manual mailing from me.

> In fact it _could_ work in several ways, e.g. if the senders
> add your mailouts to their sender policies,

Not applicable.

> Or if the receivers white 
> list your mailouts as "trusted forwarders", maybe depending
> on the RCPT TO, it's also okay.

You're grasping at straws.  That's more onerous than your "use
additional providers" approach.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frank Ellermann | 1 Jun 2005 05:12
Picon
Picon

Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt


Bruce Lilly wrote:

>> Now it sounds like an ordinary alias-style forwarder to
>> third parties (5.3.6(a) in 1123).

> No, manual mailing from me.

Okay, that was my third and last attempt to guess what you're
talking about, if you want WXYZ puzzles with W = X = 2 we're
on the wrong list.

>> if the receivers white list your mailouts
[...]
> You're grasping at straws.

That was an enumeration of theoretical possibilities, I said
_could_ and not should.

It's a perfectly normal case for SPF that a primary MX getting
mail from a secondary MX white lists the latter.  If somebody
trusts your manual relaying or whatever it is he _could_ white
list you - of course not for a dyn. IP and an invalid HELO.

>> Reliable MX services are something you can arrange (e.g. buy),

> It's amazing how willing some FUSSP proponents are to spend
> other peoples' money...

And that was an idea how to run your own MTA with a dyn. IP and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert A. Rosenberg | 1 Jun 2005 06:41
Picon
Favicon

Re: "Header Reordering", yet again


At 16:33 -0400 on 05/31/2005, Bruce Lilly wrote about Re: "Header 
Reordering", yet again:

>On Tue May 31 2005 15:51, Robert A. Rosenberg wrote:
>
>>  Or link them by having the ID field from the Received Header
>  > replicated in the Received-SPF Header.
>
>Been there, discussed that. The "id" component is optional.
>You can't replicate what isn't there.

If you say so. I've never seen a Received Header that is missing it. 
In any case, I fail to see why replicating it IF IT EXISTS is worse 
than not using it at all since it would help to link the Received-SPF 
and Received Headers when some poorly designed MTA has scrambled the 
order of the headers that were in the message when it was handed off 
to the MTA instead of it just prefixing its Received (and 
Received-SPF) Headers to the front of the header block.

IMO, NO alteration of the header block contents of the message as it 
arrived at the MTA should be permissible unless it is acting as a MSA 
(ie: Accepting a Message from a MUA) when it should restrict its 
alterations to inserting a missing DATE Header (or correcting an 
invalid timestamp) or Message-ID  Header (or other required by 
missing Headers).
Permalink | Reply | 0 comments |
headers
willemien | 1 Jun 2005 16:06

Re: Re:


At 16:33 -0400 on 05/31/2005, Bruce Lilly wrote about Re: "Header
Reordering", yet again:

>On Tue May 31 2005 15:51, Robert A. Rosenberg wrote:
>
>>  Or link them by having the ID field from the Received Header
>  > replicated in the Received-SPF Header.
>
>Been there, discussed that. The "id" component is optional.
>You can't replicate what isn't there.

Is there something simpeler than adding in the SPF draft that for SPF compliance an ID field in the received
header is a MUST?

No I do not take the argument that the draft is unchangable becaurse it discribes the way SPF allready works.
RFC means request for COMMENTS and a draft is even before that stage...

(sorry if you think that i am over reacting on this)

Other small point:

section 5.2 an include that is not an include

In hindsight, the name "include" was poorly chosen.

Then rename it.
Or at least rename it to any of the better names
and use "include" as an obsolete term that also mans the same.
(If you really want to keep it working)
(Continue reading)

Permalink | Reply | 502 comments |
headers
Hector Santos | 1 Jun 2005 18:32

Re: Re:


----- Original Message -----
From: <willemien <at> amidatrust.com>
To: "Robert A. Rosenberg" <hal9001 <at> panix.com>
Cc: <ietf-smtp <at> imc.org>
Sent: Wednesday, June 01, 2005 10:06 AM
Subject: Re: Re:

> >>  Or link them by having the ID field from the Received Header
> >  > replicated in the Received-SPF Header.
> >
> >Been there, discussed that. The "id" component is optional.
> >You can't replicate what isn't there.
>
>
> Is there something simpeler than adding in the SPF draft that for
> SPF compliance an ID field in the received header is a MUST?

The issue depends how SPF is implemented in the host.

The ID will only work 100% if the SPF implementation is direct within SMTP
like at the MAIL FROM or DATA stage.   Here you have control of both the
Received: and the Received-SPF: header.

If the SPF implementation is done as post SMTP process, then it may not any
say control or say over the creation of the current Received: line and an ID
mandate.

PS: I believe the current SPF1 specs recommends a direct SMTP
implementations to minimize bounce attacks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
willemien | 2 Jun 2005 18:21

Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt DNS comments


Hello, all

I have posted some questions on the DNS Stuff forum about the SPF draft.

To view the thread go to:
http://forums.dnsstuff.com/tool/post/dnsstuff/vpost?id=472797

Other remarks about section 3

3.1
v=spf1 is not conform RFC 1464 (this is about the TXT record not about the SPF record but as long they both MUST
be identical)

also
RFC 1464 is not mentioned in the references
the quotes are NOT nessesary (AFAIK)

3.1.1
An SPF-compliant check SHOULD try to look up and use a record of the SPF type first, before falling back to the
TXT type.  However, the client MAY also look up both types in parallel.
If, for a domain, both types are obtained but their contents do not match, the SPF client SHOULD return a
"PermError" result.

The "PermError" rule is NOT mentioned in 4.5 Selecting records.
Also:
What to do if both rules are not identical but they both exclude or allow the domain in question?
Still the SPF client SHOULD return a "PermError" result?

3.1.3
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frank Ellermann | 2 Jun 2005 23:04
Picon
Picon

Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt DNS comments


willemien <at> amidatrust.com wrote:

> http://forums.dnsstuff.com/tool/post/dnsstuff/vpost?id=472797

The answers you got there appear to be correct - I'm more on
the ignorant side about some DNS isssues, but SPF forced me
to get some basic ideas at least theoretically...

> RFC 1464 is not mentioned in the references
> the quotes are NOT nessesary (AFAIK)

...and therefore the first thing I did when I read "1464" was
to go to Rfc-editor.org and check its status:  experimental,
1993.  There are no necessary quotes within SPF records, it's
just a way to display strings.

> The "PermError" rule is NOT mentioned in 4.5 Selecting
> records.

Yes, 3.1.1 and 4.5 overlap, and there might be an inconsistency
for the case "both types exist with different content".  I had
my own problems with 3.1.1 (essentially I wanted to get rid of
the offending "PermError").  Something's odd there.

> What to do if both rules are not identical but they both
> exclude or allow the domain in question?

foo.bar.example. IN SPF "v=spf1 +a redirect=more.bar.example"
foo.bar.example. IN TXT "v=spf1 -a redirect=more.bar.example"
(Continue reading)

Permalink | Reply | 0 comments |
headers
willemien | 2 Jun 2005 23:45

Re: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt DNS


>> http://forums.dnsstuff.com/tool/post/dnsstuff/vpost?id=472797

>The answers you got there appear to be correct - I'm more on
>the ignorant side about some DNS isssues, but SPF forced me
>to get some basic ideas at least theoretically...

>> RFC 1464 is not mentioned in the references
>> the quotes are NOT nessesary (AFAIK)

>...and therefore the first thing I did when I read "1464" was
>to go to Rfc-editor.org and check its status:  experimental,
>1993.

OK I know its old and experimental, but there is no other RFC about it so why don't follow it?

> There are no necessary quotes within SPF records, it's
> just a way to display strings.

That makes it even worse, is it only for display in this draft or are they for real?
This can have real concequences when you split the record up in
strings. (Does the second string starts after the 2nd or 3rd ")

>> The "PermError" rule is NOT mentioned in 4.5 Selecting
>> records.

>Yes, 3.1.1 and 4.5 overlap, and there might be an inconsistency
>for the case "both types exist with different content".  I had
>my own problems with 3.1.1 (essentially I wanted to get rid of
>the offending "PermError").  Something's odd there.
(Continue reading)

Permalink | Reply | 501 comments |
headers
wayne | 5 Jun 2005 21:33

Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt DNS comments


In <VPOP32.1.7.20050602172121.260.1.1.2853140e <at> [217.155.134.110]> willemien <at> amidatrust.com writes:

> I have posted some questions on the DNS Stuff forum about the SPF draft.

Hi!

Thanks for the review.  Frank has already commented on this, but I'll
add one more note.  I have also posted a reply to the DNS Stuff forum.

> 3.1.1
> An SPF-compliant check SHOULD try to look up and use a record of the SPF type first, before falling back to
the TXT type.  However, the client MAY also look up both types in parallel.
> If, for a domain, both types are obtained but their contents do not match, the SPF client SHOULD return a
"PermError" result.
>
> The "PermError" rule is NOT mentioned in 4.5 Selecting records.
> Also:
> What to do if both rules are not identical but they both exclude or allow the domain in question?
> Still the SPF client SHOULD return a "PermError" result?

I have moved all of the text about the different lookups out of
section 3.1.1.  I have updated section 4.4 "Record Lookup" to mention
that the lookups can be performed in parallel and I have updated
seciton 4.5 "Selecting Records" to define the PermError results

-wayne
Permalink | Reply | 0 comments |

Gmane