Certainly the language does not help me, I try to explain better.
I know the operation of SPF, I thought that this module would make a
preventive control before sending email to recipient.
The log of server 10.10.10.115 ( smtp alternative with policyd for
domain.xx) :
2016/02 / 11-16: 58: 12-23209] [TRACKING] DEBUG: Request translated into
session data: $ VAR1 = {
'Recipient' => '[email protected]',
'SASLUsername' => 'goodclient',
'QueueID' => '',
'RecipientData' => '',
'Instance' => '5a8f.56bcaf94.1672a.0',
'EncryptionCipher' => '',
'Size' => '1',
'EncryptionKeySize' => '0',
'Unixtimestamp' => 1455206292,
'ProtocolTransport' => 'Postfix',
'EncryptionProtocol' => '',
'Helo' => '[192.168.1.205]',
'ClientAddress' => 70.70.70.25 '',
'ClientName' => 'hostxxxxxxxxt',
'Sender' => '[email protected],
'SASLSender' => '',
'_ClientAddress' => Bless ({
'Raw_ip' => 70 .70.70.25 ',
'Ip' => 70 .70.70.25 ',
'Ip_version' => 4,
'Cidr' => 32
}, 'Awitpt :: NETIP'),
Recipient address rejected: Failed SPF check; Please see
http://www.openspf.org/Why?s=mfrom;id=test%domain.xx.;ip=70.70.70.25;r=unknown
;
################################################## ##################
The 70.70.70.25 ip address is an address of a generic client (thunderbird
software), if sending by 3g will change again etc etc.
Why does the filter control directly on client ip? Logically I can not
enter in the SPF record all IP addresses from which I connect during the
day .
Make this policy because the control is on outgoing?
Sorry for bad translation :D
2016-02-11 13:31 GMT+01:00 Christoph Langguth <[email protected]>:
> On 11/02/16 13:02, Roberto Lucarelli wrote:
>
>> Hello,
>> I did not understand your response, the filter is enabled but does not
>> work as I would like.
>>
>>
> I'm afraid that you will have to provide more information. As far as I
> understood:
>
> You have domain.xx, with mx 20.20.20.20. You have an SPF record for that
> domain. So far, so good.
>
> Essentially, that means: All mails [email protected] must be sent from the MX.
>
> Now, if *I* send an email pretending to be [email protected], I cannot use
> your MX server, and so I will not be able to pass the SPF test. That's
> good, and that is exactly what SPF is there for.
>
> But if *YOU* send an email as [email protected], you must ultimately do so
> via the MX. (Or some other MTA you control, as long as it's relayed through
> the MX, that doesn't matter).
>
> The point is: YOU will have credentials to authenticate yourself to the
> system, and as soon as you're authenticated, the server should *NOT* check
> SPF records.
>
> That is exactly what Andrea was talking about. Port 25 is "public
> delivery", and can do SPF checks.
>
> Port 465 (smtps) or 587 (submission) should be used for "authenticated
> sending", and should NOT do SPF checks (but possibly enforce quotas etc.)
>
> In policyd terminology: Only apply SPF checks to *inbound* mails, not to
> *outbound* ones.
>
>
> HTH
>
> Cheers
> Chris
>
>
>
>
>
>
>
> _______________________________________________
> Users mailing list
> [email protected]
> http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
>
>
_______________________________________________
Users mailing list
[email protected]
http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
