Re: [Declude.JunkMail] DELETE_RECIPIENT ?

[Matt]

Kami,

It would be like so:

TESTNAME   DELETE_RECIPIENT

This is used just like the DELETE action but with a BIG caveat.  This
only applies after the ROUTETO action handles the message, and you
can't let the weights for a ROUTETO test and DELETE_RECIPIENT overlap. 
They initially changed the DELETE action to act this way, but in 2.0.6
they changed DELETE back to the original way and created this new
action with this functionality.

Let me give you an example.  Let's say that you had the following
weight tests:

    WEIGHT-CAPTURE       weight        x    x    25    0
    WEIGHT-DELETE          weight        x    x    50    0

A message scoring 60 would fail both weight tests.  Your JunkMail file
might look like so:

    WEIGHT-CAPTURE   ROUTETO   [EMAIL PROTECTED]
    WEIGHT-DELETE   DELETE

So a message scoring 60 would be deleted since DELETE overrides the
ROUTETO test.  With DELETE_RECIPIENTS however, you might have the
following:

    WEIGHT-CAPTURE   ROUTETO   [EMAIL PROTECTED]
    WEIGHT-DELETE   DELETE_RECIPIENTS

The trick here is that since the DELETE_RECIPIENTS action only applies
to the recipients after ROUTETO changes the recipients, it might not
delete the recipients as desired.  It all depends on where the ROUTETO
test is routing the message to, in this case the JunkMail configuration
file that applies to [EMAIL PROTECTED].  I'm not sure that it will even
DELETE the message once ROUTETO has been applied.

Basically, you want to be very, very careful about using this with
overlapping weight tests and the ROUTETO and COPYTO actions because
they might be applied to the E-mail when you are not expecting them to
as is the case with DELETE, and it won't delete the recipients if the
recipient in question is changed by ROUTETO.

This caused a lot of confusion in the early 2.x versions when they
changed the behavior of DELETE and before they changed it back.  There
was a steady stream of posts to the lists from people confused as to
why E-mail was not being handled as it was expected.  The functionality
has merits, but it wasn't thought out fully as to how it would
interferer with existing configurations when letting the ROUTETO and
COPYTO actions override the DELETE functionality.

So will this work in your config?  Well, it all depends on your exact
config from the weight and weightrange settings in the Global.cfg to
the actions that you have applied in your JunkMail files.

Matt




Kami Razvan wrote:

  
  
  
  Thanks John..
   
  Hard to figure that out from the manual.
   
  so in the default file I should have:
   
  test_name    delete_recipient    [EMAIL PROTECTED]
   
  Is that correct?
   
  Regards,
  - Kami
  
  
  From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of John
T (Lists)
  Sent: Saturday, March 04, 2006 4:26 PM
  To: Declude.JunkMail@declude.com
  Subject: RE: [Declude.JunkMail] DELETE_RECIPIENT ?
  
  
  
  DELETE_RECIPIENT
is a ACTION.
   
  
  John T
  eServices
For You
   
  "Seek, and
ye shall find!"
  
   
  
  -Original
Message-
  From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Kami Razvan
  Sent: Saturday, March 04, 2006 1:03 PM
  To:
Declude.JunkMail@declude.com
  Subject:
[Declude.JunkMail] DELETE_RECIPIENT ?
   
  
  Hi;
  
  
   
  
  
  I can't find anything
on how to write the filter for: DELETE_RECIPIENT in the manual.
  
  
   
  
  
  Is DELETE_RECIPIENT
designed for filters?
  
  
   
  
  
  what is the syntax?
  
  
   
  
  
  DELETE_RECIPIENT  [EMAIL PROTECTED]
  
  
   
  
  
  I have written a filter
to remove a certain email from the list if the email is originating
from a certain email address.  Using DELETE_RECIPIENT I can't quite
think of how the syntax should be ..
  
  
   
  
  
  Regards,
  
  
  - Kami
  
  
  

RE: [Declude.JunkMail] DELETE_RECIPIENT ?

[John T \(Lists\)]

I believe you just use DELETE_RECEIPIENT,
although admittedly now that you question in it need to do more testing. 

 

