Its very obvious that this is an issue that is dependent on site policy.
Its pointless to argue about which is the 'right' policy, since that is
entirely up to each site. Obviously on a 'personal' or 'free' site, and
perhaps at a corporate site, where your 'customers' arent going to
switch, its appropriate to do standard callbacks.
At a high-volume ISP, we cant afford to do that. We dont want to have to
take time to add exceptions by hand - we want it automatic. We arent
trying to enforce RFC's on sites that arent under our control, nor are
bounces a problem, since we dont accept mail for recipient addresses
that arent going to be deliverable.
The primary problemy we are trying to solve, is spam sent from
completely invalid addresses. Implementing callbacks with an alternate
MAIL FROM value (ideally the same as the address subject to
verification), used only if MAIL FROM:<> is rejected, will accomplish
exactly what we need.
QED
On Sun, 16 Jun 2002, Marc MERLIN wrote:
> 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
>
--
