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 126.96.36.199). > > 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[188.8.131.52] > > Fecha: Fri, 18 May 2018 10:10:39 -0400 (CDT) > > Out: 220 partagas.ettpartagas.co.cu ESMTP Partagas > > In: EHLO 184.108.40.206 > > 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: 220.127.116.11 > > 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