Hopefully Declude will say for sure
Monday morning.

 



John T

eServices For You

 

"Seek, and ye shall
find!"



 



-Original Message-
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kami Razvan
Sent: Saturday, March
 04, 2006 1:37 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail]
DELETE_RECIPIENT ?

 

Thanks John..

 

Hard to figure that out from the manual.

 

so in the default file I should have:

 

test_name   
delete_recipient    [EMAIL PROTECTED]

 

Is that correct?

 

Regards,

- Kami

 







From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John T (Lists)
Sent: Saturday, March
 04, 2006 4:26 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail]
DELETE_RECIPIENT ?

DELETE_RECIPIENT is a ACTION.

 



John T

eServices For You

 

"Seek, and ye shall
find!"



 



-Original Message-
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kami Razvan
Sent: Saturday, March
 04, 2006 1:03 PM
To: Declude.JunkMail@declude.com
Subject: [Declude.JunkMail]
DELETE_RECIPIENT ?

 



Hi;





 





I can't find anything on how to write the filter for:
DELETE_RECIPIENT in the manual.





 





Is DELETE_RECIPIENT designed for filters?





 





what is the syntax?





 





DELETE_RECIPIENT  [EMAIL PROTECTED]





 





I have written a filter to remove a certain email from the
list if the email is originating from a certain email address.  Using
DELETE_RECIPIENT I can't quite think of how the syntax should be ..





 





Regards,





- Kami

RE: [Declude.JunkMail] spf breaks email forwarding -

[george kulman]

Hear hear.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-
> [EMAIL PROTECTED] On Behalf Of Matt
> Sent: Saturday, March 04, 2006 4:36 PM
> To: Declude.JunkMail@declude.com
> Subject: Re: [Declude.JunkMail] spf breaks email forwarding -
> 
> Someone could write a plug-in or Declude could be modified to handle this,
> or IMail could be modified to handle this (and then Declude would probably
> need to be updated to handle what IMail changed).
> 
> Why implement a work around in a standards compliant platform in order to
> deal with a flawed mechanism in use at another provider, when that
> mechanism is rare?  I would prefer that SPF just disappeared.  You will
> probably spend less time telling your client that their destination server
> has issues that you can't fix and that they should take it up with them.
> It is not your, my, nor anyone else's responsibility to implement SRS in
> the current framework.
> 
> SRS isn't a an RFC standard, in fact according to that page that you
> provided, it seems that they are moving towards the "SUBMITTER" parameter.
> Maybe people should have thought about these issues before rushing to
> support SPF in the first place?
> 
> SPF, in it's current form, will die.  Just give it time.  The more support
> that you give for it, the more resistance to change will exist.and the
> longer it will take for it to die.  The implementation of SPF was always
> severely flawed, and two years later, there has been hardly any progress
> at fixing those issues, and there are now several competing sender
> validation mechanisms, all of which are flawed in one way or another.  The
> technology is all ridiculously short-sighted.  It's a problem and not a
> solution.
> 
> Matt
> 
> 
> 
> Nick Hayer wrote:
> 
>   Matt wrote:
> 
>   Real-world issues include working around bad implementation,
> such as surfglobal.net not configuring their server to reject messages
> that fail SPF.
> 
> 
>   SRS is a work around - and I'm simply asking if anyone has
> implemented it on an Imail/Declude platform. Kindly stay on topic  I
> am aware of your feelings about SPF - all I'm doing is working out a
> solution with what is in place - an MTA bouncing my legit email.
> 
> 
> 
>   I suggest you tell your customer that they can't forward
their
> E-mail reliably unless surfglobal.net removes their SPF restrictions, and
> there is nothing that you can do about it.
> 
> 
>   Should I stamp my feet and make a face when I tell them that?  :)
> 
>   I can simply ask SurfGlobal to accept me as a trusted sender - but I
> am trying to avoid that via SRS - so I will not have to make that call or
> any others.
> 
>   -Nick
> 


---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] DELETE_RECIPIENT ?

[Kami Razvan]

Thanks John..
 
Hard to figure that out from the manual.
 
so in the default file I should have:
 
test_name    delete_recipient    [EMAIL PROTECTED]
 
