Mailing List Archive

On Tuesday 26 February 2008 07:57, ram wrote:
> I think the oft repeated "SPF-breaks-forwarding" and
> "Use-SRS-when-frowarding" is the still top problems for SPF acceptance.
>
> The next big hurdle is when ISP's block smtp access to corporate
> mailservers and force the corporates to include a plethora of IP into
> their SPF

Use the submission port, port 587. That's virtually never blocked.

>
> Regarding the first problem
> I am using Postfix and cyrus on my mailserver and use sieve rules for
> forwarding. Frustratingly even though SRS has been around for ages now
> there is not a single implementation of SRS for my setup. I remember
> trying some smtp milter but that never worked

Postfix still (unless it's in 2.5, I haven't looked) lacks a way for external
programs to rewrite mail from so you'd need to do it with a transparent
filter. There's been some disucssion about this being a good feature to have
(for more than just SRS) on postfix-users, but someone either needs to
provide a patch or convince the postfix developers it's important enough to
do themselves (SRS along won't be enough)

> When I tell customers to use SPF to prevent forged spams from their
> ids , they simply give the forwarding excuse not to use SPF

For many domains forwarding is a detail. I've had approximately a handful of
forwarding related problems in the nearly 4 years I've had a -all SPF record.

> How do you guys handle the situation
>
I tend to tell them this may happen, but in the scheme of email delivery
problems it's a noise level issue for most domains.

Scott K

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

I am using mime-defang to change the envelope sender for all incoming emails that will be forwarded to an external email address. Sendmal 8.14 added a feature that allows mime-defang to change the envelope sender.

Jim

________________________________________
From: ram [ram@netcore.co.in]
Sent: Tuesday, February 26, 2008 6:57 AM
To: spf-discuss@v2.listbox.com
Subject: [spf-discuss] Top problems with SPF acceptance

I think the oft repeated "SPF-breaks-forwarding" and
"Use-SRS-when-frowarding" is the still top problems for SPF acceptance.

The next big hurdle is when ISP's block smtp access to corporate
mailservers and force the corporates to include a plethora of IP into
their SPF


Regarding the first problem
I am using Postfix and cyrus on my mailserver and use sieve rules for
forwarding. Frustratingly even though SRS has been around for ages now
there is not a single implementation of SRS for my setup. I remember
trying some smtp milter but that never worked


When I tell customers to use SPF to prevent forged spams from their
ids , they simply give the forwarding excuse not to use SPF


How do you guys handle the situation

Thanks
Ram

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?&
Powered by Listbox: http://www.listbox.com

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

Jim Hermann wrote:
> I am using mime-defang to change the envelope sender for all
> incoming emails that will be forwarded to an external email
> address.

I'd be curious to know how do you choose the replacement; is it a
fixed mailbox, SRS, or something else? And how do you know, before
delivering, that a given message will be forwarded outside?

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

On Tue, 26 Feb 2008, ram wrote:

> When I tell customers to use SPF to prevent forged spams from their
> ids , they simply give the forwarding excuse not to use SPF

The forwarding excuse is a practical reason why *checking* SPF can
be hard for some large ESPs. But it is not relevant for senders - there
is no need to worry about forwarding for publishing an SPF record.

Sure, some stupid/overworked admin could screw up the mail - but they do that
all the time anyway with or without SPF.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

--On 26 February 2008 10:01:02 -0500 Scott Kitterman <scott@kitterman.com>
wrote:

> On Tuesday 26 February 2008 07:57, ram wrote:
>> I think the oft repeated "SPF-breaks-forwarding" and
>> "Use-SRS-when-frowarding" is the still top problems for SPF acceptance.
>>
>> The next big hurdle is when ISP's block smtp access to corporate
>> mailservers and force the corporates to include a plethora of IP into
>> their SPF
>
> Use the submission port, port 587. That's virtually never blocked.

Where it is blocked, it means that the institution is forbidding you to use
third party email domains. ISPs should not do that, but companies with
security worries may do so.




--
Ian Eiloart
IT Services, University of Sussex
x3148

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

On Wednesday 27 February 2008 04:44, Ian Eiloart wrote:
> --On 26 February 2008 10:01:02 -0500 Scott Kitterman <scott@kitterman.com>
>
> wrote:
> > On Tuesday 26 February 2008 07:57, ram wrote:
> >> I think the oft repeated "SPF-breaks-forwarding" and
> >> "Use-SRS-when-frowarding" is the still top problems for SPF acceptance.
> >>
> >> The next big hurdle is when ISP's block smtp access to corporate
> >> mailservers and force the corporates to include a plethora of IP into
> >> their SPF
> >
> > Use the submission port, port 587. That's virtually never blocked.
>
> Where it is blocked, it means that the institution is forbidding you to use
> third party email domains. ISPs should not do that, but companies with
> security worries may do so.

Actually one of the few places I've had a customer run into problems was a
hotel in Paris that silently redirected port 587 to their mail servers. The
solution was to support an unpriviledged port. Technically this makes no
sense for the hotel to do it, but who knows what people do in the search for
solutions.

In another case it was blocked I told the customer to tell the hotel that
blocking 587 made no sense and they should unblock it. The hotel did so.

The largest case where it's blocked (AFAIK, I've never tested it myself) is
the Great Firewall of China.

