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
|
