Configuring for relays

[bleeb]

I just tried to add my work e-mail to my mailhosts, and wasn't sure what to do, after several attempts. (Read all the pinned items in this forum, and mailhosts portions of the help pages. If the answer is there, it wasn't obvious.) Figured I'd ask here, since SOMEONE else must have figured this out, before I bug the overworked deputies.

Problem: My incoming mail passes through multiple internal relays, before ending up at the mail server I actually download from. Mailhosts didn't like all the domains and relays it saw in the header of the confirmation, and I don't have any way of accessing mail at each intermediate relay, since anything that gets there automatically gets passed along the chain and ends up with the same full set of relays listed in the header. Pruning the header appeared to make the mailhosts config unhappy, as well.

Any pointers?

Thanks.

[StevenUnderwood]

Problem: My incoming mail passes through multiple internal relays, before ending up at the mail server I actually download from.  Mailhosts didn't like all the domains and relays it saw in the header of the confirmation, and I don't have any way of accessing mail at each intermediate relay, since anything that gets there automatically gets passed along the chain and ends up with the same full set of relays listed in the header.  Pruning the header appeared to make the mailhosts config unhappy, as well.

27142[/snapback]

This is considered a complex configuration and will require the assistance of the overworked deputied, I believe.

The good news is that since configs are shared, this should only need to be done once for your company.

[Wazoo]

Providing a Tracking URL that shows the 'problem' would go a long way in allowing someone to 'look' at the specifics ... but if things are as screwed as you say, then perhaps even Ellen can't help.

[Ellen]

Did the mailhosts error message give you an option to ask for a waiver? If it did then follow the links for the waiver, else send me the complete headers of the probe and the message text and I will take a look at it.

[bleeb]

Thanks for the responses, but after thinking it over, I decided not to risk the wrath of the IT gods by making public these details regarding the company's internal network structure (or telling people outside the company, even though one presumes the deputies are trustworthy! Maybe I'm being overly paranoid about security.

Instead, I mailhosted (apparently succesfully) using headers only up to the public MX, omitting details regarding internal routing. Guess I'll have to remember to do the same when submitting. (From the web site, this doesn't appear to fall afoul the "no modifications" rule, although I be happy to hear dissenting opinions.)

One thing I'm somewhat curious about is whether this isn't a common situation for larger organisations. The e-mail in question was relayed through a commercial 'high-reliability' service with redundant servers and multiple connections, an anti-spam server, an anti-virus server, and Sarbanes-Oxley compliance checking (whatever that means) before reaching one of several end-user mail servers. Or maybe it's just too complicated to automate.

[StevenUnderwood]

Or maybe it's just too complicated to automate.

27328[/snapback]

That is the problem I believe.

[Wazoo]

Note kicked upstairs for your "possible dissenting opinion" scenario. Modification of headers is most definitely a no-no .....

[turetzsr]

<snip>

One thing I'm somewhat curious about is whether this isn't a common situation for larger organisations. <snip>

27328[/snapback]

...Something like this seemed to have happened for me, as well. I had no problem convincing myself that publicizing the details to the deputies was not a security risk and, even if it were, the benefits of being able to easily report spam using SpamCop outweighted whatever the small risk there might be.

[bleeb]

Is there some way to tell whether you've "completed" configuring an address, other than receiving a confirmation e-mail? While struggling through the process a few times, the "configuration: success/failed" e-mail wasn't always getting through, and it wasn't obvious from the configuration web page whether all of the "sends" had been either completed or cancelled, or whether there was one open that was holding up spam processing. (Might want to add the answer to the mailhost config FAQ.)

Thanks.

[Wazoo]

As this last post by bleeb was a continuation of his query, I had merged that post into the existing discussion. I came back and see that "merged" posting gone and another Topic opened up with the same query. Merged once again ....

And the basic answer is as per the Pinned item data ... when 'done' parse some spam and verify the results. There is a question on saying that "everything is correct" in bleeb's case, based on the self-admitted manipulation of header data in both the MailHost configuration sequence and the spam submittal process.

[bleeb]

As this last post by bleeb was a continuation of his query, I had merged that post into the existing discussion.  I came back and see that "merged" posting gone and another Topic opened up with the same query.  Merged once again ....

Sorry. Didn't realise you'd merged it. Tthought I'd posted it in the wrong place since it seemed to be a separate issue, as it had to do with a "normal" e-mail address that doesn't have the problem with multiple relays within the ISP between public MX and delivery to the user.

And the basic answer is as per the Pinned item data ... when 'done' parse some spam and verify the results.  There is a question on saying that "everything is correct" in bleeb's case, based on the self-admitted manipulation of header data in both the MailHost configuration sequence and the spam submittal process.

27391[/snapback]

That was the part that had me confused: The lack of indication as to what was holding things up (slow server or mailhost config problem) when no responses were seen for spam submitted. This was spam received by a normal (non-relayed) e-mail address with headers not being pre-munged. In the end, it looks like there was one attempt at adding a server to the mailhost list that hadn't been properly cancelled, and removing recent additions one at a time till the culprit was located seems to have done the trick. I guess the FAQ/pinned item warns this can happen, but some indication that it has (and that it's not some other cause) might be a useful feature to add (i.e. "You've sent probes to your e-mail accounts on n servers, but haven't returned x of them to mailhosts for processing.")