Scott K

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

On Tue, 2008-02-26 at 10:01 -0500, Scott Kitterman wrote:
> On Tuesday 26 February 2008 07:57, ram wrote:
> > I think the oft repeated "SPF-breaks-forwarding" and
> > "Use-SRS-when-frowarding" is the still top problems for SPF acceptance.
> >
> > The next big hurdle is when ISP's block smtp access to corporate
> > mailservers and force the corporates to include a plethora of IP into
> > their SPF
>
> Use the submission port, port 587. That's virtually never blocked.
>
> >
> > Regarding the first problem
> > I am using Postfix and cyrus on my mailserver and use sieve rules for
> > forwarding. Frustratingly even though SRS has been around for ages now
> > there is not a single implementation of SRS for my setup. I remember
> > trying some smtp milter but that never worked
>
> Postfix still (unless it's in 2.5, I haven't looked) lacks a way for external
> programs to rewrite mail from so you'd need to do it with a transparent
> filter. There's been some disucssion about this being a good feature to have
> (for more than just SRS) on postfix-users, but someone either needs to
> provide a patch or convince the postfix developers it's important enough to
> do themselves (SRS along won't be enough)

I am surely missing something. Why should SRS be handled by the MTA ?

On the postfix list you got a reply from He-Who-Shall-Not-Be-Named :-)
He was clearly not interested in implementing SRS.


Why not cyrus-sieve send the forwarded message with the from id changed
as required

Thanks
Ram




-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

On Wed, 27 Feb 2008, ram wrote:

> On the postfix list you got a reply from He-Who-Shall-Not-Be-Named :-)
> He was clearly not interested in implementing SRS.

He *shouldn't* be interested in implementing SRS. That is a very
application specific hack. He *should* be interested in allowing
user extensions (via postfix policy daemons or milter api) to
modify MAIL FROM.

Proposals should distance themselves from specific applications. If an example
is needed to show why it would be useful to modify MAIL FROM, pick
one like BATV, since SRS seems to have accumulated bad vibes in his mind.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

Sent: Tuesday, February 26, 2008 11:26 AM
To: spf-discuss@v2.listbox.com
Subject: Re: [spf-discuss] Top problems with SPF acceptance

Jim Hermann wrote:
> I am using mime-defang to change the envelope sender for all
> incoming emails that will be forwarded to an external email
> address.

I'd be curious to know how do you choose the replacement; is it a
fixed mailbox, SRS, or something else? And how do you know, before
delivering, that a given message will be forwarded outside?

-------------------------------------------

I am using Mail::SRS and Mail::ExpandAliases

Jim

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