Is that correct?
 
Regards,
- Kami


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of John T 
(Lists)Sent: Saturday, March 04, 2006 4:26 PMTo: 
Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] 
DELETE_RECIPIENT ?


DELETE_RECIPIENT is a 
ACTION.
 

John 
T
eServices For 
You
 
"Seek, and ye shall 
find!"
 

-Original 
Message-From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Kami 
RazvanSent: 
Saturday, March 04, 
2006 1:03 
PMTo: 
Declude.JunkMail@declude.comSubject: [Declude.JunkMail] 
DELETE_RECIPIENT ?
 

Hi;

 

I can't find anything on how to 
write the filter for: DELETE_RECIPIENT in the 
manual.

 

Is DELETE_RECIPIENT designed for 
filters?

 

what is the 
syntax?

 

DELETE_RECIPIENT  
[EMAIL PROTECTED]

 

I have written a filter to remove 
a certain email from the list if the email is originating from a certain email 
address.  Using DELETE_RECIPIENT I can't quite think of how the syntax 
should be ..

 

Regards,

- 
Kami

Re: [Declude.JunkMail] spf breaks email forwarding -

[Matt]

Someone could write a plug-in or Declude could be modified to handle
this, or IMail could be modified to handle this (and then Declude would
probably need to be updated to handle what IMail changed).

Why implement a work around in a standards compliant platform in order
to deal with a flawed mechanism in use at another provider, when that
mechanism is rare?  I would prefer that SPF just disappeared.  You will
probably spend less time telling your client that their destination
server has issues that you can't fix and that they should take it up
with them.  It is not your, my, nor anyone else's responsibility to
implement SRS in the current framework.

SRS isn't a an RFC standard, in fact according to that page that you
provided, it seems that they are moving towards the "SUBMITTER"
parameter.  Maybe people should have thought about these issues before
rushing to support SPF in the first place?

SPF, in it's current form, will die.  Just give it time.  The more
support that you give for it, the more resistance to change will
exist.and the longer it will take for it to die.  The implementation of
SPF was always severely flawed, and two years later, there has been
hardly any progress at fixing those issues, and there are now several
competing sender validation mechanisms, all of which are flawed in one
way or another.  The technology is all ridiculously short-sighted. 
It's a problem and not a solution.

Matt



Nick Hayer wrote:

  
  
Matt wrote:
  

Real-world issues include working around bad implementation, such as
surfglobal.net not configuring their server to reject messages that
fail SPF.
  
SRS is a work around - and I'm simply asking if anyone has implemented
it on an Imail/Declude platform. Kindly stay on topic  I am aware
of your feelings about SPF - all I'm doing is working out a solution
with what is in place - an MTA bouncing my legit email.
  
I suggest you tell your customer that they can't forward their E-mail
reliably unless surfglobal.net removes their SPF restrictions, and
there is nothing that you can do about it.
  
Should I stamp my feet and make a face when I tell them that?  :)
  
I can simply ask SurfGlobal to accept me as a trusted sender - but I am
trying to avoid that via SRS - so I will not have to make that call or
any others.
  
-Nick

RE: [Declude.JunkMail] DELETE_RECIPIENT ?

[John T \(Lists\)]

DELETE_RECIPIENT is a ACTION.

 



John T

eServices For You

 

"Seek, and ye shall
find!"



 



-Original Message-
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kami Razvan
Sent: Saturday, March
 04, 2006 1:03 PM
To: Declude.JunkMail@declude.com
Subject: [Declude.JunkMail] DELETE_RECIPIENT
?

 



Hi;





 





I can't find anything on how to write the filter for:
DELETE_RECIPIENT in the manual.





 





Is DELETE_RECIPIENT designed for filters?





 





what is the syntax?





 





DELETE_RECIPIENT  [EMAIL PROTECTED]





 





I have written a filter to remove a certain email from the
list if the email is originating from a certain email address.  Using
DELETE_RECIPIENT I can't quite think of how the syntax should be ..





 





Regards,





- Kami

RE: [Declude.JunkMail] spf breaks email forwarding -

[John T \(Lists\)]

