How can i send email from this script?
This one it does work:
:tool e-mail send to=$toEmail subject=“$[/system identity get name]” body=“test: $new”;
:log info message=“Emailed”
Problem:
Im able to ping to google only when in pinging with src-address of the lan.
ping 8.8.8.8 i can’t ping
ping 8.8.8.8 src-address=192.168.y.x i can ping
so in this case im not able to send email from the router
Does anyone know hot to modicicate the script that would be able to send email?
There is no src-address or routing-table parameter for /tool e-mail like there is for ping or /system ssh. So you have to use a route with pref-src=your.lan.ip.address and dst-address=IP.of.SMTP.server if you know the numeric address of the SMTP server, or a NAT rule referring to an address list if you don’t:
/ip firewall address-list
add list=smtp-server address=smtp.my-mail.mk
/ip firewall nat
add chain=srcnat dst-address-list=smtp-server src-address-type=local action=src-nat to-addresses=your.lan.ip.address
What we will do , when you will move away from this forum?
@Sob, @mkx, @tdw know even more than I do, to name just a few people who are active during past few months. I was almost offline for half a year and the world hasn’t stopped rotating 
smtp.my-mail.mk..give more info..it doesn’t work like that you wrote
currently im using 74.125.141.108
What exactly doesn’t work, the address list part or the src-nat part? I.e. what does /ip firewall address-list print where list~“smtp” show, only the item with fqdn you’ve added manually or also some dynamically added items with IP numbers in the address field?
If the SMTP server has a single fixed IP address which you are sure to never change, there is no need to use the fqdn-tracking address list.
If the fqdn-tracking address list works fine, can you see any matches on the action=src-nat rule?
If not, I have to ask whether you’ve placed this rule before (above) any other src-nat or masquerade one.
im not getting ip when im add
/ip firewall address-list
add list=smtp-server address=smtp.my-mail.mk
Earth is spinning all right, but the world we live in slowed down almost to a halt. I think you should accept your share of responsibility for that 
Unless you’ve used literally smtp.my-mail.mk rather than the actual fqdn of your SMTP server, it could only be caused by DNS not working on the router, preventing the fqdn-tracking address list from doing its job. What does put [resolve your.smtp.server.fqdn] show?
hehehe i didn’t put that.
My internet provider is TPG and i used mail.tpg.com.au
after reboot works fine
will you be able to assist me about that
that is how it looks like on my end
/ip firewall nat
add action=src-nat chain=srcnat dst-address-list=smtp-server src-address-type=local to-addresses=local-lan
What kind of assistance do you need? So far even the goal is not clear to me - from the srcnat rule it seems that you want to srcnat sessions towards the smtp server to LAN IPs, which makes little sense to me. So you have to be a bit more verbose about the overall scenario.
basically the problem is, from the CPE i can ping to google only if i ping from src-address.
ping 8.8.8.8 without src-address doesn’t work.
i need that to be able to send email from that device
That sounds as if you have a multi-WAN setup, the traffic to 8.8.8.8 is routed via another WAN than the one chosen by the default route in routing table main, and there is no masquerade rule for traffic leaving via WANs that is sent by the router itself.
Can’t say anything more precise without seeing the export.
just here
Since dynamic routing (OSPF) is active, what does /ip route print detail show? And what src-address you must add to ping 8.8.8.8 in order that it worked?
wow do you want me to post here? from the ospf i’m receiving 700+ routes
To be able to ping to google im need to src with 192.168.0.1
OK, so post just the output of /ip route print detail where 8.8.8.8 in dst-address , that should be just a few routes.
this is what i can see:
What I can see is that the action=src-nat rule matching on out-interface=vpls-xxxx (through which the current default route goes) is restricted to src-address-list=OriginCustomer. Whereas 192.168.0.1 does match that address list, the own address assigned to that interface (172.31.1.66), which is chosen for own outgoing traffic of the 3011 via that interface, doesn’t. So I suspect that somewhere between that interface and the internet, route to 172.31.1.66 sends the ping response somewhere else than back to the 3011. OSPF doesn’t take care about 172.31.1.64/30.
You can verify this by running /tool sniffer quick ip-address=8.8.8.8 ip-protocol=icmp in one terminal window while pinging 8.8.8.8 without specifying src-address in another.