El mar, 22-05-2018 a las 20:54 -0400, John Johnstone escribió:
> On 5/18/2018 10:42 AM, Alberto José García Fumero wrote:
> 
> > Im trying to block spam (for instance, from 185.234.217.232).
> > As far as I know, it's trying to pass as a message from my very
> > net:
> > 
> > Transcript of session follows.
> > De: Mail Delivery System <MAILER-DAEMON@partagas.ettpartagas
> > .co.
> > cu>
> > Para:       Postmaster <postmas...@ettpartagas.co.cu>
> > Asunto:     Postfix SMTP server: errors from
> > unknown[185.234.217.232]
> > Fecha:      Fri, 18 May 2018 10:10:39 -0400 (CDT)
> >   Out: 220 partagas.ettpartagas.co.cu ESMTP Partagas
> >   In:  EHLO 190.6.79.98
> >   Out: 250-partagas.ettpartagas.co.cu
> >   Out: 250-PIPELINING
> >   Out: 250-SIZE 15240000
> >   Out: 250-ETRN
> >   Out: 250-STARTTLS
> >   Out: 250-ENHANCEDSTATUSCODES
> >   Out: 250-8BITMIME
> >   Out: 250 DSN
> >   In:  AUTH LOGIN
> >   Out: 503 5.5.1 Error: authentication not enabled
> > 
> > Session aborted, reason: lost connection
> > 
> > For other details, see the local mail logfile
> > 
> > but the MTA correctly rejects it as a fake.
> 
> It might not be good to describe what happened here as your MTA
> rejected 
> the connection as a fake.  If your MTA is configured to reject a 
> connection because the EHLO contains your IP address (which is 
> unlikely), that isn't what happened here.
> 
> Your MTA returned a 503 error to the sending server because your MTA
> is 
> not configured to accept an AUTH login.  250-AUTH is not part of its 
> response to the EHLO.  Most mail servers accept AUTH only on port 465
> or 
> port 587.

Right.

> 
> > I have created an alias list (rechaza) in the menu
> > Firewall/Aliases,
> > where I put all the addresses known to be spammers, and tried to
> > reject
> > them with the rule in Firewall/Rules/WAN
> > 
> > Action: Block
> > Interface: WAN
> > TCP/IP version: IPV4
> > Protocol: TCP
> > Source: (single hots or alias) rechaza
> > Destination: 190.6.79.98
> > Destination port range: any
> > 
> > but I can not stop the spam right in the WAN interface.
> 
> If you take a look at Status > System Logs > Firewall and notice
> what 
> you see for Source and Destination this can help you understand
> better 
> how filtering and NAT works.  For your WAN interface, Source will be
> the 
> public IP of the origin of the packet.  If there is no port
> forwarding 
> configured for the destination port, no NAT occurs so the
> destination 
> address will be your public IP.  If port forwarding is configured
> for 
> the destination port, then NAT does apply and the destination
> address 
> will be your LAN IP.  It helps to keep this in mind when developing
> rules.

That did the trick. 

My first idea was to take a better look at the order of the
instructions, that is, to see if the NATing occurred **before** the
blocking. But it seems I should consider then as working in different
"contextes".


Thanks a lot to all!
-- 
M.Sc. Alberto García Fumero
Usuario Linux 97 138, registrado 10/12/1998
http://interese.cubava.cu
No son las horas que pones en tu trabajo lo que cuenta, sino el trabajo
que pones en esas horas.




_______________________________________________
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Reply via email to