Mark Constable writes:
On 2008-08-27, Sam Varshavchik wrote:
> Is there a way to disable SPF checking on a host by host basis ?
Based on the sender's IP address -- set the BOFH variables in smtpaccess.
Thanks Sam, the nearest info I could find is here...
http://www.courier-mta.org/couriertc
On 2008-08-27, Sam Varshavchik wrote:
> > Is there a way to disable SPF checking on a host by host basis ?
> Based on the sender's IP address -- set the BOFH variables in smtpaccess.
Thanks Sam, the nearest info I could find is here...
http://www.courier-mta.org/couriertcpd.html
but I couldn't
Sam Varshavchik wrote:
> Bowie Bailey writes:
> > Sam Varshavchik wrote:
> > > As such, since the whole process is under the complete control of
> > > the recipient, the recipient must then recognize that SPF will not
> > > be functional on forwarded mail. The recipient must concede to
> > > disabl
Mark Constable writes:
Apologies for repeating this question...
Is there a way to disable SPF checking on a host by host basis ?
Based on the sender's IP address -- set the BOFH variables in smtpaccess.
pgpRnq2UjMpcQ.pgp
Description: PGP signature
-
Sam Varshavchik ha scritto:
> Alessandro Vesely writes:
>
>> Currently, the only way that one can concede forwarding is by IP address.
>
> That's beside the point.
It is a problem. What if the remote host could log in?
> The bottom line is this. Your email address is
> [EMAIL PROTECTED] If you
Apologies for repeating this question...
Is there a way to disable SPF checking on a host by host basis ?
--markc
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based a
Julian Mehnle wrote:
> Alessandro Vesely wrote:
>> Rewriting the sender's address currently works, but is wrong for
>> backup MXes. Isn't there room for designing a better solution?
>
> One should always be able to fully trust one's backup MXes, not only for
> _that_ reason but also because you w
Bowie Bailey writes:
Sam Varshavchik wrote:
Mail forwarding is not a random event. Mail forwarding occurs, presumably,
at the ultimate recipient's request. It is the ultimate recipient that
places the forwarding in place, so that the recipient's mail gets
forwarded
to a different destinat
Sam Varshavchik wrote:
>
> Mail forwarding is not a random event. Mail forwarding occurs, presumably,
> at the ultimate recipient's request. It is the ultimate recipient that
> places the forwarding in place, so that the recipient's mail gets
forwarded
> to a different destination.
>
> As such
Alessandro Vesely writes:
Currently, the only way that one can concede forwarding is by IP
address.
That's beside the point. The bottom line is this. Your email address is
[EMAIL PROTECTED] If you need to have example.com forward all your mail to
[EMAIL PROTECTED], you'll just have to live w
Alessandro Vesely wrote:
> Currently, the only way that one can concede forwarding is by IP
> address. This may make sense for a fully controlled backup MX. In
> general, the same IP address can be used to forward a message as well
> as to submit a new one. The forwarded-to recipient has no way to
Sam Varshavchik wrote:
> Mail forwarding is not a random event. Mail forwarding occurs,
> presumably, at the ultimate recipient's request. It is the ultimate
> recipient that places the forwarding in place, so that the recipient's
> mail gets forwarded to a different destination.
That forwardin
On 2008-08-24, Alessandro Vesely wrote:
> > In other words, the absolute bottom line is that, if I want to accept
> > messages that are aliased or forwarded from other hosts that do not
> > use SRS or rewrite the From_ header, but do use an SPF TXT record,
> > that I have to disable SPF checking?
>
Alessandro Vesely writes:
That's exactly the point. The forwarder violates SPF by impersonating
someone else. The forwarded message carries no evidence whatsoever
that the original message was SPF-compliant, does it?
Mail forwarding is not a random event. Mail forwarding occurs, presumably,
Mark Constable wrote:
>>>
>>> . whitelist forwarder IP addresses
>>> . use forwarders that rewrite the sender
>>
>> It is also possible to do both of them. Rather than patching an SRS
>> implementation into Courier, I'd be out to enhance authlib in order to
>> allow easier management of white
On Fri, 22 Aug 2008 06:39:37 pm Alessandro Vesely wrote:
> Mark Constable wrote:
> >> That state of affairs is obviously wrong...
> >
> > Absolutely. A sidebar at http://www.openspf.org/SRS says...
> >
> > [...] if you do check SPF, and you wish to
> > reject messages that fail SPF, then you mu
Mark Constable wrote:
>> That state of affairs is obviously wrong...
>
> Absolutely. A sidebar at http://www.openspf.org/SRS says...
>
> [...] if you do check SPF, and you wish to
> reject messages that fail SPF, then you must do one of two things
> to avoid rejecting legitimate mail:
>
> .
On Thu, 21 Aug 2008 06:51:53 pm Alessandro Vesely wrote:
> Well, it has been the source *many* discussions, and many consider this to
> be the weakest point of SPF. Actually, it is the weakest point of mail
> forwarding, see
> http://en.wikipedia.org/wiki/E-mail_forwarding#Historical_development_of
Mark Constable ha scritto:
> I'm somewhat stunned this has not been more of a noticable problem for
> anyone using SPF... and that I haven't noticed it myself until now even
> though we've been using SPF for the past year.
Well, it has been the source *many* discussions, and many consider this to
On 2008-08-20, Sam Varshavchik wrote:
> > If anyone sends an email to [EMAIL PROTECTED] it
> > gets forwarded to said server and results in the same error so it's
> > simply not possible to add 203.17.154.25 to "everyones" SPF records.
>
> The missing piece is that when the mail gets forwarded, th
Mark Constable writes:
On 2008-08-20, Sam Varshavchik wrote:
> This is the result of me sending a test message to [EMAIL PROTECTED]
>
> Aug 20 11:29:02 mail courieresmtpd: started,ip=[:::203.17.154.25]
> Aug 20 11:29:06 mail courierd: newmsg,id=000BB289.48AB7361.4973:
> dns; m0.vel
On 2008-08-20, Sam Varshavchik wrote:
> > This is the result of me sending a test message to [EMAIL PROTECTED]
> >
> > Aug 20 11:29:02 mail courieresmtpd: started,ip=[:::203.17.154.25]
> > Aug 20 11:29:06 mail courierd: newmsg,id=000BB289.48AB7361.4973:
> > dns; m0.velocity.net.au (mail
Mark Constable writes:
On Mon, 18 Aug 2008 09:01:28 pm Sam Varshavchik wrote:
> Because it's the From: address that fails it:
> jakeman.com.au.3568IN TXT "v=spf1 a ~all"
> jakeman.com.au.3550IN A 203.129.33.155
I'm now confused with a related
> On Mon, 18 Aug 2008 09:01:28 pm Sam Varshavchik wrote:
> > Because it's the From: address that fails it:
> > jakeman.com.au. 3568IN TXT "v=spf1 a ~all"
> > jakeman.com.au. 3550IN A 203.129.33.155
I'm now confused with a related issue where ther
On Mon, 18 Aug 2008 09:01:28 pm Sam Varshavchik wrote:
> Because it's the From: address that fails it:
> jakeman.com.au. 3568IN TXT "v=spf1 a ~all"
> jakeman.com.au. 3550IN A 203.129.33.155
On Mon, 18 Aug 2008 08:52:59 pm Kristian Duus Østerg
Mark Constable writes:
From what I understand about SPF, this example should have been
delivered to our mailserver but was rejected. Perhaps someone here
can pick up on why it wasn't...
Aug 18 09:56:22 mail courieresmtpd: error,relay=:::203.17.154.25,
from=<[EMAIL PROTECTED]>: 517 SPF so
>From what I understand about SPF, this example should have been
delivered to our mailserver but was rejected. Perhaps someone here
can pick up on why it wasn't...
Aug 18 09:56:22 mail courieresmtpd: error,relay=:::203.17.154.25,
from=<[EMAIL PROTECTED]>: 517 SPF softfail [EMAIL PROTECTED]:
27 matches
Mail list logo
