g_gateway - Gateway messages to a particular domain (Or smarthost)
Used to gateway messages to another local mail server. Typically this
other server is inside a fire wall so it's local IP address is not known
by the DNS server. You specify the domain and IP address to send
messages to and this server is treated as 'local' rather than remote in
terms of open relay restrictions. eg: nonauthenticated users are able to
send in mail. Open relay restrictions do not apply to messages sent to
this domain because they are considered as if they were local users and
not 'relaying'.
This setting has the fields domain(required), to(required),
user(optional), pass(optional),
relay=true/false(optional),check=true/false (optional)
Normally "domain" and "to" are the only fields that need to be filled
in. eg. To relay mail from anyone to user accounts in the domain
somedomain.com to the host 1.2.3.4.
g_gateway domain="somedomain.com" to="1.2.3.4"
user="username" pass="password"
If SMTP authentication is required on the destination server the user
and pass fields need to be completed.
check=true
The check=true setting tells surgemail to actually connect to the server
and check that recipients exist before accepting an incoming email for
that user, this is STRONGLY recommended, as it stops the server having
to bounce thousands of messages when spammers send to invalid addresses
on your server. If SurgeMail cannot connect it will assume the user does
exist so nothing is bounced except when the connection is successful.
Classic smarthost setting
This is where you want to send all outgoing email to another server,
that may require authentication, note that we don't use relay="true" as
that would make the server an open relay.
g_gateway domain="*" to="isp.mail.server" user=HIDDEN@sp.server" pass="xxx"
relay="true" (warning, usually not needed or wise, this can make your
server into an open relay for spammers to abuse!)
As a safety measure to prevent accidental openrelays, SurgeMail will not
relay for non authenticated users or trusted users (users that are
allowed to relay due to relaying settings eg g_relay_allow_ip) if the
domain is "*". This can be overridden by placing "true" in the "relay"
field. eg: To relay all mail for all users to host 1.2.3.4:
g_gateway domain="*" to="1.2.3.4" relay="false"
It is possible to use domain="c:\domains.txt" where domains.txt is a
file listing the domains to be gatewayed, this should only be done for
one gateway rule, and is only worth doing if you have thousands of
domains to gateway.
local="true"
Requires that the destination addresses exist in the local account database.
Gateway after user lookup
When gatewaying to a domain which accepts all email regardless of
address (e.g. exchange) you are best to define the users in your local
user database, this is the only way to prevent nasty bounces and get rid
of all the spam cleanly.
1) remove the gateway setting for the domain
2) add a virtual domain
3) In the virtual domain add surgewall settings, e.g. in this example
I'm gatewaying the domain 'netwin.co.nz' to a
backend server called 'backend.netwin.co.nz"
vdomain address="" name="netwin.co.nz"
...
surgewall "backend.netwin.co.nz"
surgewall_options strip_domain="" proxy_failover=""
auth_local="TRUE" pop="" smtp="" imap="" usercgi=""
You can find more gateway examples in our FAQ here
http://www.netwinsite.com/surgemail/help/faq.htm#gateway
Syntax: g_gateway domain=string to=string user=string pass=string
relay=string check=bool sms=bool local=bool
--Ed
On 09/10/2014 11:01 AM, Eric Vey wrote:
> This is a curiosity question:
>
> Is there a setting that allows mail addressed to a domain to be sent or
> forwarded to a particular IP or IP block or another server name?
>
>
> ------ Original Message ------
> From: "Ed" HIDDEN@ent.net>
> To: surgemailHIDDEN@etwinsite.com
> Sent: 9/10/2014 10:10:52 AM
> Subject: Re: [SurgeMail List]HIDDEN@m and @icloud.com
>
>> Hi Frank,
>>
>> We don't use m$ stuff here, linux has all that wonderfullness built
>> in. I did find something that very likely would explain the errors we
>> are seeing. Thanks for the suggestion.
>>
>> A little primer : me.com and aliases have 2 basic blocks of IP's they
>> advertise the MX's on at least that are apparent to us -- don't know
>> if they're using geo-ip management or not.
>>
>> On one block we can deliver email without issue, the other it fails
>> most times.
>>
>> Good block 17.172.*
>> Bad block 17.158.*
>>
>> I should note that the "bad block" is deliverable *sometimes*. Also
>> explained by the results.
>>
>> So without further a due I picked 2 IP's from their MX1 advertisement :
>>
>> --- Bad Block!!! Notice the MTU mismatch when it hits 17.1.152.1 .. [
>> line 6 ] Drops to 1488. That explains the error messages perfectly.
>> And it's all apple.
>>
>>
>> tracepath 17.158.8.67
>> 1?: [LOCALHOST] pmtu 1500
>> 1: gateway.easent.net 1.103ms
>> 1: gateway.easent.net 1.075ms
>> 2: 66.192.139.133 4.138ms
>> 3: mia2-pr1-xe-0-3-0-0.us.twtelecom.net 15.307ms asymm 5
>> 4: 17.1.152.1 12.509ms asymm 5
>> 5: no reply
>> 6: 17.1.152.1 12.855ms pmtu 1488
>> 6: 17.0.150.82 85.399ms asymm 7
>> 7: 17.0.150.64 85.346ms
>> 8: 17.0.150.81 85.913ms asymm 7
>> 9: no reply
>> 10: no reply
>> 11: no reply
>> 12: no reply
>> 13: no reply
>> 14: no reply
>> 15: no reply
>> 16: no reply
>>
>> --- good block !!! No MTU mismatch
>>
>> But yet when routed on the good block side when it hits 17.1.152.1 it
>> doesn't exhibit an MTU change.
>>
>>
>> tracepath 17.172.34.9
>> 1?: [LOCALHOST] pmtu 1500
>> 1: gateway.easent.net 1.150ms
>> 1: gateway.easent.net 1.193ms
>> 2: 66.192.139.133 18.927ms
>> 3: mia2-pr1-xe-0-3-0-0.us.twtelecom.net 18.709ms asymm 5
>> 4: 17.1.152.1 23.239ms asymm 5
>> 5: 17.0.140.114 50.572ms asymm 7
>> 6: no reply
>> 7: no reply
>> 8: no reply
>> 9: no reply
>> 10: no reply
>> 11: no reply
>>
>> So now the great mystery has been solved. Will it ever be resolved ? I
>> seriously doubt it.
>>
>> --Ed
>>
>>
>>
>> On 09/10/2014 12:41 AM, Frank Bulk wrote:
>>> If you ever wanted to chase down the MTU issue from a Win32
>>> perspective you could try this free tool:
>>> http://www.elifulkerson.com/projects/mturoute.php
>>>
>>> Pleas share the working and not-so-well-working IPs so we can compare
>>> to our own logs.
>>>
>>> Frank
>>>
>>> -----Original Message-----
>>> From: Ed [mailtoHIDDEN@ent.net]
>>> Sent: Monday, September 08, 2014 10:12 PM
>>> To: surgemailHIDDEN@etwinsite.com
>>> Subject: Re: [SurgeMail List]HIDDEN@m and @icloud.com
>>>
>>> Hi,
>>>
>>> PMTU I don't think so.
>>>
>>> We did find that me.com and aliases advertise a whole big pile of MX's.
>>> After some testing we found that some MX's work great every time,
>>> some
>>> fail most times -- not all [how odd]. Hmmm ! So luck of the draw ?
>>> Also we found that each of those MX's actually front for multiple
>>> different servers ie load balancing and they overlap too. Oh so cool ;-)
>>>
>>> Knowing the IP of a good one we just added a little configuration for
>>> those 2 domains to route to that IP and life is one again good, at least
>>> for now.
>>>
>>> We will have to get into this a bit deeper. I was actually entertaining
>>> the idea we've got an MTU mismatch someplace upstream, seen that action
>>> before but I'm not really sure of that because those 2 domains are the
>>> only ones giving us a problem. And it's obviously not an RBL issue
>>> either.
>>>
>>> Thanks!
>>> --Ed
>>>
>>> On 09/08/2014 10:59 PM, Frank Bulk wrote:
>>>> We've not seen any issues. Anything possibly PTMU related?
>>>>
>>>> Frank
>>>>
>>>> -----Original Message-----
>>>> From: Ed [mailtoHIDDEN@ent.net]
>>>> Sent: Monday, September 08, 2014 11:14 AM
>>>> To: surgemailHIDDEN@etwinsite.com
>>>> Subject: [SurgeMail List]HIDDEN@m and @icloud.com
>>>>
>>>> Has anybody out there had an issue sending email to me.com and
>>>> icloud.com which are really the same place.
>>>>
>>>> This all seems to have started a couple months ago. It's the only place
>>>> we're having an issue with so not a network or server issue because all
>>>> of our servers are experiencing the same issue and have zero delivery
>>>> issues any place else.
>>>>
>>>> We're getting
>>>> after data sent: 421 4.4.2 Timeout while waiting for command.
>>>> and
>>>> Write failed 100 times or 550>540 seconds 550, wrote 37305/1485
>>>> left
>>>> (37305)
>>>>
>>>> which is quite bizarre.
>>>>
>>>> If so did you fix it and how.
>>>>
>>>> Thanks!
>>>> -- Ed
>>>> -----------------------------------------------------------
>>>> EAS Enterprises LLC
>>>> World Class Web and Email Hosting Solutions
>>>> IPv6 ready today for your needs of tomorrow!
>>>> Ask us about dual-stacking your site
>>>> www.easent.net
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> -- -----------------------------------------------------------
>> EAS Enterprises LLC
>> World Class Web and Email Hosting Solutions
>> IPv6 ready today for your needs of tomorrow!
>> Ask us about dual-stacking your site
>> www.easent.net
>>
>
>
>
--
-----------------------------------------------------------
EAS Enterprises LLC
World Class Web and Email Hosting Solutions
IPv6 ready today for your needs of tomorrow!
Ask us about dual-stacking your site
www.easent.net
|
