Noel J. Bergman schrieb:
Vincenzo Gianferrari Pini wrote:
Norman Maurer wrote:
if the nameserver is not configured correctly etc we should
not try to "take care" and give the admin a chance to
correct it He should get sure what he do before change the
config.
I consider that an overly callous attitude, and unnecessary.
I think most admins and users want to get the error as soon
as possible.
They want their mail delivered (I'll address your use case in a moment). And
Delivery Notices are getting a worse reputation all the time. If you cannot
reject the message during the protocol exchange, most users want a notice to be
an absolute last resort. And, importantly, automated processes such as mailing
lists servers do not want a bounce unless it really is fatal.
q.v. http://community.kavi.com/khelp/kmlm/user_help/html/bounces.html
Is there anything more fatal as an unexisting domain ? And again if my
nameserver has problems its not the "task" of the mailserver take care.
DNS is needed for mailservices.. If there are DNS problems then the
sender should be notified. What james did in his old behavoir is really
strange and i bet most users and adminstrators never whould expect it.
Our Company administrate Qmail and Postfix server for long time and was
really shocked about the behavoir of james. We can't accept do get the
error bounce of an unexisting domain 1 Week after send the email.
Think about you have a costumer where you installed james. He sended
an email with an importent text out and not notice that he has a
misstyping in the domainname. The domain he used as recipient domain
does not exists.
Because of the scenario he described, I changed my config.xml long time
ago to one day instead of 5 days of retry before giving up.
This is a fine use case, but the solution is still wrong because of the other
problems it creates. There are multiple things that we can do to address this
use case, which I consider valid and worth addressing. For example, I have
worked with mail servers that will provide interim status information. I'm not
sure where Stefano is with respect to the DSN work that he worked on, but with
or without it we could allow the admin to configure JAMES to provide early
notice of temporary failures. That is the same as:
I think Stefano has finished the DSN stuff long ago. But it needed many
core changes.. Im not sure if it whould be backward compatible.
I was planning to code in RemoteDelivery (and never did it) a kind of
"warning bounce" feature to trigger after a few hours, while retrying
for up to five days.
and I would be fine with such a thing.
See my previous email. Its better then the old behavoir but still not
the correct solution (IMHO)
it would be much better if we could find a way to check if "my DNS
server" is failing to resolve the domain because the recursed servers
fail to resolve, and not because there is a network problem isolating
my local network.
There may be problems at the far end, including THEIR DNS server being down or
temporarily mis-configured. Again, consider the reality:
http://www.mhonarc.org/archive/html/spf-discuss/2005-05/msg00315.html
And since RFC 2821 strongly encourages the schedule that we use by default,
administrators may count on the described behavior as providing a safety margin.
Again.. if its misconfigured its not our task to deal with.. If someone
misconfigure his mailserver to deliver all email to /dev/null we also
can't take care. Its all about adminstration. If an admistrator change
something and break it, its not our "problem".
And if the dnsserver is down we will query the secondary. Every domain
should have at least 2 dns servers.
Or (a different approach) have a different retry policy (few hours
instead of 5 days) for DNS resolution failures while keeping the
longer 5 days period in case of target SMTP server failures
What do you think?
If you recall my proposal for replacing the scheduler, which is the very next
thing that I plan to work on after the hassle of dealing with I/O handling,
that was actually a related use-case. I described having a schedule for
retrying because of DNS failure, e.g., with the IsSpammerInBlacklist matcher.
So, yes, we could have multiple schedules configured for different conditions.
Read my comment above
The SMTP specifications are biased towards reliability at the expense of other
tradeoffs, and we should do likewise.
--- Noel
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