I was not referring to anything you are
doing, I was referring to the recipient domain doing a rejection based upon a
SPF fail.

 



John T

eServices For You

 

"Seek, and ye shall
find!"



 



-Original Message-
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Hayer
Sent: Saturday, March 04, 2006 12:27 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail]
spf breaks email forwarding -

 

The problem is not anything I am doing - it with SPF
itself. By design forwarded email will bounce if the receiving MTA is configed
that way. Even if I whitelist the emails they will bounce...

Let me explain - 
@Adelphia.net send an email to @greenmountainhealth.com
which is an alias on my server that forwards to @surfglobal.net
SurfGlobal will bounce the email because it failed Adelphia's SPF.
Perfectly legit email - my spf recs are perfect etc. The solution is SRS -
otherwise forwarding is dead 

-Nick


John T (Lists) wrote: 

I think the underlying problem as has been discussed on this list is that anSPF FAIL should not be relied upon as an outright rejection, rather used aspart of a weighting system. John TeServices For You "Seek, and ye shall find!"   

-Original Message-From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-[EMAIL PROTECTED]] On Behalf Of Nick HayerSent: Saturday, March 04, 2006 11:40 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] spf breaks email forwarding - Email customers that forward through me are getting their email bouncedbecause of the original sending domain's spf policy.  I understand thisdelima is addressed with "Sender Rewriting Scheme"http://www.openspf.org/srs.html Does anyone have a solution to this w/Declude & Imail? Thanks -Nick---This E-mail came from the Declude.JunkMail mailing list.  Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail".  The archives can be foundat http://www.mail-archive.com.    

 ---This E-mail came from the Declude.JunkMail mailing list.  Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail".  The archives can be foundat http://www.mail-archive.com.    

Re: [Declude.JunkMail] spf breaks email forwarding -

[Nick Hayer]

Matt wrote:

  
Real-world issues include working around bad implementation, such as
surfglobal.net not configuring their server to reject messages that
fail SPF.

SRS is a work around - and I'm simply asking if anyone has implemented
it on an Imail/Declude platform. Kindly stay on topic  I am aware
of your feelings about SPF - all I'm doing is working out a solution
with what is in place - an MTA bouncing my legit email.

I suggest you tell your customer that they can't forward their E-mail
reliably unless surfglobal.net removes their SPF restrictions, and
there is nothing that you can do about it.

Should I stamp my feet and make a face when I tell them that?  :)

I can simply ask SurfGlobal to accept me as a trusted sender - but I am
trying to avoid that via SRS - so I will not have to make that call or
any others.

-Nick

[Declude.JunkMail] DELETE_RECIPIENT ?

[Kami Razvan]

Hi;
 
I can't find 
anything on how to write the filter for: DELETE_RECIPIENT in the 
manual.
 
Is 
DELETE_RECIPIENT designed for filters?
 
what is the 
syntax?
 
DELETE_RECIPIENT  [EMAIL PROTECTED]
 
I have written a 
filter to remove a certain email from the list if the email is originating from 
a certain email address.  Using DELETE_RECIPIENT I can't quite think of how 
the syntax should be ..
 
Regards,
- 
Kami

RE: [Declude.JunkMail] spf breaks email forwarding -

[george kulman]

Nick,

Sorry about my last email.  I thought you were referring to outbound
forwarding, not inbound.

