On 2004-07-30 18:18:04 +0100, Tony Finch wrote: > "Peter J. Holzer" <hjp-asrg at hjp.at> wrote: > >On 2004-07-29 15:40:56 +0100, Tony Finch wrote: > >> Bill Cole <grsa at billmail.scconsult.com> wrote: > >> > > >> > The original SPF/RMX/DRIP proposals broke forwarders, the mess that > >> > MS has proposed and Yahoo's Domain Keys do not. SPF has a workaround > >> > for forwarders. > >> > >> Incorrect. Sender-ID breaks forwarders just as much as SPF does, Maybe we should define what we mean by the term "forwarders". For me, they are MTAs which accept mail to an address A, and - under the control of the owner of A - pass it on to a different address B. MTAs which don't change the recipient address aren't forwarders, but relays. The distinction is critical for sender authentication schemes, because a relay should always be under either the control of the sender or the recipient, but a forwarder may be neither. > >No, because it doesn't inspect the envelope but the headers. By looking > >for headers typically inserted by forwarders it avoids some of the > >breakage of SPF. Of course not all forwarders insert such headers, so > >this won't work in all cases (and I wouldn't try to guess at the > >percentage). OTOH, for this reason Sender-ID is much more expensive than > >SPF. > > > >> and it requires all forwarders to implement a change which is in > >> contradiction to RFC 2822 > > > >You mean "must not change or inspect headers except insert a > >Received header"? That's true, but many MTAs already break that > >requirement, so practically, that's not much of a change. > > Sender-ID requires forwarders to insert Resent- headers. No, it requires the forwarder to insert either a Resent-Sender, Resent-From, Delivered-To, X-Envelope-To or Envelope-To header. "Delivered-To" headers are inserted at least by qmail and I think by postfix (X-Envelope-To and Envelope-To headers were no doubt included in the spec because they are inserted by some other popular MTA). Sendmail inserts no such header AFAIK. > No existing forwarders do this. This use of Resent- headers is in > contradiction to RFC 2822. > > I don't know why you mention Received: headers -- these have > never been part of the PRA algorithm. I mentioned them because I wanted to know whether you were thinking about the same rule from RFC 2822 as me. > >> The alternative to changing all fowarders is a forwarder whitelisting > >> system which eliminates what little security designated sender schemes > >> alledgedly provide. > > > >Depends on the forwarder. If the forwarder also filters on a designated > >sender scheme, it can be whitelisted without reducing security. > > If the forwarder gets a virus infection you've lost any protection > provided by Sender-ID. If the forwarders I use get a virus infection I have more serious problems on my hands than a few more emails in my spam folder, believe me :-) > >If it doesn't, you could still use the Received header inserted by the > >forwarder instead of the forwarder's IP address (for sender-id you have > >to inspect the headers anyway, so that's only a small additional > >expense). > > Believing Received: headers is a security hole. They are frequently forged. Received headers are easily forged. But nobody can prevent an MTA from inserting its own Received line. As the final recipient I can know which Received headers were inserted by MTAs I trust and which were not. (At least in principle - in reality I see quite a few problems and wouldn't trust that as the sole filter criterion). hp -- _ | Peter J. Holzer | Je höher der Norden, desto weniger wird |_|_) | Sysadmin WSR | überhaupt gesprochen, also auch kein Dialekt. | | | hjp at hjp.at | Hallig Gröde ist fast gänzlich dialektfrei. __/ | http://www.hjp.at/ | -- Hannes Petersen in desd
Attachment:
pgprWOBKX6Nwo.pgp
Description: PGP signature
_______________________________________________ Asrg mailing list Asrg at ietf.org https://www1.ietf.org/mailman/listinfo/asrg