Re: [Declude.JunkMail] spf breaks email forwarding -
Wow thanks for the efforts here Andrew - Nice work!
-Nick
Colbeck, Andrew wrote:
Hey, Nick.
I spent some timepoking at this
with a stick.
Since I just use IMail as a
gateway so that I can use Declude... I've had no use for IMail
mailboxes or forwarding, so it was all new to me.
The real answer is that you
should lobby Ipswitch to implement that sender re-writing in their
forwarding (what the heck... all of SPF plus the bells and whistles
while they're at it). If you can garner support from other people to
make the same request, all the better.
You can also tell your client
"Sorry, Adelphia controls how [EMAIL PROTECTED]
email is moved around and since the destination you want adheres to
Adelphia's wishes,I can't forward it. However, if you do have Adelpha
forward the mail to me, I can filter out the spam and viruses, and you
can use POP/IMAP to retrievethe good mailfrom my server."
As a new policy, you would want
to double-check that any mailbox for which you do forwarding doesn't
send mail from some domain that has a tight SPF, or whomever you're
fowarding to (e.g. surfglobal.net) will see you as a spammer.
If you want to perservere and
build your own forwarding system, what I found was that:
1) Just doing a "forward" action
on a mailbox was functionally identical to making an IMailmailbox with
a rule that says "if sender email contains '@'
then forward the mail to [EMAIL PROTECTED]" and that this
forwardingviolates SPF for a domain like Adelphia.com.
2) It's not easy but it's not
impossible to instead use a Program Alias instead. That program alias
would call a batch file with optional parameters (let's say we provide
two in our configuration). That batch then receives a %3 parameter
added on that contains a tmp*.tmp filename which isreally a D*.SMD
file with a different name in the \imail\spool folder.
The first thing the
batch would do is some sanity checks.
You would have to avoid mail
loops and other badnessby making sure that this is a message that
should be forwarded, e.g. not a bounce message from whomever you're
forwarding messages to! If it is crap, it should delete the tmp*.tmp
file and exit.
The second thing the
script would do is manufacture a Q*.SMD file.
Since you've already got the
D*.SMD file, if you can just manufacture an appropriate Q*.SMD file,
you can have IMail re-send the message while passing on the complete
headers and without having to do any editing of the D*.SMD file
although there probably are useful smarty pants edits (e.g. changing
the "From:" line to something like "From: [EMAIL PROTECTED] on
behalf of [EMAIL PROTECTED]" orinserting the frills Received-SPF:
header).
Here's the format of the Q*.SMD
file, as per the venerable R. Scott Perry:
http://www.mail-archive.com/imail_forum@list.ipswitch.com/msg64280.html
The
"S" sender row would normally be[EMAIL PROTECTED]
but that violates SPF, so you instead specify [EMAIL PROTECTED]
there.
The "R" recipient row would then
be the 3rd party destination, e.g. [EMAIL PROTECTED]
In my testing it seemed that
also using the "N" original recipient row to the sender field would
preserve the "Reply-To:" as the original sender but that may have been
an artifact of bad thinking on my part (you'd best extract the original
Declude spoolname from the tmp*.tmp file and use that to extract the
MAILFROM for that message from the sys*.txt file! [To get that, you
must use the "XSENDERON" option in your global.cfg file])
The "Q" file row defines the
fully qualified name of the tmp*.tmp file and doesn't have to be D*.SMD
format; you can just specify the tmp*.tmp file here.
The "H" host row is just your
normal name for the IMail host.
The "I" guid row contains the
long id number that IMail will use in the sys*.txt file to identify
this message. Ideally this would be unique every time; however for
testing you could write out the same row every time.
Here's a sample:
QC:\IMail\spool\tmp1B.tmp
Hmail.madriver.com
Ic507787800822fbd
WC:\IMail
S[EMAIL PROTECTED]
NRCPT TO:[EMAIL PROTECTED]
R[EMAIL PROTECTED]
The third thing the
script would dois tohave IMail deliver the message.
Here's
how to re-queue a single Q*.SMD + D*.SMD pair:
http://support.ipswitch.com/kb/IM-2623-DM02.htm
The short version being that if
you make sure that the Q*.SMD file (which can be any filename) contains
the "Q" row and a fully qualified D*.SMD file (which can be any
filename) you can just call:
smtp32.exe Qxxx.SMD and
IMail will queue it up immediately.
Ta-dah! Easy as world peace.
Andrew 8)
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Nick
Hayer
Sent: Saturday, March 04, 2006 1:13 PM
To: Declude.JunkMa
Re: [Declude.JunkMail] spf breaks email forwarding -
Hi Sandy Sanford Whiteman wrote: Andrew, I like your workaround with the Program Alias. However, I think that instead, if people are willing to wait a few weeks to a month, I can find time to put out a full-fledged external test for Declude that does much the same thing, without having to forge brand-new Q files and so on, honoring IMail-level forwards. Although I am going to give Andrew's tactic a try now I would very much appreciate your external test when it becomes available. 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.
RE: [Declude.JunkMail] spf breaks email forwarding -
Hey, Nick. I spent some timepoking at this with a stick. Since I just use IMail as a gateway so that I can use Declude... I've had no use for IMail mailboxes or forwarding, so it was all new to me. The real answer is that you should lobby Ipswitch to implement that sender re-writing in their forwarding (what the heck... all of SPF plus the bells and whistles while they're at it). If you can garner support from other people to make the same request, all the better. You can also tell your client "Sorry, Adelphia controls how [EMAIL PROTECTED] email is moved around and since the destination you want adheres to Adelphia's wishes,I can't forward it. However, if you do have Adelpha forward the mail to me, I can filter out the spam and viruses, and you can use POP/IMAP to retrievethe good mailfrom my server." As a new policy, you would want to double-check that any mailbox for which you do forwarding doesn't send mail from some domain that has a tight SPF, or whomever you're fowarding to (e.g. surfglobal.net) will see you as a spammer. If you want to perservere and build your own forwarding system, what I found was that: 1) Just doing a "forward" action on a mailbox was functionally identical to making an IMailmailbox with a rule that says "if sender email contains '@' then forward the mail to [EMAIL PROTECTED]" and that this forwardingviolates SPF for a domain like Adelphia.com. 2) It's not easy but it's not impossible to instead use a Program Alias instead. That program alias would call a batch file with optional parameters (let's say we provide two in our configuration). That batch then receives a %3 parameter added on that contains a tmp*.tmp filename which isreally a D*.SMD file with a different name in the \imail\spool folder. The first thing the batch would do is some sanity checks. You would have to avoid mail loops and other badnessby making sure that this is a message that should be forwarded, e.g. not a bounce message from whomever you're forwarding messages to! If it is crap, it should delete the tmp*.tmp file and exit. The second thing the script would do is manufacture a Q*.SMD file. Since you've already got the D*.SMD file, if you can just manufacture an appropriate Q*.SMD file, you can have IMail re-send the message while passing on the complete headers and without having to do any editing of the D*.SMD file although there probably are useful smarty pants edits (e.g. changing the "From:" line to something like "From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]" orinserting the frills Received-SPF: header). Here's the format of the Q*.SMD file, as per the venerable R. Scott Perry: http://www.mail-archive.com/imail_forum@list.ipswitch.com/msg64280.html The "S" sender row would normally be[EMAIL PROTECTED] but that violates SPF, so you instead specify [EMAIL PROTECTED] there. The "R" recipient row would then be the 3rd party destination, e.g. [EMAIL PROTECTED] In my testing it seemed that also using the "N" original recipient row to the sender field would preserve the "Reply-To:" as the original sender but that may have been an artifact of bad thinking on my part (you'd best extract the original Declude spoolname from the tmp*.tmp file and use that to extract the MAILFROM for that message from the sys*.txt file! [To get that, you must use the "XSENDERON" option in your global.cfg file]) The "Q" file row defines the fully qualified name of the tmp*.tmp file and doesn't have to be D*.SMD format; you can just specify the tmp*.tmp file here. The "H" host row is just your normal name for the IMail host. The "I" guid row contains the long id number that IMail will use in the sys*.txt file to identify this message. Ideally this would be unique every time; however for testing you could write out the same row every time. Here's a sample: QC:\IMail\spool\tmp1B.tmpHmail.madriver.comIc507787800822fbdWC:\IMailS[EMAIL PROTECTED]NRCPT TO:[EMAIL PROTECTED]R[EMAIL PROTECTED] The third thing the script would dois tohave IMail deliver the message. Here's how to re-queue a single Q*.SMD + D*.SMD pair: http://support.ipswitch.com/kb/IM-2623-DM02.htm The short version being that if you make sure that the Q*.SMD file (which can be any filename) contains the "Q" row and a fully qualified D*.SMD file (which can be any filename) you can just call: smtp32.exe Qxxx.SMD and IMail will queue it up immediately. Ta-dah! Easy as world peace. Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick HayerSent: Saturday, March 04, 2006 1:13 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] spf breaks email forwarding - Matt wrote: Real-world issues include working around bad implementation, such as surfglobal.net
Re: [Declude.JunkMail] spf breaks email forwarding -
since the destination you want adheres to
Adelphia's wishes,I can't forward it. However, if you do have Adelpha
forward the mail to me, I can filter out the spam and viruses, and you
can use POP/IMAP to retrievethe good mailfrom my server."
As a new policy, you would want
to double-check that any mailbox for which you do forwarding doesn't
send mail from some domain that has a tight SPF, or whomever you're
fowarding to (e.g. surfglobal.net) will see you as a spammer.
If you want to perservere and
build your own forwarding system, what I found was that:
1) Just doing a "forward" action
on a mailbox was functionally identical to making an IMailmailbox with
a rule that says "if sender email contains '@'
then forward the mail to [EMAIL PROTECTED]" and that this
forwardingviolates SPF for a domain like Adelphia.com.
2) It's not easy but it's not
impossible to instead use a Program Alias instead. That program alias
would call a batch file with optional parameters (let's say we provide
two in our configuration). That batch then receives a %3 parameter
added on that contains a tmp*.tmp filename which isreally a D*.SMD
file with a different name in the \imail\spool folder.
The first thing the
batch would do is some sanity checks.
You would have to avoid mail
loops and other badnessby making sure that this is a message that
should be forwarded, e.g. not a bounce message from whomever you're
forwarding messages to! If it is crap, it should delete the tmp*.tmp
file and exit.
The second thing the
script would do is manufacture a Q*.SMD file.
Since you've already got the
D*.SMD file, if you can just manufacture an appropriate Q*.SMD file,
you can have IMail re-send the message while passing on the complete
headers and without having to do any editing of the D*.SMD file
although there probably are useful smarty pants edits (e.g. changing
the "From:" line to something like "From: [EMAIL PROTECTED] on
behalf of [EMAIL PROTECTED]" orinserting the frills Received-SPF:
header).
Here's the format of the Q*.SMD
file, as per the venerable R. Scott Perry:
http://www.mail-archive.com/imail_forum@list.ipswitch.com/msg64280.html
The
"S" sender row would normally be[EMAIL PROTECTED]
but that violates SPF, so you instead specify [EMAIL PROTECTED]
there.
The "R" recipient row would then
be the 3rd party destination, e.g. [EMAIL PROTECTED]
In my testing it seemed that
also using the "N" original recipient row to the sender field would
preserve the "Reply-To:" as the original sender but that may have been
an artifact of bad thinking on my part (you'd best extract the original
Declude spoolname from the tmp*.tmp file and use that to extract the
MAILFROM for that message from the sys*.txt file! [To get that, you
must use the "XSENDERON" option in your global.cfg file])
The "Q" file row defines the
fully qualified name of the tmp*.tmp file and doesn't have to be D*.SMD
format; you can just specify the tmp*.tmp file here.
The "H" host row is just your
normal name for the IMail host.
The "I" guid row contains the
long id number that IMail will use in the sys*.txt file to identify
this message. Ideally this would be unique every time; however for
testing you could write out the same row every time.
Here's a sample:
QC:\IMail\spool\tmp1B.tmp
Hmail.madriver.com
Ic507787800822fbd
WC:\IMail
S[EMAIL PROTECTED]
NRCPT TO:[EMAIL PROTECTED]
R[EMAIL PROTECTED]
The third thing the
script would dois tohave IMail deliver the message.
Here's
how to re-queue a single Q*.SMD + D*.SMD pair:
http://support.ipswitch.com/kb/IM-2623-DM02.htm
The short version being that if
you make sure that the Q*.SMD file (which can be any filename) contains
the "Q" row and a fully qualified D*.SMD file (which can be any
filename) you can just call:
smtp32.exe Qxxx.SMD and
IMail will queue it up immediately.
Ta-dah! Easy as world peace.
Andrew 8)
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Nick
Hayer
Sent: Saturday, March 04, 2006 1:13 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] spf breaks email forwarding -
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.
RE: [Declude.JunkMail] spf breaks email forwarding -
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 -
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 -
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 - user@Adelphia.net send an email to user@greenmountainhealth.com which is an alias on my server that forwards to user@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 -
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 - user@Adelphia.net send an email to user@greenmountainhealth.com which is an alias on my server that forwards to user@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, 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 -
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 - user@Adelphia.net send an email to user@greenmountainhealth.com which is an alias on my server that forwards to user@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 http://www.openspf.org/srs.htmlDoesanyonehaveasolutiontothisw/DecludeIma 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 -
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] spf breaks email forwarding -
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 - user@Adelphia.net send an email to user@greenmountainhealth.com which is an alias on my server that forwards to user@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 YouSeek, 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 Schemehttp://www.openspf.org/srs.htmlDoes 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 -
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] spf breaks email forwarding -
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.
