On Thu, Nov 29, 2001 at 08:19:06PM -0800, Claus Assmann wrote:
> You can have this via a mechanism like dsn.rfc-ignorant.org,
> i.e., DNS.
This list is out of date by design. Also, I don't have control over it, and
I don't know how trustworthy it is.
If someone says "why did you reject my mail", I have exact logs to show why.
Once the server is fixed, mail flows through again right away.
> Not performing a callback twice to the same MX record like
> sourceforge.net does. That is:
>
> MAIL FROM:<x@???>
> ...
> DATA
> ...
> From: <x@domain>
>
> with
>
> domain. MX 10 host.domain.
> host.domain. MX 10 host.domain.
Mmmh, I can see your point, but exim many not need that level of complexity.
If you get one extra callback, as long as it gets cached and it doesn't
happen again for several days (I'd set positive caching to high values, like
a week or more), it's not the end of the world.
> causes 2 SMTP connections from sourceforge (unless I misunderstood your
> explanation why your MTA connects twice to my system when I send an
> e-mail; in once case it connected 6 times... probably due to some
> forwarding?)
No, you understood correctly. Note that this is not sf.net specific. Anyone
using exim and callbacks will generate two callbacks back to you since your
header and envelope froms are different.
On Fri, Nov 30, 2001 at 06:54:20PM -0500, James Antill wrote:
> > - caching of positive callbacks (by far #1)
> > (I do not really want caching of negative results, as I'd rather have
> > people who just fixed their mail server be able to send right away)
>
> This might be nice, the problem is that one of the benefits of
> callback support is that if someone does a spam from an ISP account
> and the ISP then kill that customers account then you instantly stop
> getting their spam.
True. I'm willing to live with that.
1) I subscribe to maps
2) callbacks are to get rid of unbounceable junk more than spam
> I guess as with all caching the big question is how long to you cache
> for.
It should definitely be an option
> > - Being able to do an additional callback on the domain for a special
> > address (like postmaster@ and optionally abuse@). My patch implements that
> > by piggybacking on top of the current callback, it does a RSET, a new mail
> > from: <>, and tries the 2nd address.
>
> This is sort of pointless IMO, but I can see how some nazi mail
> admins might like it :).
Fair enough.
For the record, I wrote the postmaster callback after getting pissed off at
having yet another of my Emails to postmaster@somesite bounce back. If there
isn't a remote postmaster that I can troubleshoot things with if needed, I
don't want the mail anymore.
Of course, the callback doesn't garrantee that the postmaster mail goes
anywhere or gets read, but I'll take what I can get.
> > - Some way to optionally not do SMTP callback if there is a certain header
> > line in the message
> >
> > The 2nd one is important if we don't want people on mailing lists to be
> > flooded with SMTP callbacks every time they post to a list.
>
> I presume you are talking about the third point here ?
Err yeah.
> > The way this would work is that if the list server runs exim with SMTP
> > callbacks, it would check the mails as they are posted, add a header saying
> > that the header from has been checked, and rebroadcast to the list
> > subscribers
> >
> > List subscribers would then be encouraged to not do callbacks if the special
> > header is there.
>
> And spammers would be encouraged to include it by default ?
1) Spammers too dumb to have incorrect from headers will probably not know
about a callback avoidance header
2) Exim could be configured to know that some sites you receive mail from
can do callbacks, and only honor the header if it comes from one of those
sites (and you could set callback_checked_header_honor = *) to accept all
of them as long as spammers aren't setting it.
> I'd probably trust something like a maps RBL kind of thing, where
> if a domain is on the list it means that they do callbacks (and/or do
> sender_verify/headers_check_syntax/etc).
> Hopefully because of the nature of a list like that they could have
> massive positive expire times (and fairly large negative ones) thus
> the bandwidth wouldn't be as big a problem.
That's actually a good idea too, probably better than my suggestion.
Marc
--
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page:
http://marc.merlins.org/ | Finger marc_f@??? for PGP key