George

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-
> [EMAIL PROTECTED] On Behalf Of Nick Hayer
> Sent: Saturday, March 04, 2006 3:27 PM
> To: Declude.JunkMail@declude.com
> Subject: Re: [Declude.JunkMail] spf breaks email forwarding -
> 
> The problem is not anything I am doing - it with SPF itself. By design
> forwarded email will bounce if the receiving MTA is configed that way.
> Even if I whitelist the emails they will bounce...
> 
> Let me explain -
> @Adelphia.net send an email to @greenmountainhealth.com which
> is an alias on my server that forwards to @surfglobal.net
> SurfGlobal will bounce the email because it failed Adelphia's SPF.
> Perfectly legit email - my spf recs are perfect etc. The solution is SRS -
> otherwise forwarding is dead
> 
> -Nick
> 
> 
> John T (Lists) wrote:
> 
>   I think the underlying problem as has been discussed on this list is
> that an
>   SPF FAIL should not be relied upon as an outright rejection, rather
> used as
>   part of a weighting system.
> 
>   John T
>   eServices For You
> 
>   "Seek, and ye shall find!"
> 
> 
> 
>   -Original Message-
>   From: [EMAIL PROTECTED]
> [mailto:Declude.JunkMail-
>   [EMAIL PROTECTED] On Behalf Of Nick Hayer
>   Sent: Saturday, March 04, 2006 11:40 AM
>   To: Declude.JunkMail@declude.com
>   Subject: [Declude.JunkMail] spf breaks email forwarding -
> 
>   Email customers that forward through me are getting their
> email bounced
>   because of the original sending domain's spf policy.  I
> understand this
>   delima is addressed with "Sender Rewriting Scheme"
>   http://www.openspf.org/srs.html
> 
>   Does anyone have a solution to this w/Declude & Imail?
> 
>   Thanks
> 
>   -Nick
>   ---
>   This E-mail came from the Declude.JunkMail mailing list.  To
>   unsubscribe, just send an E-mail to [EMAIL PROTECTED],
and
>   type "
>  il?Thanks-Nick---ThisE-
> mailcamefromtheDeclude.JunkMailmailinglist.Tounsubscribe,justsendanE-
> [EMAIL PROTECTED],andtype> unsubscribe Declude.JunkMail".  The
> archives can be found
>   at http://www.mail-archive.com.
> 
> 
> 
>   ---
>   This E-mail came from the Declude.JunkMail mailing list.  To
>   unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
>   type "unsubscribe Declude.JunkMail".  The archives can be found
>   at http://www.mail-archive.com.
> 
> 
> 


---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] spf breaks email forwarding -

[george kulman]

Nick,

What I've done, and I can't be sure its working, is to set up my client's
SPF records like this:

v=spf1 ip4:[my ip mx range] ip4:[client ip mx range] mx ~all

The range format is nnn.nnn.nnn.nnn/nn

I haven't had complaints about SPF rejects.

George


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-
> [EMAIL PROTECTED] On Behalf Of Nick Hayer
> Sent: Saturday, March 04, 2006 2:40 PM
> To: Declude.JunkMail@declude.com
> Subject: [Declude.JunkMail] spf breaks email forwarding -
> 
> Email customers that forward through me are getting their email bounced
> because of the original sending domain's spf policy.  I understand this
> delima is addressed with "Sender Rewriting Scheme"
> http://www.openspf.org/srs.html
> 
> Does anyone have a solution to this w/Declude & Imail?
> 
> Thanks
> 
> -Nick
> ---
> This E-mail came from the Declude.JunkMail mailing list.  To
> unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
> type "unsubscribe Declude.JunkMail".  The archives can be found
> at http://www.mail-archive.com.

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] spf breaks email forwarding -

[Matt]

Real-world issues include working around bad implementation, such as
surfglobal.net not configuring their server to reject messages that
fail SPF.

SPF has many real-world issues.  SRS is novel, but it is impractical
since no one supports it (that I am aware of), and it certainly won't
be globally available any time soon.

I suggest you tell your customer that they can't forward their E-mail
reliably unless surfglobal.net removes their SPF restrictions, and
there is nothing that you can do about it.

SPF is not a magic bullet.

Matt



Nick Hayer wrote:

  
The problem is not anything I am doing - it with SPF itself. By design
forwarded email will bounce if the receiving MTA is configed that way.
Even if I whitelist the emails they will bounce...
  
Let me explain - 
@Adelphia.net send an email to
@greenmountainhealth.com which is an alias on my server
that forwards to @surfglobal.net
SurfGlobal will bounce the email because it failed Adelphia's SPF.
Perfectly legit email - my spf recs are perfect etc. The solution is
SRS - otherwise forwarding is dead 
  
-Nick
  
  
John T (Lists) wrote:
  
I think the underlying problem as has been discussed on this list is that an
SPF FAIL should not be relied upon as an outright rejection, rather used as
part of a weighting system.

John T
eServices For You

"Seek, and ye shall find!"

  

  -Original Message-
