On Tue, 7 Jan 2003, Sunil Shetye wrote:
In fact, I have noted that when a MAIL FROM: <> is sent to the mailbox
on my popservername, the Return-Path: is stored as
<MAILER-DAEMON(_at_)popservername> and not <>! Then, when fetchmail gets
that mail, the from address is <MAILER-DAEMON(_at_)popservername>. I have
not checked who is doing this rewriting and why.
Which mailer runs on that box? I checked a few exim sites and a few
sendmail sites. Only 1 site (sendmail, and of course exactly the
one at which I don't have access to the sendmail config) does indeed add a
"Return-Path: <MAILER-DAEMON(_at_)smtpservername>" instead of a
"Return-Path: <>".
All other exim and sendmail setups handle a "MAIL FROM:<>" nicely with a
"Return-path: <>". As it should, IMO. What use would a return-path header
be if it doesn't display the SMTP envelope-from?
So, my opinion is that no harm is done if <> is converted to
MAILER-DAEMON (and eventually to <MAILER-DAEMON(_at_)popservername>).
If you really mean that, you could as well not patch anything... That's
the way it works now anyway.
However, fetchmail should not bounce mails to MAILER-DAEMON anyway!
[snip]
Undoubtedly, there could be more addresses for which bounces should
not occur like "postmaster" or even "FETCHMAIL-DAEMON"!
That would mean you want fetchmail to make other decisions than all
other mail software? AFAIK, the spec says something like: 'want no
bounces? then send the _special_ "MAIL FROM:<>".'
However, this patch will atleast solve the mailing loop problem.
Like blocking all @hotmail.com mail will stop a lot of spam...
The only difference would be that "somedomain" would become
"popservername". Which raises another interesting question: what happens
with mail (especially the bounces) sent to
MAILER-DAEMON(_at_)yourowndomain(_dot_)com
if fetchmail pops mail from yourowndomain.com:pop3? In that case you
don't even need two sites running fetchmail to create a mail loop :-)
In fact, this already happens if popservername is anyway converting <>
to <MAILER-DAEMON(_at_)popservername> when storing in the mailbox.
If popservername is already breaking empty return paths, fetchmail might
provide an optional (!!) workaround. _NOT_ break empty return-paths that
are still intact.
I didn't check the mda and escape stuff yet, but I do think the right way
would be to replace the "<>" to "MAILER-DAEMON" only for mda transport,
right before the escaping.
In my opinion, coding specifically for mda is not a good thing to do.
Agreed. As is coding specifically for MAILER-DAEMON, postmaster or
FETCHMAIL-DAEMON.
As I said, I didn't yet look into the mda or the escaping stuff. I still
did not do that. The only thing I know right now that "<>" needs special
treatment some way or another, as it's a special case by design. Using
"" instead of "<>" doesn't work, but escaping "<>" to "__" isn't right
either.
Regards,
Maarten.