g_gateway can work for domain level and even box level redirects
--Ed
On 09/10/2014 11:48 AM, Eric Vey wrote:
> I didn't want all the mail to go to a particular IP, just the ones that
> were addressed to a server that I knew was misconfigured.
>
> The 19 year-old kid didn't know how to set up A or MX records correctly.
> He had a server working, but his domain name records were messed up.
>
> ------ Original Message ------
> From: "Ed" HIDDEN@ent.net>
> To: surgemailHIDDEN@etwinsite.com
> Sent: 9/10/2014 11:41:43 AM
> Subject: Re: Spam:*********, Re[2]: [SurgeMail List]HIDDEN@m and
>HIDDEN@d.com
>
>> You can do that with g_gateway
>>
>> --Ed
>>
>> On 09/10/2014 11:39 AM, Eric Vey wrote:
>>> That's what I was thinking about. I was hoping that instead of it being
>>> all IP based, it could ignore whatever the MX record said and send the
>>> message to a particular IP.
>>>
>>> I could have used a feature like that a long time ago. I'm not sure I
>>> was even on dmail yet.
>>>
>>>
>>> ------ Original Message ------
>>> From: "Ed" HIDDEN@ent.net>
>>> To: surgemailHIDDEN@etwinsite.com
>>> Sent: 9/10/2014 11:08:35 AM
>>> Subject: Re: Spam:*********, Re[2]: [SurgeMail List]HIDDEN@m and
>>>HIDDEN@d.com
>>>
>>>> In some cases I think you can use :
>>>>
>>>> g_dns_translate - If mx response is x.x.x.x translate to y.y.y.y:port
>>>>
>>>> Useful for translating ip numbers inside a local intranet and doing
>>>> other fancy routing of various sorts.
>>>>
>>>> Syntax: g_dns_translate from=string to=string
>>>>
>>>> See also: g_dns_paranoid, g_dns_match_msg, g_dns_noptr,
>>>> g_dns_noptr_skip, g_dns_noptr_msg, g_dns_nocache, g_dns_disk,
>>>> g_dns_cache_size, g_dns_system, g_dns_blank_fail, g_dns_host,
>>>> g_dns_nlookup, g_dns_require, g_dns_old, g_dns_new, g_spf_dns_timeout
>>>>
>>>> Unfortunately according to ChrisP the "from" parameter doesn't accept
>>>> wild cards so you could expect to have a fairly large list in a case
>>>> like me.com
>>>>
>>>> --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
>>>>
>>>
>>>
>>>
>>
>> -- -----------------------------------------------------------
>> 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
|