From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-
[EMAIL PROTECTED]] On Behalf Of Nick Hayer
Sent: Saturday, March 04, 2006 11:40 AM
To: Declude.JunkMail@declude.com
Subject: [Declude.JunkMail] spf breaks email forwarding -

Email customers that forward through me are getting their email bounced
because of the original sending domain's spf policy.  I understand this
delima is addressed with "Sender Rewriting Scheme"
http://www.openspf.org/srs.html

Does anyone have a solution to this w/Declude & Imail?

Thanks

-Nick
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.



---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.


  
  

Re: [Declude.JunkMail] spf breaks email forwarding -

[Nick Hayer]

The problem is not anything I am doing - it with SPF itself. By design
forwarded email will bounce if the receiving MTA is configed that way.
Even if I whitelist the emails they will bounce...

Let me explain - 
@Adelphia.net send an email to
@greenmountainhealth.com which is an alias on my server
that forwards to @surfglobal.net
SurfGlobal will bounce the email because it failed Adelphia's SPF.
Perfectly legit email - my spf recs are perfect etc. The solution is
SRS - otherwise forwarding is dead 

-Nick


John T (Lists) wrote:

  I think the underlying problem as has been discussed on this list is that an
SPF FAIL should not be relied upon as an outright rejection, rather used as
part of a weighting system.

John T
eServices For You

"Seek, and ye shall find!"

  
  
-Original Message-
From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-
[EMAIL PROTECTED]] On Behalf Of Nick Hayer
Sent: Saturday, March 04, 2006 11:40 AM
To: Declude.JunkMail@declude.com
Subject: [Declude.JunkMail] spf breaks email forwarding -

Email customers that forward through me are getting their email bounced
because of the original sending domain's spf policy.  I understand this
delima is addressed with "Sender Rewriting Scheme"
http://www.openspf.org/srs.html

Does anyone have a solution to this w/Declude & Imail?

Thanks

-Nick
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

  
  
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.


  

Re: [Declude.JunkMail] spf breaks email forwarding -

[Matt]

I'm not aware of any mail server that supports the Sender Rewriting 
Scheme.  It's certainly a fine idea, but the real issue is that the SPF 
implementation has issues with forwarded E-mail, and they are seeking to 
have mail servers correct their shortcoming.  It may be a very long-time 
in coming if it ever gets here at all.


IMO, real-world issues demand real-world solutions.

Matt



Nick Hayer wrote:

Email customers that forward through me are getting their email 
bounced because of the original sending domain's spf policy.  I 
understand this delima is addressed with "Sender Rewriting Scheme"  
http://www.openspf.org/srs.html


Does anyone have a solution to this w/Declude & Imail?

Thanks

-Nick
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.



---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] spf breaks email forwarding -

[John T \(Lists\)]

I think the underlying problem as has been discussed on this list is that an
SPF FAIL should not be relied upon as an outright rejection, rather used as
part of a weighting system.

John T
eServices For You

"Seek, and ye shall find!"

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-
> [EMAIL PROTECTED] On Behalf Of Nick Hayer
> Sent: Saturday, March 04, 2006 11:40 AM
> To: Declude.JunkMail@declude.com
> Subject: [Declude.JunkMail] spf breaks email forwarding -
> 
> Email customers that forward through me are getting their email bounced
> because of the original sending domain's spf policy.  I understand this
> delima is addressed with "Sender Rewriting Scheme"
> http://www.openspf.org/srs.html
> 
> Does anyone have a solution to this w/Declude & Imail?
> 
> Thanks
> 
> -Nick
> ---
> This E-mail came from the Declude.JunkMail mailing list.  To
> unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
> type "unsubscribe Declude.JunkMail".  The archives can be found
> at http://www.mail-archive.com.

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

[Declude.JunkMail] spf breaks email forwarding -

[Nick Hayer]

Email customers that forward through me are getting their email bounced 
because of the original sending domain's spf policy.  I understand this 
delima is addressed with "Sender Rewriting Scheme"  
http://www.openspf.org/srs.html


Does anyone have a solution to this w/Declude & Imail?

Thanks

-Nick
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.