On Tuesday 26 February 2008 10:01, Scott Kitterman wrote:
> On Tuesday 26 February 2008 07:57, ram wrote:
> > I think the oft repeated "SPF-breaks-forwarding" and
> > "Use-SRS-when-frowarding" is the still top problems for SPF acceptance.
> >
> > The next big hurdle is when ISP's block smtp access to corporate
> > mailservers and force the corporates to include a plethora of IP into
> > their SPF
>
> Use the submission port, port 587. That's virtually never blocked.
>
> > Regarding the first problem
> > I am using Postfix and cyrus on my mailserver and use sieve rules for
> > forwarding. Frustratingly even though SRS has been around for ages now
> > there is not a single implementation of SRS for my setup. I remember
> > trying some smtp milter but that never worked
>
> Postfix still (unless it's in 2.5, I haven't looked) lacks a way for
> external programs to rewrite mail from so you'd need to do it with a
> transparent filter. There's been some disucssion about this being a good
> feature to have (for more than just SRS) on postfix-users, but someone
> either needs to provide a patch or convince the postfix developers it's
> important enough to do themselves (SRS along won't be enough)

FYI, a Debian user of the Postfix policy servers pointed me at this today:

http://blog.madism.org/index.php/2007/08/29/136-postfix-and-srs

Perhaps an answer is coming soon.

Scott K

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

RFC 4405 (SUBMITTER) seems to me a good, workable idea that when combined
with SPF, could go a long way toward solving "the forwarding problem".

Is this getting any traction, and if not, why not?

-dgl-

>I think the oft repeated "SPF-breaks-forwarding" and
>"Use-SRS-when-frowarding" is the still top problems for SPF acceptance.
>
>The next big hurdle is when ISP's block smtp access to corporate
>mailservers and force the corporates to include a plethora of IP into
>their SPF
>
>
>Regarding the first problem
>I am using Postfix and cyrus on my mailserver and use sieve rules for
>forwarding. Frustratingly even though SRS has been around for ages now
>there is not a single implementation of SRS for my setup. I remember
>trying some smtp milter but that never worked
>
>
>When I tell customers to use SPF to prevent forged spams from their
>ids , they simply give the forwarding excuse not to use SPF
>
>
>How do you guys handle the situation
>
>Thanks
>Ram
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org
>Archives: http://www.listbox.com/member/archive/735/=now
>RSS Feed: http://www.listbox.com/member/archive/rss/735/
>Modify Your Subscription: http://www.listbox.com/member/?&
>Powered by Listbox: http://www.listbox.com

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

On Sunday 02 March 2008 14:40, Don Lee wrote:
> RFC 4405 (SUBMITTER) seems to me a good, workable idea that when combined
> with SPF, could go a long way toward solving "the forwarding problem".
>
> Is this getting any traction, and if not, why not?

No.

1. Proposed by Microsoft to solve problems with SenderID. Tied irretrevably
to their Sender ID PRA patents.

2. Replaces an SPF check of Mail From with a new arbitrary identity that can
only be verified by accepting the body of the message.

If you like Submitter, just do Sender ID. It'll do a good job of ensuring no
one abuses your domain name in resent-sender.

Scott K

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

>On Sunday 02 March 2008 14:40, Don Lee wrote:
>> RFC 4405 (SUBMITTER) seems to me a good, workable idea that when combined
>> with SPF, could go a long way toward solving "the forwarding problem".
>>
>> Is this getting any traction, and if not, why not?
>
>No.
>
>1. Proposed by Microsoft to solve problems with SenderID. Tied irretrevably
>to their Sender ID PRA patents.
>
>2. Replaces an SPF check of Mail From with a new arbitrary identity that can
>only be verified by accepting the body of the message.
>
>If you like Submitter, just do Sender ID. It'll do a good job of ensuring no
>one abuses your domain name in resent-sender.
>
>Scott K

Too bad. The basic idea is straightforward and has advantages in both
implementation and deployment.

-dgl-

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

On Sun, 2 Mar 2008 19:20:33 -0600 Don Lee <spfdiscuss@caution.icompute.com>
wrote:
>>On Sunday 02 March 2008 14:40, Don Lee wrote:
>>> RFC 4405 (SUBMITTER) seems to me a good, workable idea that when
combined
>>> with SPF, could go a long way toward solving "the forwarding problem".
>>>
>>> Is this getting any traction, and if not, why not?
>>
>>No.
>>
>>1. Proposed by Microsoft to solve problems with SenderID. Tied
irretrevably
>>to their Sender ID PRA patents.
>>
>>2. Replaces an SPF check of Mail From with a new arbitrary identity that
can
>>only be verified by accepting the body of the message.
>>
>>If you like Submitter, just do Sender ID. It'll do a good job of
ensuring no
>>one abuses your domain name in resent-sender.
>>
>>Scott K
>
>Too bad. The basic idea is straightforward and has advantages in both
>implementation and deployment.
>
>-dgl-

During the IETF MARID working group I suggested that and Microsoft declined
to separate it from PRA.

Scott K

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

On Sun, 2 Mar 2008, Don Lee wrote:
> [.... regarding RFC 4405 as a solution to the forwarding problem ...]
> Too bad. The basic idea is straightforward and has advantages in both
> implementation and deployment.

Have people forgotten about my SWK-SPF proposal already?

ftp://ftp.ocis.net/pub/users/ldeutsch/beta/swkspf-0.0.txt

It has all the benefits of SUBMITTER regarding the forwarding problems,
but does not require that the extra envelope address be held in lockstep
with the RFC822 headers. Thus, a forwarder does not need to rewrite the
message body, and nobody needs to use the patented PRA algorithm.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

Don Lee wrote:

> The basic idea is straightforward and has advantages in both
> implementation and deployment.

Apparently straightforward, but actually it's a SenderID hack.

For SPF FAIL and RFC 821 compatibility forwarders need to do
"something" with the MAIL FROM. By definition redistributors
work "as is".

For PRA FAIL forwarders *and* mailing lists have to update the
PRA, e.g., add Resent-* header fields as specified in RFC 4406.

After they have done that they can try to use the "Submitter"
in RFC 4405 with servers supporting it. But this is only a
shortcut allowing to reject an obviously FAILing PRA before
the server sees the message DATA with the "real" PRA.

If "Submitter" doesn't trigger a PRA FAIL - the bad guys could
make sure that "Submitter" won't fail - the server still has
to check that the "real" PRA matches the alleged "Submitter".

And for that more important check forwarders and mailing lists
have to modify the message header, see above. Modifying the
message header above what is permitted in 2821bis and 2822upd
is a legal rathole.

In practice I don't see why enough SMTP servers would wish to
support the "Submitter" shortcut when they have to check the
DATA with the PRA anyway (if the "Submitter" doesn't fail).

It is actually *THE* problem with PRA (SenderID), unlike SPF
PRA only works after worldwide deployment, it is a "FUSSP".

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

At 11:35 AM +0100 3/3/08, Frank Ellermann wrote:
>Don Lee wrote:
>
>> The basic idea is straightforward and has advantages in both
>> implementation and deployment.
>
>Apparently straightforward, but actually it's a SenderID hack.
>
>For SPF FAIL and RFC 821 compatibility forwarders need to do
>"something" with the MAIL FROM. By definition redistributors
>work "as is".
>
>For PRA FAIL forwarders *and* mailing lists have to update the
>PRA, e.g., add Resent-* header fields as specified in RFC 4406.
>
>After they have done that they can try to use the "Submitter"
>in RFC 4405 with servers supporting it. But this is only a
>shortcut allowing to reject an obviously FAILing PRA before
>the server sees the message DATA with the "real" PRA.
>
>If "Submitter" doesn't trigger a PRA FAIL - the bad guys could
>make sure that "Submitter" won't fail - the server still has
>to check that the "real" PRA matches the alleged "Submitter".
>
>And for that more important check forwarders and mailing lists
>have to modify the message header, see above. Modifying the
>message header above what is permitted in 2821bis and 2822upd
>is a legal rathole.
>
>In practice I don't see why enough SMTP servers would wish to
>support the "Submitter" shortcut when they have to check the
>DATA with the PRA anyway (if the "Submitter" doesn't fail).
>
>It is actually *THE* problem with PRA (SenderID), unlike SPF
>PRA only works after worldwide deployment, it is a "FUSSP".
>
> Frank


Potentially, though, SUBMITTER could be checked instead of Mail from:.
This presumes that each server in the chain is willing to take responsibility
for the message, and does not handle end-to-end checking, but would at
least provide a reliable one-hop solution for SPF checking that does not
have "forwarding problems".

It's dead. I'll file it appropritately.

Thanks all for the enlightenment.

-dgl-

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

Don Lee wrote:

[Quotes rearranged]
> It's dead. I'll file it appropritately.

+1 It's still possible to create a similar SMTP extension
with another name for slightly different purposes. On the
DKIM list Hector proposed a kind of SSP-accelerator using
the "submitter" idea. There was no much discussion because
SSP had more pressing problems than optional optimizations.

Some years ago William proposed a different "submitter" on
the former MARID list with a new spf2.0/submit identity, I
forgot the details, but folks here including Wayne and me
considered it as redundant wrt v=spf1 and its Mail From:

http://tools.ietf.org/html/draft-leibzon-responsible-submitter

And recently there was a Tenbox proposal in this direction,
I'll try to look at it again when it hits IETF servers in
the form of an Internet Draft.

> Potentially, though, SUBMITTER could be checked instead of
> Mail from:. This presumes that each server in the chain is
> willing to take responsibility for the message, and does
> not handle end-to-end checking, but would at least provide
> a reliable one-hop solution for SPF checking that does not
> have "forwarding problems".

I very much doubt it. The mail architecture offers MAIL FROM
to report problems and indicate responsibility, tons of RFCs
down to "mail disposition notifications", "sieve vacation",
"delivery status notifications", etc. all rely on no nonsense
MAIL FROM envelope sender addresses. And SPF PASS + FAIL is
the only way to get this today, after RFC 821 was mutilated
by RFC 1123 5.3.6(a) 19 year ago, and the spammers figured it
out about seven years ago. The concept of "forwarding" as it
was known before RFC 1123 5.3.6(a) does not work any more,
"forwarding" is now a part of the problem, like open relays.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

On Tue, 4 Mar 2008, Frank Ellermann wrote:
> And recently there was a Tenbox proposal in this direction,
> I'll try to look at it again when it hits IETF servers in
> the form of an Internet Draft.

SWK-SPF is unlikely to "hit IETF servers in the form of an Internet Draft",
since I'm allergic to RFC lawyering and ignorant of the procedures involved.
If it ever does, it will be because someone else who isn't allergic took an
interest.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com

On Wed, 2008-02-27 at 08:09 -0500, Scott Kitterman wrote:
> The largest case where it's blocked (AFAIK, I've never tested it
> myself) is the Great Firewall of China.

The behaviour of the Chinese firewall varies over time, but I don't
think I've ever known port 587 to be blocked.

--
dwmw2

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com