Chris Lightfoot wrote: > On Mon, Aug 28, 2006 at 11:14:17AM -0600, Sherwood Botsford wrote: > [...] > >>We are on a satellite link, with a variable IP address. Our >>conditions of use prohibit running any server on our end of the >>link. >>I have an ISP cache our email, and use fetchmail to pick it up >>every 5 minutes. Once here, fetchmail funnels it to exim. >> >>If exim rejects email, fetchmail regards it as undeliverd, and >>doesn't delete it from the server, so next time it's there, like >>a bad penny. >> >>I suppose the best thing to do would be to set up a separate >>transport for "people who used to be here" and set it up so that >>exim would make one attempt to respond, saying "You recently sent >>email to a user who is no longer here." If the transport failed, >>it would log something and never try again. >> >>Almost all of this email is spam. Real people know the person's >>new address. I don't see much point in wasting my bandwidth >>trying to send mail to mostly non-existent addresses. >> >>Thoughts. > > > Two suggestions-- > > - Can you run a VPN between a site on the `real' > internet and your host, and have SMTP deliveries > directly to your own server? (This might break the `no > servers' rule, or there might be separate rule against > VPNs; or there might not.)
So long as the server is not public or 'visible' as such, one can probably meet both letter and spirit of a typical Tos by this method. BUT - you still need a 'cooperative' relay, even if not a fully configurable one, so a 'smarter' retrieval tool or MUA isn't much worse off. > > - At the site where you're currrently accepting mail > for later download by fetchmail, what control over the > alias file do you have? Are you just accepting any > local-part at your domain, or are you transferring a > list of valid local-parts? If the former, you'd do a > lot better if you could send your list of registered > users up to the server with good connectivity and have > it accept/reject mail as appropriate. Most connectivity 'packages' have relatively sparse address-count, though many DO allow 'unlimited' aliases. Seems it would entail effectively moving the entire current mailing-list onto the ISP's server as aliases - which could be expected to then abrogate / impede application of MLM-style vetting and posting rules. Unless, perhaps, all 'aliases' pointed to the downstream MLM ONLY. Might work well. Admin would not necesarily meet the often legally-mandated 'unsubscribe' rules. > If you can put > in a list of valid local-parts, is there any way you > can force a failure there (e.g. using the :fail: > syntax or in some other way)? This depends a lot on > what your ISP lets you do, I guess. > Not sure it helps much if the upstream host just flags and onpasses spam rather than allowing server-side rejection/discard settings. > (Not really relevant to your problem, but I take it you > don't have the option of collecting mail in the form of > batched SMTP data rather than via POP3/IMAP?) > Fetchmail and Getmail Do have some quasi-intelligent tools, and/or hooks to same, IIRC. May not be enough if one is trying to operate a mailing list / service a domain w/o a dedicated MX. FWIW, Ecartis, to name one, is an MLM designed to be installed and operated from within shared/virtual userspace, i.e. without need of 'root' privs, save for setup of a short group of pipe entries into ~/etc/aliases. MTA agnostic, as well. Steepish learning curve, as it is used primarily within its own devel community, and docs are not for the faint-hearted. JM2CW Bill -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
