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
