On Sat, Jun 15, 2002 at 11:10:37AM -0400, Dave C. wrote:
> However, on the at the ISP I work for, we can't afford to piss off our
> customers who expect to receive mail from their
> associates/customers/etc. They don't want to hear about some RFC, they
> want to get their mail.
If I may, I have the same problem at work.
Obviously, for sourceforge.net, it's easy to just reject pretty much
anything that breaks a rule, as shown here:
http://sourceforge.net/docman/display_doc.php?docid=6747&group_id=1
but for corporate Email, the rules are obviously different. For instance, we
don't run RBLs (at least not to block mail at SMTP time), and we don't do
postmaster callbacks (patch of mine to see if the remote site would accept
mail for postmaster)
The way I've handled this and justified having full callback on is:
We (IS) want to garantee mail delivery or failure bounces. If you Email
someone, we do our best so that your mail goes through or you get a bounce
to inform you of the failure
Now, if someone Emails us, we want to be 100% sure that we can either
deliver the Email or garantee that the Email gets bounced and the sender
is notified (at least, we'll do everything in our power to insure that)
Once, you explain that, with which people tend to agree, it's a lot easier
to implement callbacks.
If a site refuses bounces, your site tries to inform them of their
misconfiguration and asks them to fix their side.
Now, note that:
1) your customer doesn't get the callback bounce, the remote sender does
2) if the remote sender doesn't fix their mail server, but complains to your
user out of band, it's easy to explain the "we don't drop mail"
configuration, and then explain that their mail server is broken but that
you'd be happy to put them in an override list after your user
acknowledge that you will not be responsible for lost mail.
Take my word for it, if you put it that way, it flies a *lot* better.
You never have to pronounce the word RFC (nor should you)
> My idea would be to _first_ try "MAIL FROM:<>", and only if that was
> rejected try other values. Any site not accepting "MAIL FROM:<>" isn't
Not as bad, but you can still create a loop.
> same address that you are trying to verify. It is VERY unlikely that a
> site will reject "MAIL FROM:<>", do callbacks, *AND* do callbacks on its
> OWN addresses.
True, that's likely to work.
> If it was the sending sites that were complaining, that would be fine.
> But its OUR customers. We have way too much mail volume to continuously
See above.
> monitor this, and if we wait until our customer is calling us, they are
I don't monitor mine either. I wait for remote sites to complain or very
rarely for users to get an out of bound complaint.
I have a friend who runs an ISP just like that without any problems.
> My goal here is not necesarrily trying to enforce RFC-compliance on the
> world, my goal is to try and block some percentage of the spam from
> addreses that are completely forged, without blocking non-spammy email
That's merely a byproduct of callbacks.
Their main goal is really to make sure that you can send a bounce or a reply
back to people who sent you mail.
If you really want to kill spam, look at this instead:
http://marc.merlins.org/linux/exim/sa.html
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f@??? for PGP key
